Home > Atmosphere, Comet, Websocket > Friday’s Trick #2: Websocket/Comet survival guide to Proxy, Firewall and Network Outage

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.

BroadcasterCache

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>

That’s it!

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.

About these ads
Categories: Atmosphere, Comet, Websocket
  1. Nik
    July 2, 2010 at 3:10 pm

    Perfect. I just read through the API to determine this today but its nice to have it all in one place now :D

  2. Nik
    July 2, 2010 at 3:12 pm

    I was hoping for a quick blurb on the session version of the broadcaster cache. You mentioned the header version and how the jQuery plugin handles it but not the session one.

    • July 2, 2010 at 6:10 pm

      Salut, for the session one it should work as well without any extra as it’s the HttpSession is represented by a Cookie, and the browser will always send it back.

      Thanks!

  1. July 9, 2010 at 5:52 pm

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 51 other followers

%d bloggers like this: