I realised this morning that part of my “The life of a stream socket connection” document about the safe use of server callbacks in my server framework was wrong.
I said this:
At any time after a connection is established, including before you’ve had a chance to handle the connection establishment event, you might get a connection termination event.
and this:
Note that it IS possible that you could receive error, client disconnect, connection reset or connection closed events before or during the processing of the connection established callback.
The code in the last two articles in the “Practical Testing” series have contained a considerable amount of duplication. This came about for a couple of reasons. Firstly part 17 was a bit rushed and secondly it was useful to compare the CCallbackTimerQueue implementation with the CCallbackTimerQueueEx implementation. I’m also a firm believer that in this kind of situation it’s better to get both sets of code working independently and then refactor to remove any duplication rather than attempting to design a duplicate-free solution from the start.
As I mentioned here I’ve recently adjusted how socket callbacks are dispatched in The Server Framework.
Once you’ve written a TCP server or client you will find that you spend a lot of time dealing with the lifecycle of the connections that are created. You get to deal with a number of events which take place during a connections lifetime and, due to the way that the framework works, you can select just the events that interest you and ignore the rest.
The latest release of The Server Framework is now available. This release includes the following changes.
The following changes were made to the libraries.
Some whitespace changes to remove incorrect tabs. Admin Library - 5.2.3
Added a check for _WIN32_WINNT >= 0x0600 and JETBYTE_PLATFORM_SDK_VERSION < 0x060A as targetting Vista or later means we enable stuff that’s only available in the v6.0a Platform SDK.
Added The \ref AdminFAQ “Frequently asked project related questions” page.
Back in 2004, I wrote a series of articles called “Practical Testing” where I took a piece of complicated multi-threaded code and wrote tests for it. I then rebuild the code from scratch in a test driven development style to show how writing your tests before your code changes how you design your code. Since then there have been various changes and fixes and redesigns all of which were made considerably easier due to the original tests.
I started to document part of The Server Framework’s behaviour as I expect that a client will be asking questions about it in the near future. Whilst writing the documents I found myself writing this:
“It’s pretty easy to deadlock The Server Framework in complex servers if you don’t abide by the rules. Unfortunately, the rules weren’t documented until now and, although I knew them, it’s probably more accurate to say “I knew of them”.
I stumbled on Gustavo Duarte’s blog this week via this post about how lucky we are to be programmers.
The post that led me to his blog is good stuff and has had lots of linkage this week. The rest of the blog is also good stuff; I especially like the “Reality Driven Development” post which fits nicely with my “thin thread of functionality” way of designing software. I’ve always tended to design from the bottom up and my testing addiction has fuelled that somewhat; but I do still like to pop up to the surface on regular intervals and then drill down with a ‘spike’ of throw away code to make sure that the stuff that I’m building properly is actually what we need to build.
There was a change in release 5.2.1 of The Server Framework which has caused some issues with clean shutdown. This issue is also present in 5.2.2.
Prior to 5.2.1 the CSocketServer or equivalent object that did the bulk of the work with regards to connections could be destroyed whilst there were sockets that it managed still in existence. This wasn’t usually a problem but it meant that it was possible for a socket to make a callback to code that didn’t exist anymore; which is a Bad Thing.
Well, of course, the day after I released the 5.2.2 version of The Server Framework I get a bug report from a client using 5.2.1 listing a couple of memory leaks. One of them fixed in 5.2.2 and one not.
The leak that survived 5.2.2 is in CReadSequencingStreamSocketConnectionFilter::FilterSocketReleased() which currently looks like:
void CReadSequencingStreamSocketConnectionFilter::FilterSocketReleased( IIndexedOpaqueUserData &userData) { delete userData.GetUserPointer(m_userDataIndex); } and which should look like:
void CReadSequencingStreamSocketConnectionFilter::FilterSocketReleased( IIndexedOpaqueUserData &userData) { CInOrderBufferList *pBuffers = *reinterpret_cast<CInOrderBufferList *>(socket.
The latest release of The Server Framework is now available. This release includes the following changes.
This is the first release built using Compuware BoundsChecker and there have been some resource leaks fixed. The following changes were made to the libraries.
Admin Library - 5.2.2
Added JETBYTE_MINIMUM_SUPPORTED_WINDOWS_VERSION and JETBYTE_MINIMUM_SUPPORTED_NTDDI_VERSION to Admin.h. These are currently set to _WIN32_WINNT_WIN2K and NTDDI_WIN2K.
Added JETBYTE_PLATFORM_SDK_VERSION which you can use to tell the libraries which version of the Platform SDK you’re using.
