Michael is on the WebSocket, Comet, HTML 5, and web standards panel that SV Web Builder has organized for October 29th. The panel also includes Alex Russell, Dion Almaer, Ted Goddard, John Fallows, and Kevin Nilson. It’s all going down at the Google headquarters in Mountain View. The event is free if you register online.

A couple of new features include:

• Embedded Stomp broker via MorbidQ. Now you put stomp:// urls in the [listen] section of the configuration
• Reworked startup api for easier use with outside projects like WillowChat.
• Improvements to the IRC client (via js.io)
• Increased stability for Connection handling when the page is reloaded navigated away from then returned to
• Various small bug fixes
• See the commit logs and timeline

Obviously it makes sense to migrate to separate processes for a high-concurrency production deployment, but this method is perfect for developing applications and deploying small to medium instances.

The tutorial uses a different technique than the STOMP method I described. Dark Porter takes advantage of the fact that Django and Orbited are both written in Python, and puts everything in one process, including a custom threaded TCP server.

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.

If you’re using a version of Orbited lower than 0.6.x, this is a great time to make the change, because 0.6.0 marked the change from alpha to beta, with the corresponding stabilization in API and core functionality. Remember to stop by the mailing list, IRC channel (#orbited on freenode or use the LiveDemo), and Trac system to participate in the development process and/or get help with Orbited.

Prior to 0.5, Orbited used a custom protocol (the Orbit protocol) for communication between it and the framework. Inside Orbited was a rudimentary message queue. This is the method used in the outdated CherryChat tutorial.

Use Existing Solutions

With 0.5, the team decided to switch to a standard and well-developed protocol: STOMP. Instead of trying to improve the message queue functionality, we decided to focus on TCPSocket and Comet. Using STOMP allows the use of advanced stand-alone message queue brokers like ActiveMQ and RabbitMQ. It also removes the need to write and update clients for the custom Orbit protocol, since there are actively maintained STOMP clients in many languages. These benefits are similar to the benefits of the biggest change in 0.5: TCPSocket, which lets you use existing protocols for communication to the browser.

The Super-Easy Way

ActiveMQ and RabbitMQ are fairly easy to install and use, but many people wanted something even easier and simpler for testing and basic deployments. Starting with 0.7, Orbited will feature a built-in basic STOMP message queue. The message queue has already been released as a Twisted-based daemon called Morbid. If you have setuptools installed, type easy_install morbid and then run orbited and morbid. Go into the Stomp demo and it should work! Once Orbited 0.7 is released you won’t even have to install Morbid.

The Benefits in Two Sentences

With the integrated STOMP message queue, you can use the same architecture as with pre-0.5 but with the added benefits of using a standard protocol. Using a stand-alone STOMP message queue broker gives you the benefits of the standard protocol plus the features and performance of advanced message queue brokers.

A CLA is a legal document, which means you should read it carefully. It basically gives the projects managed by the nonprofit a license to use your contributions (you retain copyright), and warrants that you have the right to give the projects that license. Most people do this implicitly when they submit code to an open source project, but a CLA puts it in writing and hopefully makes everyone aware of their responsibilities e.g. not submitting code they didn’t write, or submitting code they wrote on their employer’s time/property without their employer’s permission to license the code to an open source project. If you are doing or have done work for any of nonprofit’s software projects on your employer’s time/property, you should:

1. Talk to your boss and make sure it’s fine that you’re working on code that will be licensed to an open source project.
2. Have them sign a corporate CLA with the nonprofit which formalizes this agreement.

As a general note, anything you create on your employer’s time/property may belong to your employer. If you want to have any rights to these creations, you should have a written contract with your employer stating the the specific terms of the agreement. You should also be careful when writing and/or contributing code that’s similar to proprietary code owned by your employer. I’ll get back on topic now, as intellectual property is a very complex issue, but it’s a good idea to read a survey such as the Software Freedom Law Center’s primer.

The Benefits of CLA’s

The main purpose of CLA’s is protecting users of the software from IP lawsuits. They also have a number of other benefits. CLA’s make it clear that contributors are under no obligation to provide support for their contribution. They make people more aware of their rights when writing code on their employer’s time/property, as mentioned above. The project itself is less likely to be attacked via lawsuits. And in general it’s good to make issues clear and explicit. CLA’s are used by many open source projects including all the projects managed by the Apache Foundation.

About the CLA

The CLA is between contributors and the project, which makes it distinct from an end user license e.g. the MIT license used by Orbited. We’re using a CLA that is very similar to the one used by the Apache Foundation. The CLA’s are available on the Development page. You should email a scanned copy of the signed agreement to orbitedprojectREMOVETHISTEXT@gmail.com. A single CLA covers Orbited as well as all the other projects managed by the nonprofit.