2
votes

I have a usecase for which I would like to know if HTML5's Server-sent-Events is suitable.

Multiple clients (Javascript+HTML5 browsers) connect to the web server (with a Java EE backend). Each client could be looking at a different view at any time, depending on what is their object of interest.

My Question is: How to keep multiple clients (on different views) up-to-date on the updates happening on the server-side, without flooding all clients with all updates on all views ?

Important points that I need to consider are:

  1. Many clients might be interested in the same events. If two clients are looking at the same view, they MUST get identical events.
  2. Events to be sent to a client depend on the view that client is currently at.
  3. Some clients may not be interested in any events (i.e they might be viewing static data)
  4. A given client could be dynamically changing their interest. for ex: close View1 and open View2.
  5. A client could be interested in multiple event channels (for ex: two dynamically-changing views could be part of a single page).
  6. I can target only browsers with complete support for SSE.
  7. There will only be a maximum of 100 clients (browsers) connected to the server at any time. So, I could have the luxury of having more than one connection open (for SSE), per client.

I have searched SO/Google for SSE and couldnt (yet) get reliable solution for production quality software. I dont want to go back to old Comet techniques, before fully exploring SSE.

Is SSE (by itself) capable of delivering on these requirements ? I am looking into Atmosphere right now, but I dont want to resort to some polyfill that imitates SSE, before deciding that SSE wont be sufficient by itself.

What I plan to do if this is not possible:
The server could broadcast all events to all clients and let the clients figure it out. This would mean, lots of unnecessary traffic from server to client and complex client code.

2

2 Answers

2
votes

Unless you can target a specific set of recent browsers you will always have to support some sort of fallback. Atmosphere looks like a good solution for that.

As to sending the right events to the right clients: Keep track of the clients and their preferences in either a Session object (check of Atmosphere is configured to support sessions) or your own Map. It looks like you can create multiple session broadcasters in Atmosphere as outlined here: http://blog.javaforge.net/post/32659151672/atmosphere-per-session-broadcaster

Disclaimer: I've never used this myself.

0
votes

What you could do is to send parameters via GET when you register an event with EventSource. The only problem lies at point #4, for which you should close the connection and re-register the event.

I tried that myself and it works pretty well.