This post isn’t intended to promote using Comet servers, but to highlight the difference between PubSubHubbub and client push technologies such as Comet (which in my view includes HTML5 WebSocket). It is important to understand the difference and why the technology and protocols to implement the two areas are not suitable for the other. I have seen people consider PubSubHubbub for client delivery, and also using full streaming techniques for server to server delivery, but in both cases it is not as suitable.

PubSubHubbub is a server to server protocol, and this is the key point. It increases the speed at which servers such as Google’s servers for Google Reader receive updates to blogs and other RSS feeds. However, PubSubHubbub does not change the last hop, which is how client applications or browsers receive these updates to blogs.

Of course, if the server gets the update quicker, the client will too, but PubSubHubbub is only responsible for getting the update to the server.

There are lots of techniques for clients to receive real time updates, and it is becoming reasonably common for websites to have elements of live data. Often this is polling behind the interface, so although the user does not have to take any action, and the whole page does not reload, there is still a delay in the screen updating – the user is just not as aware of it.

The following diagram shows the sequence of events for PubSubHubbub. The green events happen once when an aggregating server, such as Google Reader’s servers, subscribe to a blog. The red events happen each time the blog is updated. The blue events are not part of PubSubHubbub, but show a typical polling client to complete the picture.

One of the key aspects of PubSubHubbub is that the Aggregator Server does not stay connected to the Hub. The subscription process is a single HTTP request but the Hub only has to remember a list of subscribers – not maintain open connections to them. When a new item is published on the blog, the blog server simply pokes the Hub to tell it the feed has changed, and the Hub then does the hard work of figuring out what is new and sending the new items to all the subscribers.

Informing the subscribers is a simple HTTP request, as are all the events in this workflow. There are no persistent connections other than HTTP Keep Alive efficiencies at a lower level.

PubSubHubbub for client delivery?

Delivery to clients is a very different use case.  There could be many more clients, most of which will not be running at any one time. With a persistent streaming connection the server knows when a client is connected and only has to send updates to currently connected clients. With PubSubHubbub a subscription is just a list of URLs to inform – if the list contains a large number of clients that are no longer running then it is a large overhead to attempt to send out all the HTTP messages.

Another reason for PubSubHubbub not being suitable for client delivery is because clients are often not publically addressable. In other words the Hub cannot send an HTTP request to a client even if it did implement a web server interface. For this reason all real time client delivery techniques use either client polling or maintain an open connection initiated by the client.

HTTP Streaming for server to server?

Conversely, client delivery techniques are not as suitable for server to server communication here. If polling is used, we simply go back to how things were done before PubSubHubbub with all the problems associated with that – poll too often and you have large overheads. Poll too infrequently and you only get updates infrequently.

However, a full streaming connection would be ok right? Well not really, as blog updates and other RSS feeds are not millisecond critical, and scalability and stability are probably more important. A Hub having to maintain persistent connections to all server subscribers would add complexity and increase resource usage. Clients may have to use a persistent connection, but you can communicate with a server using a simple HTTP request.

There are some use cases where low latency is essential, and in these cases a streaming connection is more suitable. In these situations the number of clients is usually controlled more closely than a typical PubSubHubbub network of public blogs.

Conclusion

PubSubHubbub may not address the final hop to the client, and as a protocol is not suitable for that hop, but it works well for what it is designed for. The server to client hop is covered by Comet or other streaming solutions and together with PubSubHubbub provide end to end real time publication of RSS feeds.

I have been reasonably vocal about how WebSocket isn’t the answer to everything, mainly due to browser support and the time it takes for large companies to upgrade their browsers and operating systems. However, on mobile devices this might not be such an issue and WebSocket could now be a good option for real time web apps on mobile devices. I would still advocate using a product that wraps this up and handles backwards compatibility and browser differences across all desktop and mobile environments.

10 Add clients that subscribe to X subjects.
20 Once subscriptions are done, measure the latency of all messages for 30 seconds
30 GOTO 10

This means we are measuring the steady state of updates, while no other activity is going on.

We have soak tests that do a whole lot more than that, but we’re talking about benchmarks here.

It is easy to come up with more real world scenarios. For example, clients unsubscribing and subscribing to other data, clients sending messages into the server, and using different features of the platform. The purpose of a benchmark is to have measurable attributes, for the standard benchmarks this is clear – latency, cpu, numbers of users etc. It is also easy to understand – ‘Liberator can support 100,000 clients receiving 1 message/sec at under 10ms latency’ is is something you can compare to other products (with a few more details like message size clarified).

The problem with the real world scenarios is they are less comparable, less meaningful – ‘Liberator can support X clients subscribing and unsubscribing every minute, while sending messages to the server every 30 seconds…’ – it becomes fairly arbitrary. The standard benchmarks are the kind of numbers you can ask a customer for – how many clients will you have? how fast does your data update? With the real world examples, try asking questions and see what you get – how often will people switch views (change subscriptions)? how often will users trade? You will get answers that are vague at best.

Nevertheless, I have been doing some benchmarks along these lines to see how various commonly used features impact the performance of Liberator and the platform.

Transformer is a server that sits behind Liberator and allows modules to be implemented to transform the data coming from sources. So I added Transformer into the chain in the benchmark environment. Tests include using each of the three types of module, C, Java and LUA. The modules themselves do very little apart from passing the message through, so it is really only testing the bridge between languages. Results are good, with very little latency added at all.

Trading. Clients have to send messages to Liberator to trade, so I added some scenarios that include client to server messages, being echoed back and round trip latencies recorded, as well as looking at the usual update latency of other data.

