Before I started to look at RIO for inclusion in The Server Framework I did a quick check on the Microsoft BUILD site to see if there were any sessions that dealt with it specifically, I didn’t find any. Once I posted my blog posting I did another check and found this video that deals specifically with RIO. This gives some in depth details of how RIO works and the kinds of performance improvements that Microsoft has witnessed in their labs.
Version 16 of the draft WebSocket protocol specification was just released and the HyBi mailing list announcement for this version contained the following:
Chairs and editors believe that this version is final (before the publication of the RFC). Thank you to everybody who helped to get this completed and for the stimulating discussions on the way.
Now feel free to discuss extensions, WebSocket 1.1, etc. :-).
There are no major differences between this and version 13 and the version number of the protocol itself stays at 13 so The WebSockets Option Pack supports everything that will be in the final RFC.
I’ve just released The WebSockets Option Pack for The Server Framework and I think it’s worth running through why the API that I designed ended up as it did. This will probably end up as part of The Server Framework’s WebSockets documentation, which is currently a little sparse.
The WebSockets protocol is a message based protocol with unbounded message sizes. This makes a general purpose API more difficult to design as some clients of the API may wish to work in terms of discrete messages and some may wish to work in terms of streams of data.
I have a tendency to write unit tests that are a little more invasive than they need to be; these tests make sure that not only are the results as expected but also that as many of the side-effects and interactions with other objects are as expected as well. So, for example, in my current WebSockets development for The Server Framework I have some tests which test that the correct data is delivered to the client of the API that I’m developing and also test that the API interacts with its buffer allocator correctly and doesn’t leak memory.
Another day, another WebSocket protocol draft…
That’s probably a little unfair actually. Although there have been several drafts in quick succession over the past few weeks the protocol itself has only changed very slightly. The majority of the changes have simply been to the wording and arrangement of the document.
I was fairly cynical about the likely quality of the final RFC when I started looking at the 09 draft and then, in search of clarification, started following the HyBi Working Group’s mailing list.
I’m nearing the end of my WebSockets implementation for The Server Framework and have been dealing with various protocol compliance issues. Whilst I have decent unit test coverage I haven’t, yet, sat down and produced compliance specific unit tests which walk through the various parts of the (ever changing) draft RFC and test each aspect. Looking back, I probably should have taken this approach even though the RFC was fluid. Anyway.
I’m just back from a wonderfully relaxing holiday in Italy. This time we had internet connectivity all the time, so I’m up to date on email, etc. The first thing that I do after all the ‘we’re back, how’s the house, and you need to go to bed even though you’re excited to see all of the toys you’ve missed’ stuff is to fire up all my machines and make sure that they do their windows update stuff… Then the NAS devices need to be started and allowed to settle in, then the VPN needs to be checked, dyndns kicked, etc.
As I mentioned here, the WebSockets protocol is, at this point, a bit of a mess due to the evolution of the protocol and the fact that it’s being pulled in various directions by various interested parties. I’m just ranting about some of the things that I find annoying…
The WebSockets protocol includes a way for the endpoints to shut down the connection.
If an endpoint receives a Close frame and that endpoint did not previously send a Close frame, the endpoint MUST send a Close frame in response.
As I mentioned here, the WebSockets protocol is, at this point, a bit of a mess due to the evolution of the protocol and the fact that it’s being pulled in various directions by various interested parties. I’m just ranting about some of the things that I find annoying…
The WebSockets protocol is designed to be extended, which is all well and good. Extensions can, at present, be formally specified by RFCs or be “private use” extensions with names that are prefixed with an “x-”.
I’m currently building a new example server for The Server Framework. This is a variation on one of our proxy server examples for a client that’s doing some WebSockets work. The idea is that the server takes an inbound WebSockets connection, creates an outbound TCP connection to the target server and routes data to and from the remote server and the WebSockets client. It’s fairly simple stuff to put together once you’re up to speed on The Server Framework but my client needed a helping hand and it’s another nice example of what you can do with the framework.
