I’ve been doing a lot of performance related work over the past few months. Much of it has originally stemmed from work that I have been doing for our Online Game Company client. They want the asynchronous ENet-based server that we’ve built for them to be the fastest it can be and so I’ve been looking at all aspects of performance within the framework. The testing hasn’t brought anything too embarrassing to light; the I/O recursion limiter that was introduced in 6.

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.

Overview When building TCP client server systems it’s easy to make simple mistakes which can severely limit scalability. One of these mistakes is failing to take into account the TIME_WAIT state. In this blog post I’ll explain why TIME_WAIT exists, the problems that it can cause, how you can work around it, and when you shouldn’t. TIME_WAIT is an often misunderstood state in the TCP state transition diagram. It’s a state that some sockets can enter and remain in for a relatively long length of time, if you have enough socket’s in TIME_WAIT then your ability to create new socket connections may be affected and this can affect the scalability of your client server system.

We have a new client profile available here for a client that we’ve had since 2006 in the IP Fax business.

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.

As you can see, we’ve updated the JetByte web site and integrated it into our product site for The Server Framework and Len’s, Rambling Comments, programming blog. We’ve also got a new logo which we had developed for us as part of a logo design competition that we ran on 99designs.com. The site is now managed using Movable Type rather than the custom content management system that we had written for us in 2001.

Version 6.3.3 of The Server Framework was released today. This release is purely a bug fix release and includes the following fix. A fix to JetByteTools::Service::CServiceManager so that it actually allows the service to run without throwing an exception! Fixes to JetByteTools::CLRHosting::CCLREventSink and JetByteTools::CLRHosting::CHostPolicyManager to remove a race condition during host shutdown which could have caused a purecall due to events being fired after the event sink has been destroyed. There’s no need for a documentation update so the latest docs available online will be for the 6.

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.

It seems that C10K is old hat these days and that people are aiming a little higher. I’ve seen several questions on StackOverflow.com (and had an equal number of direct emails) asking about how people can achieve one million active TCP connections on a single Windows Server box. Or, in a more round about way, what is the theoretical maximum number of active TCP connections that a Windows Server box can handle.

I’ve spent the last few days implementing the WebSocket protocol (well, two versions of the draft standard actually) and integrating it into an existing server for one of our clients. This has proved to be an interesting exercise. The protocol itself is pretty simple but, as ever, the devil is in the detail. I now have server side code that deals with both the Hixie 76 draft and the HyBi 03 draft of the protocol.