Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I am designing a web server that handles multiple things such as a user-to-user chat, a user-to-group chat, friends request, forum etc.

The chats have to be real-time chats, the friends requests should be notified in real-time to the user, and the users should be instantly notified about the new topics on the forum.

I use Spring and I implemented long polling to lower the latency and the number of requests. In theory long polling works well for one thing (a chat for example).

The problem here is that the client has to be notified for multiple reasons: new message on chat, new message on forum, new friend request etc. The naive solution would be to use long polling requests for each action, but it leads to having all the clients opening four or five requests at the same time.

Can the server easily handle this or should I manage to create a system so that every notification is returned through only one request? Is there another solution?

share|improve this question
    
I don't have experience in this area but what's the problem with sending every notification through one request? –  Doval May 2 at 18:43
    
It could break the logic on the server side: why would friend requests and chat messages be treated by the same controllers. I do not say it as a bad solution (since it is the one i am planning to use), but it can be seen this way. –  Thüzhen May 2 at 18:47
1  
They don't have to be handled by the same controller. Couldn't the controller responsible for aggregating all the notifications into the single response delegate to other controllers that contain the notification type-specific logic? –  Doval May 2 at 18:52
1  
I'd view the architecture like this: The polling just establishes a content-agnostic communication channel, which transports messages of various types. At the client side, a callback would be responsible for dispatching the message to the correct action, e.g. notifications or chat messages. This would be mirrored on the server side, where controllers collect all messages for one user at a central location until the user initiates the next request. –  amon May 2 at 19:02
3  
I agree with Doval - step one is to re-engineer it to use a single connection. Whether a large number of long polling clients will be an issue or not really depends on what you are doing on a server. It'd be fine in node, for example. But probably not a great idea if you're launching a thread or process per connection. –  GrandmasterB May 2 at 19:20

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Browse other questions tagged or ask your own question.