Platformability

Latest Updates: WebSocket RSS

• 

  London Ajax Comet Panel

  Martin Tyler 9:09 am on 14th July, 2010 | 1 Permalink | Reply
  Tags: Comet (23), WebSocket

  An interesting event last night that I mentioned recently.

  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.
   

  Reply Click here to cancel reply.

  Name (required)

  Email (required)

  Web Site

   
• 

  Apple releases Safari 5 with HTML 5 WebSocket support

  Martin Tyler 9:07 am on 8th June, 2010 | 2 Permalink | Reply
  Tags: html5 (4), Real-time web (23), WebSocket

  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?
   
• 

  Comet server message sizes, Bandwidth considerations

  Martin Tyler 3:03 pm on 28th May, 2010 | 8 Permalink | Reply
  Tags: bandwidth, Comet (23), messaging (2), Real-time web (23), WebSocket

  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 …)
   
• 

  Google Comet?

  Martin Tyler 9:07 am on 20th May, 2010 | 0 Permalink | Reply
  Tags: Comet (23), Real-time web (23), WebSocket

  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..

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

  Google going real real-time

  Martin Tyler 9:34 am on 18th May, 2010 | 0 Permalink | Reply
  Tags: Browsers (5), Comet (23), Real-time web (23), WebSocket

  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.
   
• 

  Evolution of Comet at Caplin

  Martin Tyler 12:45 pm on 16th April, 2010 | 0 Permalink | Reply
  Tags: ajax (13), Browsers (5), Comet (23), WebSocket

  I have been blogging on CometDaily since before we started Platformability so thought I would take a look back and see if there was anything there that might be of interest to our Platformability audience.

  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.
   
• 

  HTML5 WebSocket Failure Rates

  Martin Tyler 3:09 pm on 13th April, 2010 | 0 Permalink | Reply
  Tags: Comet (23), Real-time web (23), WebSocket

  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!
   
• 

  Why we don't need HTML5 WebSocket

  Martin Tyler 4:28 pm on 2nd March, 2010 | 8 Permalink | Reply
  Tags: ajax (13), Comet (23), Real-time web (23), WebSocket

  I was going to blog about HTML5 WebSocket last week, but got side tracked. In the meantime Greg Wilkins wrote an excellent piece covering some of what I wanted to say – http://blogs.webtide.com/gregw/entry/websocket_chat

  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.
  (More …)
   
• 

  Sockets, Messages and the Pub Sub Paradigm: Approaches to Streaming

  Martin Tyler 2:40 pm on 20th October, 2009 | 1 Permalink | Reply
  Tags: Comet (23), Object Remoting, PubSub, Real-time web (23), Sockets, WebSocket

  There are many products and projects out there that allow you to stream data to clients from a server, and most letting you send data back to a server too. There are various approaches that have been taken to achieve this which will be explored in this article.

  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.

  (More …)