Thanks to Dylan for organising the event, and thanks to the other panelists for taking part. It was good to finally meet Alessandro from Lightstreamer, and its good to see the various open projects talking about their technology too. A couple of guys from Nirvana were in the audience and we had a good chat down the pub afterwards.

Everyone on the panel seemed to have similar views on WebSocket, although some have implemented it and some have not.

I’ll post a link to the video and slides when they are available soon.

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?

A question that a customer once asked was about message sizes, but the question was wrong, they asked what performance Liberator could handle with 1K messages – they wanted to compare Liberator to another Comet server sending 1K messages. I pointed out that they should let us know what the payload they want to send is and we can see the size of the message in our protocol, and they should do the same with the other Comet server. Maybe we could represent a much bigger payload in a 1K message than the other server could.

I have looked at four servers for this blog – Liberator, Lightstreamer, Adobe LCDS and my-Channels Nirvana. They all take slightly different approaches, but can all be used to achieve similar results. My test case is a single message payload, but I am showing the structure of the messages and will comment on how different payloads may be represented better or worse in the different servers.

The payload I am looking at is a fairly typical financial data update. To help highlight a few problems I am looking at what is often called an ‘image’ and an ‘update’. An image is an initial update, containing all the data about the instrument, the update is the subsequent updates where only a subset of all the fields will be updating.

The image is:

The update is:

These may seem like small messages, but they are fairly typical, and it should be easy to see how a few more fields will affect the message sizes. Lets first look at the summary of results, and if you are interested, further down is the detail of the messages.

The table shows the size of the message in bytes that each server will send. For LCDS and Nirvana there are two entries as they implement different protocols with quite different message sizes. I assume anyone using LCDS would be using the binary AMF protocol, you get to choose. With Nirvana, if you want a native web client you have to use the web protocol, but the protocol available to other technologies has far smaller message sizes.

Lets now look at the actual message structure and how they might differ with other payloads.

Liberator

Liberator is sending a script tag wrapped Javascript function call, with a single argument containing its own protocol. The messages do not contain the subject (or channel), and field names are mapped onto single characters (for the first 64 fields, then 2 characters etc..) This is quite compact with not much overhead. As more fields or larger field values are added there is little overhead.

Web Image message = 101 bytes


<script>a("7O5W0001 a=123456 b=234567 c=1274181389019 d=100000 e=200000 f=Company+Name+Ltd")</script>


Web Update message = 64 bytes


<script>a("6c5W0002 a=123459 b=234569 c=1274181389999")</script>


Other APIs such as Java and .Net don’t need the script wrapper, which makes the messages that much smaller.

Other Image message = 80 bytes


7O5W0001 a=123456 b=234567 c=1274181389019 d=100000 e=200000 f=Company+Name+Ltd\n


Other Update message = 43 bytes


6c5W0002 a=123459 b=234569 c=1274181389999\n


Lightstreamer

Lightstreamer is similar to Liberator in that it is also sending a single Javascript function call. Again, no subject name needed, and field names are not used at all. The fields are known by the subscriber, so the order the values come back in is significant – this has the benefit that it doesn’t need to send field names, but it does mean that fields that have not updated still need to be sent, albeit as an empty string. This is illustrated by the three empty strings at the end of the update message. Worst case scenario where a subscription to lots of fields where not many updated very often would have a bit of an overhead, but it is not that significant.

Web Image message = 95 bytes


<script>z(0,1,"123456","234567","1274181389019","100000","200000", "Company Name Ltd");</script>


Web Update message = 67 bytes


<script>d(0,1,"123459","234569","1274181389999","","","");</script>


For non web APIs the messages are again smaller.

Other Image update = 64 bytes


0,1|123456|234567|1274181389019|100000|200000|Company Name Ltd\r\n


Other Update message = 36 bytes


0,1|123459|234569|1274181389999|||\r\n


Nirvana

