I’ve been having some problems with Explorer hanging when opening “My Network Places” on some of my machines. Some work fine, some hang. Most annoying. I’ve been trying a few things over the past few weeks (as and when I get a hang and as and when I feel like it), but nothing has seemed to have fixed anything, until this morning…
I’ve recently adjusted my networking kit and now have a couple of UPnP devices floating around and it’s useful (but not essential) to be able to connect to them directly in Explorer.
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 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…
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.
