I’ve been running a pair of 2TB Infrant Ready NAS NV+ RAID systems for a while now as on-site file server and off-site backup and so far I’m very pleased with them. I have one under my desk and one in my dad’s office and they talk over a VPN and keep each other in sync using rsync. The one under my desk acts as a file server for my development boxes and as a music server for my Squeezebox music players.

Charles Miller over at ‘The Fishbowl’ provides a cheat sheet to decode what us programming types mean when we describe the difficulty of solving problems…

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).

I’m fixing up my performance monitoring code and this uses shared memory to communicate between the perfmon extension DLL and the application. Since I’m tightening up security I decided to explicitly pass in the security attributes, which has a possitive knock-on effect to several of my Win32 tools classes which now also need to deal with security properly rather than just conveniently… Of course once you’re passing explicit security attributes around rather than simply passing 0 to the APIs you can get back some of the convenience of the not-needing-to-think-about-it style of security by passing in an “allow all” security descriptor.

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.