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.

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 client MUST mask all frames sent to the server. A server MUST close the connection upon receiving a frame with the MASK bit set to 0.

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… Back when binary frames were mentioned in the WebSocket protocol specification as a slightly hand wavy “something for the future” and only text frames were actually possible to send and receive using the clients at the time then there MAY (in the strictest RFC meaning of the word) have been a need to differentiate between text and binary frames.

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 first thing to realise about the WebSockets protocol is that it isn’t really message based at all despite what the RFC claims.

I’ve been working with the WebSocket protocol recently, updating the code that implements the protocol in The Server Framework to the latest version of the draft standard (the HyBi 09 version). Whilst this looks like it’s almost a real standard, there are still lots of potentially open issues as can be seen from the HyBi discussion mailing list. It’s quite clear from some of the less cohesive parts of the draft spec (and more so from the mailing list) that the protocol is very much a design by committee effort.

Due to client demand we’re working on the WebSocket protocol again. Things have moved on since the work we did in December and this time the resulting option pack really will make it into the next release rather than simply being something that we tweak for each client that asks for it. Back in December one of our gaming clients wanted WebSocket functionality in their game server so we did some work on the two versions of the spec that they wanted, the Hixie 76 draft and the HyBi 03 draft.

I’ve just upgraded Movable Type from 5.03 to 5.11. The upgrade itself went smoothly except for one thing. A recent fix to MT to remove an obscure HTML standard violation that Firefox was causing problems with means that permalinks with runs of dashes in them have been changed. You can see the full details here on the MT forums where I posted the bug report. This is more of an issue for me as I did the upgrade and then launched www.