My VoIP client has been stress testing the UDP version of The Server Framework and they had what they thought was a deadlock. It wasn’t a deadlock it was more of a lazy server… What seemed to have happened is that they had been thrashing a server with lots of concurrent datagrams and pushed the machine until it stopped receiving packets due to the resource limitations of the machine being hit (probably either non-paged pool exhaustion or the i/o page lock limit).
Robert Scoble, the “Microsoft Geek blogger”, has recently had a complaint that he only writes about Microsoft and he figured that he was in a rut and decided to get out of his rut by deliberately not writing about his usual topics of Microsoft, Google and Yahoo (GYM) for 100 posts… So, for the last 3 days he’s been writing about other stuff… There are problems with this idea though…
Whilst I’m ranting about the little things…
You still can’t create named versions of the .Net ManualResetEvent and AutoResetEvent, even in .Net 2.0. Wasn’t everything going to be fixed in Whidbey?
Of course, I realise that you can “simply” access the underlying Win32 API to do it, but a) why should we have to? and b) it’s not recommended that you do…
I guess the fact that the P/Invoke route isn’t recommended is the reason for the dearth of nicely packaged up solutions to this problem; surely anyone who needs this functionality would write an object that wraps it up nicely rather than doing it “long hand” like this?
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.