Nirvana’s NHP protocol used by browser Javascript clients is quite verbose. Once again it is Javascript being streamed directly, but it is not that optimised for size. The channel name is sent, twice, and field names are sent both as part of the map and as a list. There is also some extra data in there, which may be useful to some of the features of Nirvana, but seems like quite an overhead.

Note that this is a message using the properties style message (the ‘fprops’ section), it is also possible to send an opaque message (or a combination of the two) – an opaque message uses the ‘badata’ part of the message and would then not need all the fprops information – but you would have to pack some of that into your opaque message.

Since you can send what data/fields you want, the update message is smaller, not containing anything about the fields that haven’t updated.

With much larger payloads, the overhead will become less significant.

The messages below have been formatted a bit for easier readability, adding line breaks, the sizes reflect the actual message sizes though.

Image message = 760 bytes


<script>
try{
window.parent.handleNVLLastEID("/PATH/TO/CHANNEL1","28");
window.parent.handleNVLEvents({ eid : 29,
cname : "/PATH/TO/CHANNEL1",
tag : "notag",
badata : "",
hasData : true,
hasDictionary : true,
'fprops': {
'Field1':"123456",
'Field2':"234567",
'Time1':1274181389019,
'Low':"100000",
'High':"200000",
'FullName':"Company Name Ltd",
'nrvpub.time':1274187070518,
'nrvpub.host':"host.domain.com",
'nrvpub.name':"username",
'JMSMessageID':"My Message Id",
'JMSXUserID':"My User id",
'JMSDeliveryMode':"NON_PERSISTENT",
nrvkeys : ['Field1','Field2','Time1','Low','High',
'FullName','nrvpub.time','nrvpub.host','nrvpub.name',
'JMSMessageID','JMSXUserID','JMSDeliveryMode'],
nrvprops : "",
nrvproparrays : "" }
},
"eventHandlerCallbackFunc");
}catch(Exception){}
</script>
<i></i>


Update message = 675 bytes


<script>
try{
window.parent.handleNVLLastEID("/PATH/TO/CHANNEL1","28");
window.parent.handleNVLEvents({ eid : 29,
cname : "/PATH/TO/CHANNEL1",
tag : "notag",
badata : "",
hasData : true,
hasDictionary : true,
'fprops': {
'Field1':"123459",
'Field2':"234569",
'Time1':1274181389999,
'nrvpub.time':1274187070518,
'nrvpub.host':"host.domain.com",
'nrvpub.name':"username",
'JMSMessageID':"My Message Id",
'JMSXUserID':"My User id",
'JMSDeliveryMode':"NON_PERSISTENT",
nrvkeys : ['Field1','Field2','Time1',
'nrvpub.time','nrvpub.host','nrvpub.name',
'JMSMessageID','JMSXUserID','JMSDeliveryMode'],
nrvprops : "",
nrvproparrays : "" }
},
"eventHandlerCallbackFunc");
}catch(Exception){}
</script>
<i></i>


Nirvana’s NSP protocol is used by the Java API (and other Enterprise APIs), this is a binary protocol and much smaller in message size. Field names are sent but channel names are not.

Image message = 154 bytes


..............Field1..123456.Field2..234567.Time1......J.
Low..100000.High..200000.FullName..Company Name Ltd.........J.
.......host.domain.com.username....


Update message = 102 bytes


..............Field1..123459.Field2..234569.Time1......J.
........J........host.domain.com.username....


Adobe LCDS

LCDS sends serialised representations of objects, which means it sends all the fields whether they have changed or not. You could probably construct objects to only contain changed fields, but it doesn’t play to the strengths of the intended ease of use of sending objects and object remoting.

The XML version of the message is very verbose, but I don’t think there is a reason to use it, so it is only here to show the data more clearly than the binary version of the message. Class names, channel names, field names, XML tags, they are all sent and makes the message very large. Again, line breaks and indentation have been added for readability.

AMF XML message = 937 bytes


