Last week I was on the panel at the London Ajax Comet event along with a number of other people representing Comet products. Comet servers are nothing new and there are lots of options out there now, some open source, some free, some commercial, and more recently some as a service.
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.
The iPhone 4 announcement obviously trumped this at WWDC 2010, but Apple have also released Safari 5. If you read about what’s new you will see lots of HTML5 stuff, including WebSocket.
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?
I have blogged about Why we don’t need HTML5 WebSocket previously – and to recap, it’s not that we don’t need it, it’s not really that important until it is far more widespread and that is a very long way off.
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.
One of the questions I brought up on a previous blog – Comet servers for a Single-Dealer Platform – was that of bandwidth. The main thing that affects bandwidth that a Comet server has some control over is message size. At the time of that blog I hadn’t looked into this issue with all the servers in much detail, so I decided to dive a little deeper and look at the protocols of some of the Comet servers written about on that blog.
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.
(More …)
At the Google I/O developer event a few interesting things have been announced. I blogged earlier this week about Google going real real-time with its Feed API and yesterday they announced some new features in Google App Engine.
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..
There’s a log of talk about the real-time web these days, but most of it is talking about stuff that isn’t really real-time at all. Most of it just means when you access the data it is up to date, or in some cases it means things update for you every few minutes or seconds.
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.
As I mentioned on my previous blog – Comet Servers for a Single-Dealer Platform (SDP) I am performing some new benchmarks for Liberator. These are going to focus on some new things as well as some new figures for our traditional scenarios.
Amongst the new benchmarks will be some tests for publishing from the client, which is key for trading applications, and also benchmarking our container objects. A container is an object that represents a dynamic list of references to other data. Subscribing to the container automatically subscribes the client to its contents. Containers also allow you to subscribe to a subset, allowing efficient display of huge lists. The platform allows containers to be created dynamically based on filter and/or sort criteria too.
(More …)
Some interesting information on WebSockets recently came to my attention. Greg Wilkins posted to the hybi mailing list about Websocket success rates and TLS extension which links to some original research done by Google employees here while looking at their SPDY protocol, but they used WebSocket for their tests.
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!
Every second counts - or in financial markets, we’re usually talking milliseconds or even microseconds. The faster you can get a price to a client the better.
We have been very busy recently on R&D and are now close to releasing the Agatha negative latency trading platform.
Using advanced predictive algorithms we are able to send price changes to clients in advance of all other trading platforms.
This technology effectively breaks the zero latency barrier by predicting future events. The Agatha platform allows users to “pretrade” leading to more profitable arbitrage strategies.
Agatha is self tuning. The more confident the price prediction the earlier it will be sent out. There is a danger that when prices are predicted too early that it can actually have a knock on effect on future events.
Ongoing testing shows predicted prices are accurate 99.8% of the time, and the minority of prices that are inaccurate are reported back into the system acting as a feedback loop which allows the self tuning to adjust how early prices are sent.
Over the years we have carried out benchmarks on Liberator that focus on latency, sending high update rates to large numbers of clients in the shortest possible time. We have always been proud of our ‘close to zero’ latency figures.
The problem is that the margins of improvements are getting smaller and more and more people are in the low latency game now. Customers are demanding more and we had to make a game changing move.
Vast sums of money are made, and lost, based on latency of information. In this article by InformationWeek it was estimated that a 1 millisecond advantage in trading applications can be worth $100 million a year to a major brokerage firm.
Think of the effect negative latency could have on profits!
A few weeks ago a colleague sent through a link to this blog by Paddy Donnelly (warning, this link carries a parent advisory sticker) in which he expresses his frustration with web sites littered with spelling mistakes. I also find these mistakes annoying, although I am treading on thin ice as I am a frequent perpetrator of using effect instead of affect.
Within a few minutes of reading this blog, I sent a tweet that contained several spelling mistakes. With Paddy Donnelly’s blog still on my mind, this made me wonder whether spelling mistakes matter so much within the real-time web? Does the importance of sending out an update now outweigh that of ensuring it is spelt correctly and is grammatically correct?
