It seems that the latest changes to The Server Framework have managed to flush out a graceful shutdown bug that’s been floating around since day 0.
There’s this whole, complex, way of determining how a socket is shutdown and this whole clever thing that lets you decide if you want to do a graceful, lingering, close on an I/O thread or simply slam the door and risk losing data and, well, it doesn’t seem to work.
I’ve finally got to the point where my latest refactoring of The Server Framework can be merged back to the main development branch. The changes grew from just being a “remove inappropriate use of pointers where references would be better” to a complete pass through my TODO list and subsequent design adjustments. I also managed to have a good crack at a first pass through the “document the code with doxygen” item and the results of that can be found here.
Except of course, the refactored filters can’t actually be layered that well using the design that I outlined in the previous blog posting.
The main problem, the “too simple” part of the design is that, well, it just doesn’t work. The filter chain needs to be walked in one direction for request filtering and the opposite direction for completion processing and the previous design was only a singly linked list (and so was always walked in the same direction).
As I mentioned a while back, the interface that user code had to The Server Framework was somewhat jumbled and, in fact, consisted of three interfaces that were mashed together. I’ve been teasing these apart and in doing so have finally bitten the bullet and dived in and refactored the filtering interface so that it’s easier to use.
The Server Framework has had a filtering interface for a long time, since around 2002 when I added SSL support for a client.
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 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.
