Websockets and Comet

Websockets and Comet

Up until now, Superfeedr mostly focused on server to server communications (even though, technically, XMPP also works very well with clients too). Today, we’re announcing 2 server to client protocols, even though, they too, can be used for servers : websockets and comet. On both, we will push JSON by default.

Comet

It’s no secret that most of the modern webservices that we use are now able to load data within a page. You probably heard of Ajax, which relies on polling the server every few seconds to get any updated data, but you may also have heard of Comet, which in this case is mostly on persistent HTTP connection. This enables the server to keep pushing data on that TCP socket when more data is available for the client.
Among the most documented use cases, you will find Friendfeed’s and their infamous Tornado server.

Today, as a subscriber, you can also get Superfeedr’s content pushed to you directly using comet. Just open an HTTP connection, and we will push on this any content in the feeds to which you subscribed. Use your superfeedr credential for HTTP Basic Authentication, and we will push you the JSON. You can also open several connections at once, which is convenient if you need to upgrade your client without losing any data.

As you can see the stream contains several types of messages not just the notifications. For example you can see the line that tells that this user just subscribed to a feed, and later unsubscribed. There is currently no protocol as for these streams, so we chose to adopt the convention explained by the folks at new bamboo : each message is built with 2 elements : a ‘verb’ (subscribe, unsubscribe, publish in our case), as well as scalar which gives more details. We obviously use our JSON schema.

Since an HTTP connection is still mostly one-way, there is no way to send data on this connection to subscribe to additional feeds for example. However, we also introduce a small REST-like API which allows you to subscribe to feeds or unsubscribe, based on your needs. Since we push the result of subscriptions to the stream, it’s recommended to open a stream first, so you can see whether your subscription was a success or not.

Websockets

Unless you lived in a cave for the last year, you probably already heard of websockets. They’re now supported by modern browsers, such as Chrome, Firefox, Safari, Opera… etc. As they are part of HTML5, we can certainly expect an extended support in the coming months, and we want your apps to be ready for when that happens, which is why we also release a websocket API. It’s actually very similar to the Comet version and uses the same conventions. It also uses HTTP basic header to authenticate you.

The only significant difference is that websockets are duplex. You can receive and send traffic on the same socket! So, to subscribe to feeds, you can very simply send message on the websocket. The messages use the same convention explained a little above : ["subscribe", {:topic => "http://superfeedr.com/track?include=music"}] will perform a subscription.

A few warnings

First of all, these 2 APIs are alpha, which means they will get better over time, we will add features based on user feedback. The current setup should be good enough to support enough connections for all of our users and we’re already working on the proxies which will enable us to support hundreds of thousands of concurrent connections and beyond (the famous C10K problem), but we kindly ask that you take all measures on your end to support disconnections by handling them and reconnecting. Don’t forget to back-off too if you see persistent errors.

Liked this post? Read the archive or

Previously, on the Superfeedr blog: PubSubHubbub is not a license.