Every now and then I come across a situation where encapsulation has been taken slightly too far. Usually, or at least most recently, these over encapsulated designs have had problems because they’ve blocked access to an event handle. It’s great to wrap up a bunch of Win32 primitives into a nice coherent class but if you expose a method that allows the user of the class to wait for something to happen then it’s probably also a good idea to expose a handle they can wait on as well.

Recently I finished developing a high performance ISO-8583 financial transaction authorisation server for a client using The Server Framework and whilst I was running the final black-box tests against the server I realised that these particular tests were dependant on the system date of the machine running the server. The server uses the current time and date to make some decisions on whether it can authorise a particular transaction or not.

Ian Griffiths has just written a nice piece on profiling .Net code and why the obvious things that people do are often very wrong: “Unfortunately, lots of developers just love to go off on micro-benchmarking exercises, where they write about 10 lines of code in a variety of different ways, and discover that one runs faster than the rest. (Or worse, one looks like it runs faster than the rest when running in the profiler.

Alan Green doesn’t like the word “manager” used as a class name suffix. His point seems to be that “manager” is imprecise and instead he suggests a list of alternative suffixes with more precise meaning; though they seem to be rather contrived and smack of using new words just for the sake of it to me. For example using “Herder” rather than the more usual “Collection” (PolicyHerder, hmm…) and using “Bucket” as a pretty non standard replacement for “Pool”.

“Because of a subtle bug called a “race condition,” a quick-fingered typist could accidentally configure the Therac-25 so the electron beam would fire in high-power mode but with the metal X-ray target out of position. At least five patients die; others are seriously injured” History’s Worst Software Bugs, from Wired. I’m pretty careful about how I write code and I like to have my tests in place and, on the whole, I write pretty reliable code (most of the time) but I’m still glad that I don’t work on stuff that’s likely to cost lives if it goes wrong…

Jochen Kalmbach has discovered a problem with dynamically linked applications built with VC2005 running (or not running!) on NT 4. I guess this isn’t going to bite that many people… Read about it here.

One of the good things about the server performance testing that I’ve been doing recently is that I have been able to witness some rather rare failure conditions in action and seen how The Server Framework handles them. When using IO Completion Ports for asynchronous IO you get notifications when reads and write complete. Read completions are obviously an important event, it’s where you receive incoming data. Write completions, on the other hand, are often viewed as less important.

A long time ago when I wrote my first article on high performance TCP/IP servers for Windows using IO Completion ports over on CodeProject I complained that “Also the more complicated examples, ones that used IO completion ports for example, tended to stop short of demonstrating real world usage. After all, anyone can write an echo server… “ Yet here I am, three and a half years later with a huge collection of different kinds of echo server.

For the last week or so I’ve been working on measuring and improving the performance of The Server Framework. 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. This week I’ve had several potential new clients asking about performance numbers for various aspects of the system and so I thought it best to do some measuring.

This is quite nice, a whole list of finely targetted RSS feeds for Knowledge Base articles for various products.