The 0.6.1 release of Orbited adds a feature called heartbeats that improves dropped connection handling and also decreases reconnects due to timeouts. Dropped connection handling is important because it affects the user experience of a web application. Heartbeats are better than the previous solution of reconnecting at a fixed interval because they do a better job at a lower network cost.

Dropped Connections

A web application can’t prevent most dropped connections. It can only handle them in the best manner possible. Dropped connections are a problem because unless there’s some notification mechanism, the browser won’t automatically try to reestablish the connection. Furthermore, the user will think that the application is operating in a connected state, and won’t realize that they are missing messages.

This hurts the functionality of the application, and also decreases the user’s confidence in the application, which has negative implications for how much they use it and whether they will use it for important tasks. Preventing disturbances in the user experience and increasing user trust are both very important goals. Orbited prevents lost messages by keeping a buffer of recently sent messages, but we still want to resume normal operations as possible.

Fixed Interval Reconnects

A common way to handle dropped connections is to have the browser reconnect every 30 seconds, regardless of whether the connection has dropped. Prior to 0.6.1 this is what Orbited did. This method caps the period of browser unawareness at 30 seconds + the browser timeout interval. ~30 seconds is a long time for the browser to be ignorant of the connection state. The interval can be decreased, but reconnects should be avoided for 2 reasons:

• The browser can’t receive messages while it’s reconnecting. The connection is usually fine, so most reconnects are actually making things worse for a short period of time.
• Each reconnect requires a full HTTP message to be sent and processed. This isn’t that bad for the client, but really adds up for the server, which is almost always the bottleneck for web applications. And some people are on dial-up or mobile connections.

Fixed interval reconnects aren’t horrible, and they’re used by live deployments. But there’s a much better way.

The Heartbeat Solution

Orbited 0.6.1 adds a feature called heartbeats, which provide better browser awareness at a lower overhead cost than fixed interval reconnects. A “heartbeat” is a tiny amount of data (~1 byte) sent from the server to the browser without separate HTTP headers (it’s sent in the context of the Comet connection HTTP headers), meaning the cost both of bandwidth and server processing is negligible.

If we send a heartbeat every 5 seconds, the maximum time the browser is unaware of the connection state drops from 30 seconds + the browser timeout interval (with fixed interval reconnects) to the heartbeat timeout, which defaults to 15 seconds (the timeout is longer than the interval to account for latency). And the browser only has to reconnect if the connection drops, instead of having to reconnect every 30 seconds no matter what. The timeout and the heartbeat interval can both be lowered if necessary.

Timeouts

Heartbeats also prevent browser and proxy timeouts. Browsers and proxies often close open connections after around 60 seconds of inactivity. The fixed interval reconnect avoids the connection being closed unceremoniously, but since heartbeats count as activity, they prevent the timeouts from even happening. The fewer reconnects the better.

Usage with Transports

Orbited provides two Comet transports: streaming and long polling. Streaming provides better performance and is the default/recommended option. Both transports work with heartbeats. IE and Opera can only read heartbeats when they’re used with a streaming connection, so a long polling connection can’t use them for dropped connection handling, but they’re still handy for avoiding timeouts. Streaming with heartbeats works with most firewalls, forward proxies, reverse proxies, and routers, but if a particular deployment of intermediaries does manage to thwart streaming, the server can fall back to long-polling.

What You Need to Do

Probably nothing! Orbited 0.6.1 and onward use streaming with heartbeats by default. If you want you can lower the heartbeat interval and timeout for even better browser awareness of dropped connections.

This entry was posted on Wednesday, September 17th, 2008 at 4:00 pm and is filed under Uncategorized. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.