<object type="flex.messaging.messages.AsyncMessage">
<traits>
<string>destination</string>
<string>headers</string>
<string>correlationId</string>
<string>messageId</string>
<string>timestamp</string>
<string>clientId</string>
<string>timeToLive</string>
<string>body</string>
</traits>
<string>market-data-feed</string>
<object>
<traits>
<string>DSSubtopic</string>
</traits>
<string>PATH.TO.INSTRUMENT</string>
</object>
<null/>
<string>DCE35EDA-AF0F-B3B5-3ECC-DA2D0F7BE56B</string>
<double>1.243526266655E12</double>
<string>DCE25D41-DC0A-6A55-8F54-E7E2C34D1B07</string>
<double>0.0</double>
<object type="flex.samples.marketdata.Stock">
<traits>
<string>Field1</string>
<string>Field2</string>
<string>Time1</string>
<string>Low</string>
<string>High</string>
<string>FullName</string>
</traits>
<double>123456</double>
<double>234567</double>
<date>1274181389019</date>
<double>100000</double>
<double>200000</double>
<string>Company Name Ltd</string>
</object>
</object>


The binary AMF protocol strips out the XML tags which are replaced by single byte type markers (shown by the percent symbol in the message below). This cuts the message size a lot, but it is still pretty big.

AMF binary message = 403 bytes


1ae%%
1a7%%
%%%
%flex.messaging.messages.AsyncMessage
%destination
%headers
%correlationId
%messageId
%timestamp
%clientId
%timeToLive
%body
%market-data-feed
%%%
%DSSubtopic
%PATH.TO.INSTRUMENT
%
%IC49204A4-D0D5-6C35-476C-B0170F6444AA
%%%%%%%%%
%IC47E1B72-01DF-9FE4-6EEE-D7D230F6A28E
%%%%%%%%%
%%%
%flex.samples.marketdata.Stock
%Field1
%Field2
%Time1
%Low
%High
%FullName
%123456
%234567
%%%%%%%%%
%100000
%200000
%Company Name Ltd
%%%%%


Conclusions

As you can see, message sizes can differ a lot, even when they are representing the same data payload. Message size may not seem that important at first, but if you want to deliver real time data to a lot of clients it quickly adds up to a large bandwidth bill and saturated networks which can affect hosting costs. Bandwidth on the client end may also be an issue and latency can be affected in some situations. Smaller is better!

The interesting part is this:

Channel API – The Channel API lets you build applications that can push content directly to your user’s browser (aka “Comet”). No more polling for updates!

Google have done things with Comet before, some of which are probably just polling, but others such as Google Wave are fully live updating.

With the feed API and the App Engine Channel API Google are opening up their Comet capabilities to outside developers. I look forward to more details on the Channel API and maybe dissecting how it works. Most Comet solutions implement a number of techniques, mainly for different browsers, so it will be interesting to see what Google have done.

Google have announced a number of other things at this event which I found interesting and look forward to trying out..

• Google Storage
• BigQuery and Prediction API
• Cloud Portability – including some impressive Rapid Application Development with Spring Roo

Google’s Feed API gives you access to any public Atom/RSS like data, including lots of Google’s own data. There was a lot of fuss recently about PubSubHubbub and I blogged about how PubSubHubbub is the not quite real-time web.

At Google I/O this week, Google will be announcing some changes to the Feeds API that enable updates to be pushed to browsers. ReadWriteWeb got the scoop on this posting that Google will push real-time feeds to browsers. Not just in terms of details yet, the video shows the code changes are minimal, but what is going on under the covers is what interests me. Is is really real-time? is it polling? Will they pick one, works for all, solution, or try out WebSocket for those that support it. For most things the Feed API will be used for the speed of polling is probably fine, but high frequency polling is just inefficient compared to true streaming. Long polling would sit somewhere between polling and streaming and a good compromise for the client end. What I am interested in is what implementation Google thinks is best for what could be the largest deployment of a web push service yet.

Early on in CometDaily’s lifetime I wrote a piece on the Evolution of Comet at Caplin which covers how Caplin’s core technology has evolved since the start in 1997. The article was written in 2007, so I thought I would say how things have moved on since then.

