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 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.
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.
As I mentioned, I’ve been adjusting my build system and have finally got to the point where my lock inversion detector is suitable to run on all of my example servers during their test phase on the build machines. I’m working my way through the various example server’s test scripts and adjusting them so that they use the lock inversion detector, can be easily configured to run the full blown deadlock detector and also can run the servers under the memory profiling test runner that I put together earlier in the week.
My theorising about the strange memory related failures that I was experiencing with my distributed testing using WinRS have led me to putting together a test runner that can limit the amount of memory available to a process and terminate it if it exceeds the expected amount. With this in place during my server test runs I can spot the kind of memory leak that slipped through the cracks of my testing and made it into release 6.
See here for details.
The latest release of The Server Framework is now available from ServerFramework.com. See here for details.
I’ve put together a new website for my super scalable, high performance, I/O Completion Port based server framework.
This has all of the information that you need to decide if you can use The Free Framework or if you’d prefer to license The Server Framework. There’s also a new server example, WASP, which is a pluggable server platform that is available in compiled form and is free for non-commercial use. Over the next few months WASP will evolve to support most of the key features of the various options that are available with The Server Framework such as SSL, Managed hosting, UDP and TCP, etc.
Back in April I was talking about how the fact that 6.2 allowed you to enable FILE_SKIP_COMPLETION_PORT_ON_SUCCESS meant that some server designs might start to experience recursion that they previously didn’t experience. During the testing for the imminent release of 6.3 I managed to hit on just the right combination of build machine, load and test server to actually produce this under test. As I mentioned back in April, this is only a problem (in 6.
This evening I kicked off the acceptance tests for version 6.3 of the example servers that ship with The Server Framework; they’ll probably take most of the weekend to run, if I’m lucky. The unit tests for all the libraries have already been run through the build machines over the last few days, the release notes are almost done and so I’m now in the final phase of preparing the 6.
