Of course, once I’d teased apart the callback interface so that it was separate, clear and easy to use and document I realised that it was, in fact, 3 interfaces all jumbled together. They’re actually quite easy to spot, there are all of the callback functions that start with OnXXX (and a couple which don’t!), there are the filtering functions and there is CreateListeningSocket() call. All three sets are used by different kinds of user.

After spending some time cleaning up and refactoring away the need to derive from concrete classes in the Win32 and IO libraries that make up The Server Framework, I finally reached the Socket library and applied the same transformations to the interfaces there. This is actually where I hoped to get most value from taking classes that required you to override virtual methods in a derived class and replacing them with explicit virtual callback interfaces that you need to implement.

I’m continuing to work through my list of things to do for The Server Framework (and all the libraries that support it) and I’ve recently got to the ‘set up Doxygen and do a bit of documentation’ item… I’m a firm believer that code should be documented once it has stabilised; I don’t tend to write many code comments as I prefer to try and make the code as self documenting as I can but for a tool like Doxygen to be worth using for more than just the pretty pictures it’s best to add some comments to explain what things are and how they hang together.

It wont come a surprise to anyone who has read this blog for a while that I disagree with much of what Simon Sebright has written about asserts in the latest issue of the ACCU’s Overload magazine… I’ve stated my case far too many times to go through it all again, but, it would be nice if he’d explained why he doesn’t like using references when a pointer argument cannot ever be null, especially as he then takes a stance that says, in his view, a pointer argument SHOULD NEVER be null…

We’re engaged in ongoing work with our Industrial Control Client. Refactoring and redesigning the TCP connectivity layer of their industrial device control system and refactoring and multi-threading a DDE connectivity component. Len is also designing and developing a high performance data acquisition system that connects as a client to their monitoring server and streams data to a SQL Server database for later analysis.

I’m in the middle of making some changes to The Server Framework, working through my list of things to do whilst I get my head around my next project; some LSP development… The current change is one that I advised others of some time ago; avoid unnecesary optionality. It’s quite a sweeping change as all through the framework I originally used pointers to socket objects and data buffers when, in 99.

The work on the CLR hosting socket server example is going pretty well. I now have a server that can pass server notifications to managed code that either runs in an AppDomain per connection or within a single AppDomain (depending on how isolated you want the user code to be). I think I’m pretty much there as far as what I want to demonstrate is concerned; it works and the line between managed and unmanaged code is likely to vary depending on a client’s particular requirements so there’s little point in extending the example code any further.

My investigations into CLR hosting are going well and today I built an echo sever based on The Server Framework and my CLR Hosting helper library. The idea is that the server can deal with the network IO and then hand off the ‘real work’ to some .Net code. So far the integration is going pretty smoothly….

People often ask me what the difference is between the free code that’s available on this website and the licensed version; this is what I reply… Please note that the most up to date information on the licensed version of our high performance, super scalable, IO completion port based networking code will always be available from the dedicated website for The Server Framework. The latest version of The Server Framework is available in source code form, the same as the free version, but includes many new features , performance improvements and bug fixes.

The Server Framework now includes UDP multicast. There are a couple of new examples; a server that joins a multicast group and a client that sends to a multicast group.