I am developing one distributed system application, besides than other thing, it use real time messasing to chat service and push notifications to many concurrent users notifications.
First, my actual project system is one Spring Framework Webservices with another two servers, one to real time messaging service, and another Google Cloud Messages to push notifications service.
Now, I am thinking to implement my own real time messaging and push notifications through my Spring Framework Webservices.
In here I have some doubts about application performance, Android/iOS chat and notifications services allways will be in up on Movile Services (like facebook, twitter, whatssap...). To few concurrent users less than 1000 for example, I have not doubt about it would be necessary a low features server to run system, but, if will be to many concurrent users more than 10000 running persistent websockets... Somebody can tell me the features server to run it?
For each Websocket connection Java getting up one persistent new Thread until close connection or only is getting up one new Thread by server to each Websocket request/response?
Which of the above two implementations is better?
Thank you in advance and best regards.
Neither nor;) You will want a server that does not need a new thread per connection or request, but per CPU core. And do asynchronous networking. E.g. Netty or Jetty.
Play Framework would be a perfect fit for this : full asynchronous/non blocking and very good websocket support.
Related
I need instances of a web-app to receive notifications via WebSocket.
These notifications derive from events in backend systems; these events need to be handled in multiple ways, not only pushed to clients.
Thus a pub/sub system is ideal: events are published and n consumers handle them if they are relevant for their operations (e.g. by topic).
Given my lack of knowledge on WebSocket I'm having a hard-time understanding the overall architecture I need to put in place.
In the pub/sub world consumers subscribe to queues of messages related to "topics" of interest to them.
Can the same be done in WebSockets? (i.e.: when connecting to a WebSocket from the browser, can I specify a set of topics that the client is interested in?).
If so, is it possible to directly connect to the pub/sub system or do I need a middle-layer that consumes from the pub/sub and pushes to websockets?
I guess that the answer to the last question depends on the pub/sub used and would need some library over WebSocket.
I am familiar with RabbitMQ, but I can choose another pub/sub system as at the moment nothing is in place so I have no migration costs.
Thanks
Why can't the individual app servers directly send notification to their mobile apps ? What is the benefit of having a centralized notification platform ?
From this thread, GCM is a service that helps developers send data from servers to their Android applications on Android devices. Same with APN which is a service for app developers to propagate information to iOS (and, indirectly, watchOS), tvOS, and macOS devices.
You may check these threads:
Why it is preferred to use GCM for push notifications?
Let's say you have 50 applications on your phone that do not use GCM. Each app developer decides it is appropriate to poll their respective backend once a minute.
Since these are all separate applications, each call will likely not happen at the same time as another api call. The biggest kill to battery is when the radio within an android device has to turn back on after being off to make an API call, so multiple calls happening with blocks of time in between drains battery faster (read this article on the radio state machine to better understand why this is https://developer.android.com/training/efficient-downloads/efficient-network-access.html)
In addition, each application will be hitting a separate endpoint. Each time you make an API call, you have to go through the connect process for a given server. With batched api requests or HTTP 2.0, multiple calls going to the same server can be optimized by not having to re-do a handshake or the connect process.
What are some advantages of push notifications?
Wide reach across internet users.
High conversion rates.
Real-time communication.
Push Notifications Explained
Hope this helps!
I wonder to know which technique and tools I should use to have the ability to send real time notifications to users. Specifically if I build a messaging system.
I can see that modern social networks can send notifications about new messages almost immediately. Even when the user 'A' from one country writes a message to the user 'B' in another country you can see that the user 'A' writes a message and you immediately see it (even if those users live in different continents).
I tried to figure out how it is possible and find any information about this but without success.
The only thing I found out is the technique when we use a Redis or RabbitMQ server with several servers which acts like publishers and subscribers. Our API servers receive new messages then they push a new message in the queue then subscribers receives the messages and if they have an open WebSocket with the recipient they push this message in the WebSocket and a client receives the message.
But it really won't work if you have a distributed project and your clients are connected to the nearest servers in the nearest data center.
The question is: what technologies/techniques/anything we should use to be able to build notifications in a distributed project?
If you develop your distributed app/system using web technologies, you can consider building what is referred to as a Progressive Web App. With PWAs you can add push notifications in a relatively easy way. You could start with a PWA approach, and then decide later on if developing a native app as well (i.e. iOS or Android) would be necessary.
There are many resources to learn and guide you in developing progressive web apps. Check the references I mentioned above, and you can do this codelab as a starting point.
Hi we are thinking to implement a chat feature in our web app. (MVC 3 running on Azure) like Facebook or Gmail applications.
So the idea about this question is to have your technical architecture opinion about it.
How would you design it and which services you would use (worker role, queue, blob, Sql azure etc.).
Thanks
Instant Messaging is about asynchronous delivery of messages between multiple publishers and subscribers. This sounds like a perfect recipe for Azure Queues.
If the number of users who will use this feature is small, you can create a queue per recipient. Web-app would drop a message onto the recipient's queue and would check queue of its own user.
The positive about this approach is its simplicity The downside of this approach is the frequency of checking the queues per user and the cost associated with that.
If you have 10,000 users logged into IM and the app is checking their queue's once per second, that's 1penny per second. Which translates to ~$26k/month.
Windows Azure Service Bus provides Publish-Subscribe messaging with Topics that can be used for this scenario. You can see a Silverlight based Chat sample for this: http://servicebus.codeplex.com/SourceControl/changeset/view/9715
In addition you can see a Multi-tier app sample that shows using Service Bus Topics/Subscriptions from Web/Worker roles here: http://code.msdn.microsoft.com/windowsazure/Multi-Tier-application-6c033cad
I am implementing an application using Prism.
The application has a few distributed components that resides on various machines or servers. In order to communicate them, I am planning to implement messaging service using Event Aggregator. But before I start working on that I would like to have a few clarifications:
Can Event Aggregator be used on a distributed environment. If yes
than how to define the server or hub where the message would be
published or subscribed?
What is the performance impact on the applications using Event
Aggregator? I feel it is negligible but still I would like to know.
Is Event Aggregator approach is good for future expansion in an
enterprise environment?
Thanks and Regards,
Ashish Sharma
PRISM is client-side technology. So, EventAggregator as it is won't do what you need. This is mechanism to communicate between modules in a loosely-coupled way. It is not about communicating between different clients.
For what you need - I would look into HTTP Polling Duplex
http://www.devproconnections.com/article/silverlight-40/using-http-polling-duplex-in-silverlight-applications
If you use PRISM on front end - you can write your own service and subscribe/publish EventAggregator events from that service while making server calls and receiving responses back.