The article finishes off talking about Caplin Trader our Ajax trading front end framework. This is still a large focus for Caplin, but we have also expanded out. There is a lot of extra functionality on the backend that was developed along with Caplin Trader – higher level integration to Trading and Permissions for example. Although Caplin Trader allows you to host other RIA technologies within it, we also wanted to more openly support other client side technologies in their own right. So we worked on these APIs to create Caplin Xaqua which is the full stack of our software, from backend integration APIs, through Liberator (and Comet) out to our StreamLink client APIs, which we expanded to include .Net, Silverlight and Flex.

Coming back to Comet, with the new client APIs and also new browsers and browser versions, we improved our coverage of Comet techniques to ensure the best possible connection is made for each scenario.

And the future? Well I have blogged about HTML 5 WebSockets more than once and to reiterate, it is a good new tool for Comet server implementers (rather than people developing web applications themselves) and i’m sure when the market share for browsers supporting WebSocket grows we will be adding the capability to Liberator and Streamlink.

I have always been suspect of WebSocket through proxies. Most people seemed to either not understand the issues or try to ignore them. An article on InfoQ on How HTML5 Web Sockets Interact With Proxy Servers was the first thing I had read that even addressed it at all.

If you did not read the links, it basically says that WebSocket over HTTP will fail for 37% of users, over HTTPS it should work ok. Of course that is only for people with WebSocket capable browsers (About 7% of people at the moment)

As I have said before, WebSocket is a step in the right direction, but it is just the latest tool in the Comet Server implementers tool box, for everyone else – come back in a few years time!

The idea of WebSocket is sound – it should get past some of the limitations of the various Comet techniques used today on various real time websites. It gives you full duplex communication between a browser and a server – Comet fakes this somewhat, but in most cases it is sufficient.

Some people seem to think that WebSocket is going to mean no more Comet servers and no more frameworks for real time data. But as Greg points out, WebSocket just doesn’t give you enough.

I see three main issues with WebSocket, or rather its uptake by web developers.

1. Browser support

We still have to deal with IE6 at the moment and WebSocket is not supported yet in the current browsers (apart from Chrome). So when can a web developer realistically rely on WebSocket being available for the majority of his users? This is likely to remain an issue for a long time.

2. Proxy support

WebSocket through proxies are a fairly unknown quantity – WebSocket is designed to fail cleanly so falling back to another mechanism is possible. However we don’t really know how many proxies will work with WebSocket. This includes server side proxies, which are often overlooked and are usually out of the control of the server side developer.

3. Features

What I am referring to here are the low level features that Greg talks about. His blog demonstrates that you cannot just take the simple WebSocket API and write a real time application (other than a demo) without taking into account the kind of edge cases he describes. Without this a web application could appear unstable for many users.

Taking all this into account, what is WebSocket good for? Who should use it?

Conclusion

Application developers use frameworks that hide issues and allow them to concentrate on their application, not the infrastructure. Frameworks can handle the error cases and implement various fallback methods for when WebSocket doesn’t work or an old browser is being used – there are free and commercial frameworks offering this.

So in this sense while Websocket will not improve web applications directly, it is something that framework developers can use to improve their frameworks – consequently improving those web applications that use the frameworks.

In a followup to this post I’ll explore some of the advantages and disadvantages of the methods discussed here further and talk a bit about domain driven design.

The term Comet came along a few years ago as a general term to describe the case where the client is a web browser and there are no visible page reloads. Many servers in this space support other client side technologies too, but the focus is often web browser clients.

When designing a product in this category there are various decisions to make. Many commercial products have target audiences in mind at this stage, whereas some projects are trying to solve a technical problem and the real world use cases will come later. In both cases technical decisions need to be made regarding how the product will look to the user (the developer) and how it will be implemented under the covers.

