Friday’s Trick #2: Websocket/Comet survival guide to Proxy, Firewall and Network Outage
Independently of what transport you are using (WebSocket or Comet or both), a connection can always be closed by a Proxy or Firewall, or an expected network outage can close your connection. Why is it a problem? It’s problematic when a disconnection happens as you may loose server side events if you don’t architect your application correctly. This week I will describe how you can avoid loosing server side events using Atmosphere.
You can loose server side events under the following conditions:
- long-polling: between reconnection, servers side events may happens and if they aren’t persisted, those events will never reach your client.
- websocket: Websocket are new and most if not all firewall will close them after some X idle times. Again, all server sides events will be lost
- http-streaming: Some proxy really don’t like the http-streaming technique, and will close it right away. Again, possibility to loose server sides events.
- Unexpected network outage: the connection can also be closed by something between your browser and server.
For some application like chat, it may not be an issue if you loose some server side events, but for the majority of them it is critical to never loose any server sides event.
The problem is easily solved with Atmosphere by either implementing your own BroadcasterCache, which is as simple as:
void addToCache(AtmosphereResource<V, W> r, Object serverSideEvent);
List<Object> retrieveFromCache(AtmosphereResource<V, W> r);
You can easily implement that interface and persist any server side events using memcached, your favorite database, etc. As soon as you tell Atmosphere which BroacasterCache to use, the magic will happens. If you aren’t familiar with Atmosphere, the AtmosphereResource represents a request from where you can decide to suspend, resume or broadcast server side events. In case you implement your own, you can always persist using this object as a key or retrieve some information from it in order to construct the list of missed server side events.
Atmosphere ships with two build in BroadcasterCache:
- HeaderBroadcasterCache: Use a special header to tell the server what was your last receives server side events.
- SessionBroadcasterCache: Use the HttpSession/Cookie to tell the server what was your last receives server side events.
The HeaderBroadcasterCache uses the following header:
X-Cache-Date: Fri Jul 02 2010 10:34:21 GMT-0400 (EST).
So if an disconnection happens, independently of the transport used, you are guarantee to retrieve the server side events that occurred during your disconnected period. Hence your application is shielded from loosing data. By default, the Atmosphere JQuery Plugin always add the X-Cache-Date header, so all you need to do is to configure your BroadcasterCache in either web.xml, atmosphere.xml or programmatically:
<init-param> <param-name>org.atmosphere.cpr.broadcasterCacheClass</param-name> <param-value>org.atmosphere.cache.HeaderBroadcasterCache</param-value> </init-param>
For any questions or to download Atmosphere Client and Server Framework, go to our main site and use our Nabble forum, or follow the team or myself and tweet your questions there! You can also checkout the code on Github.