My new development box arrived last week. It’s a bit of a monster, dual processor (Intel Xeon E5320 quad core, 1.86 GHz), 8GB ram, and it runs 64bit Vista very nicely indeed. Since it’s an x64 box I have started work on porting The Server Framework to x64. So far things are going very smoothly. The main issue is that I have, in the past, tended to overuse size_t when I really mean “a reasonable sized unsigned value”.

We’ve been engaged by an Online Gaming Company that is using The Server Framework to refactor and redesign their reliable UDP implementation, based on ENet, so that it’s more efficient and performs better with the asynchronous design of The Server Framework. In addition they want us to build them a custom CLR Hosting solution within their server so that their games can be written in managed code but the networking layer can leverage the power of C++ for their reliable UDP layer.

I’m just about to try out the latest STLPort release and I went to apply my ‘STLPort 5.0 multiple side by side dlls changes’ from 2005 and noticed that the place where one of the changes needs to be made has changed. The change to Makefile.inc should still be made to STLport-5.1.3\build\lib\Makefile.inc but the change that was previously made to stl_msvc.h now has to be made to STLport-5.1.3\stlport\stl\config\_auto_link.h

Given what Jeff wrote recently and what Ian and Dennis said about it… I’m definitely on the Ian and Dennis side of the fence…

I grabbed a couple of copies of “The NT Insider” from my ’not quite got around to reading’ rack today and read them on the train on the way in to London. These are the quite short, bi-monthly, driver developer and kernel programmer magazine from OSR. It’s free to subscribe and the content reminds me of the thrill that I used to get from reading computer mags back in the late 80s… I guess it’s possibly the fact that lots of it is slightly alien to me, there’s a certain excitement in knowing that there’s so much to learn and being able to follow half understood threads in one article to other articles and deeper understanding… Plus this stuff is hard, and complex, and a bit scary, and nobody is appologising for it… Anyway, sure takes me back…

I’ve been having some problems with Explorer hanging when opening “My Network Places” on some of my machines. Some work fine, some hang. Most annoying. I’ve been trying a few things over the past few weeks (as and when I get a hang and as and when I feel like it), but nothing has seemed to have fixed anything, until this morning… I’ve recently adjusted my networking kit and now have a couple of UPnP devices floating around and it’s useful (but not essential) to be able to connect to them directly in Explorer.

It seems that the latest changes to The Server Framework have managed to flush out a graceful shutdown bug that’s been floating around since day 0. There’s this whole, complex, way of determining how a socket is shutdown and this whole clever thing that lets you decide if you want to do a graceful, lingering, close on an I/O thread or simply slam the door and risk losing data and, well, it doesn’t seem to work.

I’ve finally got to the point where my latest refactoring of The Server Framework can be merged back to the main development branch. The changes grew from just being a “remove inappropriate use of pointers where references would be better” to a complete pass through my TODO list and subsequent design adjustments. I also managed to have a good crack at a first pass through the “document the code with doxygen” item and the results of that can be found here.

Except of course, the refactored filters can’t actually be layered that well using the design that I outlined in the previous blog posting. The main problem, the “too simple” part of the design is that, well, it just doesn’t work. The filter chain needs to be walked in one direction for request filtering and the opposite direction for completion processing and the previous design was only a singly linked list (and so was always walked in the same direction).

As I mentioned a while back, the interface that user code had to The Server Framework was somewhat jumbled and, in fact, consisted of three interfaces that were mashed together. I’ve been teasing these apart and in doing so have finally bitten the bullet and dived in and refactored the filtering interface so that it’s easier to use. The Server Framework has had a filtering interface for a long time, since around 2002 when I added SSL support for a client.