The complexity of the client API is a key aspect. There is a big trade off here between how much work a client coder has to do and how open what he can do is. This isn’t a simple scale though and the trick is to have something that is very easy to use without losing out on any flexibility in what can be achieved. A socket like API leaves a reasonable amount of work for the client coder, but also means he is free to implement almost anything. Conversely, many products in this space provide a publish/subscribe like API, which gives the client coder some basic building blocks that a good proportion of applications are likely to find helpful.

Publish/Subscribe

The use of the pub/sub paradigm has become very common in this space. It is a natural fit. The client chooses what it wants to see on its screen and subscribes to it from the server. Clients, or other server components, publish data and the server pushes that data to all subscribed clients. Many applications fit into this template, and some that do not can often still make use of the pub/sub API in a simple way without too much of an overhead.

Pub/sub may be a common, however it is implemented differently by different products. JMS like systems can be fairly static, you configure topics/destinations and these are used for a class of message or a specific application. Other systems are more dynamic, and to use an example from the finance world, the topic would represent a stock or other financial instrument and are created dynamically as they are needed. Some products that use the first, more static, method will have a sub topic which is more suited for use as the stock name.

Another way that pub/sub implementations can differ is in what happens when you first subscribe. In pure pub/sub, which may be based on multicast technology, when you subscribe you will get a message the next time there is a message on that topic. This is not always that useful, to use an example from the finance world again, when you subscribe to a stock you want to know its current value along with subsequent changes. Some older pub/sub systems add this capability in, but the initial value comes from a different place, introducing a nasty race condition.

Messages

The format of the messages, both on the wire and how they are presented to the client coder, can differ a lot between products. Not all products will present what they do as messaging, but at some level that is what they are doing, something is being sent from the server to the client or vice versa.

Sockets

The most basic method here is a socket-like API. The client coder is left to implement a protocol using this API. This gives maximum flexibility at the expense of possible complexity of the client coders implementation. With a browser client, a Socket-like API (see WebSocket) does a bit more for you compared to a true socket, it will most likely present you with whole messages, which avoids tricky code to handle partial reads etc.

Using sockets means you do not have any features like pub/sub or structured messages, it all has to be implemented by the client coder.

This approach is good for the hardcore coders who want maximum flexibility. It can also more easily integrate with existing backend servers that have differing protocols.

Simple Pub/Sub

A simple pub/sub approach with basic message structures can be very useful and solve a lot of use cases. Pub/sub means your messages have a subject (or topic) to identify it and a message body. The message body can vary between products, field/value pairs, structured data types, opaque data types etc.

This is an area that many products fall into and it’s the message body and the API that differentiates them at this level.

Field/Value pairs

This is a very simple, but powerful, structure. It is basically a hashtable or a map structure, often ordered. Most things can be represented in this format, but sometimes more complex structures are needed to avoid extra encoding being used by the client coder.

Structured data types

A reasonably common approach here is to use a format such as JSON for the message body. JSON allows simple data structures and objects to be represented in a textual human readable format. This gives a bit more flexibility over a field/value pair message type.

Object Conversion

Another approach is to send objects as the message body. This is similar to the JSON approach in many ways, but the object is converted from one languages representation of an object into a serialised form and then back again into an object in the language of the receiving end. For example this could be a Java object being converted to a wire format and then being converted to a Javascript object or an ActionScript object. Technologies like Flex/LCDS use this with AMF wire protocol to good effect, which can reduce bandwidth and processing compared to sending complex objects a formats such as XML.

Object Remoting

Object conversion is most likely used within a pub/sub like system, the object being the message body, whereas object remoting is more like conventional object oriented programming.

Object remoting tries to abstract away the fact that a client is talking to a server over a network. The client has an object that is a proxy for an object on the server (or vice versa) and allows method calls to be made on the remote objects. This means once setup, the client code can be written much like a normal application, making method calls on objects as if they were local. If there are return values for the method calls then there can be issues that complicate the apparent simplicity, as you will have to block for the call to return, or have a callback mechanism.

My followup article will cover why some of these approaches can be improved upon if your product is targeting a specific domain and how this can lead to faster time to market and a better final solution.