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.
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.
Dhanji over at Rethrick Construction has written an interesting piece on the value of unit testing.
I agree with his conclusion; “So the next time someone comes to you saying let’s write the tests first, or that we should aim for 80% code coverage, take it with a healthy dose of scepticism.” But then I tend to take everything with a dose of scepticism…
I also agree with the fact that sometimes the tests get in the way of refactorings that you’d like to do and sometimes the tests give you more code that needs to be maintained and that they often appear to slow down your development time.
I have a client who is possibly suffering from TIME_WAIT exhaustion and I thought that the best way to find out for sure was to get them to add the TIME_WAIT perfmon counter to their normal counter logs so that we could see how and when sockets in TIME_WAIT accumulate on the machine.
The problem is that there doesn’t seem to be a perfmon counter for this, which is unfortunate, especially since you can easily get the number of established and reset connections from the TCPv4 and TCPv6 performance objects.
Back in 2004, I wrote a series of articles called “Practical Testing” where I took a piece of complicated multi-threaded code and wrote tests for it. I then rebuild the code from scratch in a test driven development style to show how writing your tests before your code changes how you design your code. Since the original articles there have been several bug fixes and redesigns all of which have been supported by the original unit tests and many of which have led to the development of more tests.
I’ve just finished upgrading the blog from Movable Type 2.64 to Movable Type 5.0.x. The main reason behind actually getting around to doing this (the ‘update blog’s MT version’ “todo item” has been on my list for several years!) is so that I can integrate Rambling Comments with my other technical blogs. At present it’s just The Server Framework blog, but I have two more micro blog sites due in 2011 for products that I’m working on and I wanted to be able to include the entries from these new blogs into the main Rambling Comments feed.
After a week or so of serious dog fooding I’ve finally got a nice reliable lock inversion detector running as part of my build system for The Server Framework’s example servers.
Note: the deadlock detector mentioned in this blog post is now available for download from www.lockexplorer.com.
The build system has always run a set of ‘black box’ server tests for each server example as part of the build. These start up the example server in question, run a set of connections against it and shut the server down.
