The latest release of the free version of my asynchronous, windows, IOCP based, socket server framework can now be obtained from here at ServerFramework.com.
The latest release is really just a bug fix and compiler compatability release. The code now supports Visual Studio 2005 (as well as VC6, Visual Studio .Net (2002) and Visual Studio 2003). I’ve fixed the memory leak bugs that were present in the ThreadPoolLargePacketEchoServer sample and worked around the iostream leak that’s present in the Visual Studio 2005 version of STL.
Last year 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.
The code under test was intended to be very scalable, I use the code to provide light weight asynchronous timers for my socket server framework and the idea is that each connection might have several timers associated with it.
A long time ago, on Practical Testing: I mentioned that there was a small chance that the way that ResetTimer() operated could mean that you could pass in a handle that you no longer owned and affect someone else’s timer by mistake; I said it was unlikely to cause problems… In this posting we fix this problem and in the process show how TDD builds up a set of tests that can support you during redesign…
Previously, on Practical Testing: we added a multi-threaded version of our timer queue that manages timeouts automatically. This time we’ll integrate our new timer queue into an application that uses the old version of the code and, along the way, discover some functionality that the original version supports but that the new version currently doesn’t.
One of the original reasons that we designed this timer queue was to handle per socket, read timeouts in our IO Completion Port based server framework.
Previously, on Practical Testing: we finished our reworking on the code we were left with a simpler timer queue that passed all of our tests, but was single threaded and needed manual intervention from client code to manage timeouts. Today we’ll add back the multi-threaded functionality so that the queue manages timeouts automatically.
Our original implementation of the callback timer queue used a thread to manage the timeouts. The threading was integral to the timer queue code and this made testing the queue logic difficult because, to test the queue, we had to control the thread.
Previously, on Practical Testing: having decided to rework the code from scratch in TDD style we fixed the tick count bug for the second time - this time the solution was cleaner and simpler. At the end of that episode we were left with a failing test. The test was for multiple timers and it failed because our TDD route was taking a ‘simplest thing that could possibly work’ approach and that design only supported a single timer.
Previously, on Practical Testing: Having bolted on some tests to an existing piece of code we’re now doing some “agressive refactoring” ;) and rewriting the code from scratch using the testing ideas we developed earlier. The whole point of this exercise was to fix a known bug, we did that in the existing code here, now we have a test that forces us to address the issue in the new code.
Previously, on Practical Testing: we fought through the pain of writing tests for hard to test code and then we decided to see what it could have been like if we’d developed the code test first… Now we’ll add some more tests and some more code, still keeping it all nice and simple…
In our BOT development our second test was a test for multiple timers. Unfortunately that will completely break our simplest possible implementation of a timer queue so we’ll ignore that test for now.
I’ve been writing some blog entries about a piece of code from my ‘back catalogue’ that didn’t have tests and that had a known bug that was reasonably hard to test for. Right at the start I commented that the code was a tad over complicated due to the way it had been developed using HITIW (Hack it till it works). The complexity in the code itself made writing tests for it harder than it should have been and, well, I wouldn’t write code like that these days (honest).
Previously on Practical Testing: After far too much work we finally got to the point where we had a test for the tick count wrap bug. Now that we have a failing test we can fix the bug.
At long last we have a test for GetTickCount() wrapping from a big number to 0 every 49.7 days. The test is controllable and we can run the test at any time, not just when the PC in question has been operating for 49.