Containers. Liberator has the concept of a container. A meta object that can be subscribed to with a single command. A container is a list of references to other data, which you get subscribed to by the server. This is very convenient for long lists of data in grids, such as a list of bonds. It is also possible to only subscribe to a portion of a container, allowing the client to only receive what is visible on screen and not anything scrolled off screen. Items can be added and removed from containers with the clients subscriptions updated accordingly. This is how many clients subscribe to the majority of what is on their screen, so scenarios where subscriptions are made this way are quite important.

I will probably publish some actual graphs soon, but final results are still being run.

Althought the focus for Comet is on server to client push, most Comet solutions provide an API to allow client to server push within the Comet environment – rather than forcing you to send client to server messages over HTTP directly.

The ‘Web’ way

The problem is many people are still stuck in the ‘web’ way of doing things and they only come to Comet when they need server push.

The problem with this is it leads to a circular architecture. Somewhere on the server side lives some application logic, sending messages and receiving messages, and probably doing something to them in between. Before the web, or if the web isn’t a requirement, people would use communication APIs that allow you to send and receive – from low level socket APIs to higher level messaging – but you send and receive using the same API.

With some web applications, messages are sent to an Application server using standard web technology, this is then passed on to another server process which may feed into the back (or side?) of the Comet server, which sends messages using Comet to clients. The circular architecture.

The Comet way

If you are using a Comet solution, make full use of it. A single API on the client, and a single API on the server.

What benefit do you actually get?

I think I have covered the benefits of using a single API, but there is more. Liberator, and some other Comet servers, provides a security API to control access to the system and granular access to specific data. When using the Comet server for data in both directions this aspect of controlling data access is contained in one place. With a circular architecture, subscribing to data needs to be controlled by the Comet server, but sending data needs to be controlled by the application server. It’s quite clear that this situation is not a good thing.

What about efficiency?

At the moment, most Comet solutions will be using new HTTP requests for each client to server message – so technically it isn’t much different to the circular architecture (as far as the network is concerned). What about the future? I have blogged about WebSocket before, but if/when WebSocket does become more widespread using Comet servers for bidirectional messages will be more efficient, since client to server messages do not have the overhead of HTTP requests.

So take a step into the future, it isn’t all about posting requests to application servers and all the constraints of the request/response stateless nature of the web. Comet gives you a much more natural way to communicate!

Some of my blogs relate to Liberator, but I don’t often talk about it directly, explain the different versions or describe what you can do with it.

Caplin Liberator is a commercial product that we sell, usually as part of a larger framework called Caplin Xaqua. Liberator was first developed in 2000 and has been used in many large deployments since then.

A few years ago we decided to release Liberator FE, this is a free edition of Caplin Liberator.

So what can you do with Liberator FE?

The short answer is ‘pretty much everything you can do with the commercial version’, but what is that and what are the differences?

Liberator FE comes with two APIs. Most people familiar with Comet will understand the idea of a JavaScript library that runs in the browser talking to a Comet server and exchanging information – Liberator of course provides this, it is called StreamLink for Browsers. Not all Comet servers provide server side integration APIs though. For some the model is ‘everyone is a client’, so even if something is conceptually a backend component it might still use the same API as the clients. Liberator has the concept of DataSources, as the name suggests these components provide the data. Clients can also provide data, but it is treated differently. Liberator FE provides a Java DataSource API.

So you might take the Java DataSource API and write an application that feeds data into Liberator that is then available for clients. The client application would be a web page using the StreamLink for Browsers JavaScript API to subscribe to the data that the DataSource is publishing. It will receive data in real time, as soon as it is published, and clients can also publish data back to the server – it is fully bidirectional.

What kind of applications can you develop? How long is a piece of string? You can use your imagination.. Caplin’s main focus is financial trading applications, but anything that could benefit from real time data or highly interactive experiences can be developed. Sports scores, chat and other social media applications, real time monitoring, games, whatever you can think of! We’d love to hear of other ideas.

So what can’t you do?

Liberator FE is a full blown version of Caplin Liberator, performance, scalability etc, it is all the same. However, you don’t get other language APIs, for example, .Net, Silverlight, C/C++. You don’t get two further integration APIs, for handling realtime permissioning and monitoring.

You also cannot use Liberator FE for a commercial application – it is against the license.

Liberator FE has been downloaded by a lot of people and we hope this is a good way for people to get familiar with Liberator and Comet technology – whether it is for a non-commercial project or as a way of easily evaluating Liberator for a commercial project.

So if you want to try out Comet, if you are interested in some of the things I blog about and want to try it out, Liberator FE is a good place to start! Let us know how you get on.

But as I wrote about last week, which version of HTML WebSocket? Is it the same as the latest version of Google Chrome? Google made a clear statement about the version and how it will not maintain compatibility until the specification is more stable, but I cannot find any info from Apple on this. Is it the same code base since they are both WebKit browsers?

So that’s the two smaller browsers (market share) with some support for WebSocket, when will IE and Firefox join the party?

Anyway, Google have just announced that they have Updated WebSocket in Chrome. I follow the hybi mailing list which is where most WebSocket discussion goes on and there is far from a consensus on many aspects of WebSocket, which has led to the changes the Google blog mentions, and there will almost certainly be more. Google noted this too and state that they will continue to update their WebSocket implementation regardless of compatibility issues until a more stable spec is available.

So where does that leave us? The only browser that supports WebSocket is updating and will continue to update its support for WebSocket, breaking compatibility with WebSocket servers, who will most likely also be updating to newer versions as they are available. I think this is the right choice for Chrome and server implementers – but it does mean that WebSocket for any kind of serious web application is clearly not viable. I hope any web apps and server implementations can handle the compatibility issues gracefully so they can fallback to other Comet techniques, as they have to with all other browsers anyway.

I look forward to a day when WebSocket is usable – but for now it’s business as usual.