I’ve spent some time over the last few days playing around with my CLR hosting socket server example. I had stalled on a piece of client work, I’ve got a bit of a head cold at the moment and my brain just wasn’t in the right place for what I was supposed to be doing so I picked up one of more interesting the items on my todo list and took a look at that instead… The bulk of the work flowed nicely but then, just at the end things stopped working for no apparent reason… I’d done what was suggested in the book, the code compiled, the CLR called into my host in the right way and then I got a security policy exception… Hmmm.
I’ve just fixed a bug in the latest version of The Server Framework (v5.1 - if you dont have docs and a version number then you’re < 5).
The probelm was that I was being fractionally over-zealous in making things easy for the user… CStreamSocket has a RequestWrite() method that takes a BYTE * and a length. Originally this used to fail if the length was more than the size of a buffer.
Around a week ago I started looking at rewriting my performance counter library so that it worked on Vista. That work is almost complete and I’m at the stage where the new library does everything the old one did but there’s a list of ’nice to have’ new items that I haven’t completed yet. The work was reasonably easy once I got into it. I wasted an afternoon or so trying to understand the original code that I’d hacked a little way back in 2000 and eventually gave up and went to the documentation (and the book from whence the original code came).
So, back in June I discovered that my performance counter library code didn’t work on my new Vista x64 development box… The problem seems to be that the code has always been doing things in an undocumented/unsupported way and it’s only now that the old way doesn’t actually work at all any more…
I think I know what I need to do to fix the counter installation problem, use the wonderfully unixy named “lodctr” program (or the API alternative) to load the strings for the performance counters rather than simply shoving them into the registry myself… That means that the library code I have needs to be changed so that it writes out the appropriate files (an .
I’ve been doing some work for a client on their reliable UDP implementation. It’s been interesting stuff. They had picked out a ‘best of breed’ open source, reliable UDP protocol implementation (ENet) which was in ‘C’ and integrated it into their server that was written in C++ with my framework. Unfortunately the ‘C’ API assumed a synchronous ‘pull’ model for the communications and The Server Framework gave them an asynchronous ‘push’ model.
In the past I’ve mentioned my lack of enthusiasm for the normal ‘debug trace’ files that some systems seem to include… I pretty much consider them a design smell… But, some of my clients seem to like them and over the years I’ve been asked to provide high performance logging systems so that they can spew random messages to files and still run at a reasonable speed. I’ve written and adjusted an asynchronous file writing log file class a couple of times now and it finally ripened to the point where it was time to harvest it.
The x64 port of The Server Framework is going well. I’ve run the tests for the OpenSSL servers and things are looking good there; this is always an important stage to get to for me as these servers and their tests really thrash the framework and are good at shaking out any bugs that might be hiding…
So, now I’m faced with the monkey work of adjusting all of the other example servers to build cleanly on all platforms and (in addition to the x64 work) to support either IPv4 or IPv6… My problem is that I now support 5 compilers; VC6 through VS2005 + x64 and, since both I and my clients like being able to work in the IDEs, this means 4 project files to maintain per example.
Whilst The Server Framework has supported IPv6 for a while now I haven’t really used the functionality a great deal. My previous development box didn’t have IPv6 installed and so I never really got around to playing with it. Since my new box has IPv6 installed and since porting, building and testing can become a bit dull after a while I’ve spent a little time this afternoon playing with making sure the example servers are fully IPv6 aware, and, in fact, address type agnostic.
I’ve been aware that there was a ’need to run as Administrator’ issue with some of my server examples for a while; only the ones that installed/removed performance counter dlls or installed/removed themselves as Windows Services. The service installation problem was obvious, you got a message box saying that the user had insufficient rights and now, on Vista, this message box lets you try again and it relaunches the application with the “run_as” verb and you get a chance to run it as Admin… The performance counter issue seems more complex.
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”.
