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.

I’ve finished the write completion driven outbound data flow control connection filter that I started work on a while ago. This provides a way to deal with the problem of having more data to send to a client than the client can receive within a reasonable time. Rather than simply continuing to send and building up a massive amount of buffered data in the TCP/IP stack the connection filter keeps track of write completions and begins to buffer data for you when there are ’too many’ write operations outstanding.

Back in December and January I was working on the initial phases of a system to allow the development of custom Excel worksheet functions in managed code using the Excel XLL ‘C’ interface (Excel4v). Phase 1 finished with us having a pretty workable system that the client could go live with. The only problem was that we skipped the key ease of use part of the project due to time and budget constraints.

As I said in my recent posting about Data Distribution Servers, “Next on the list is writing a more focused server and clients.”. Tick. I started out by writing the data feed. This was a simplified version of the echo server test harness that I’d extended to use a controllable TCP receive window. The data feed is just a client that generates random data in packets that have simple header, length, sequence number, type and sends it to the server that it’s connected to.

I really really really hate the error that I sometimes get when trying to copy a file from my Vista box to my NAS: “The mounted file system does not support extended attributes”. With the options to “Try again” or cancel. I suppose the “Try again” option is just in case the mounted file system changes its mind or the file somehow decides that the extended attributes that it’s somehow acquired aren’t actually required…

Many of the servers that are built with The Server Framework are for high number of connections and low data flow situations and as such that’s where the focus has been on the framework development and testing. As I’ve shown in the past, we can easily deal with 70,000 concurrent connections with various real world traffic flow patterns and have various test tools that can stress these kinds of servers. As importantly it’s easy to place a limit on the number of connections that a server can handle so as to protect the server (and other processes on the same machine) from resource limits (such a non-paged pool exhaustion).

It has been a busy couple of weeks for me. I’ve been working on an ISO 8583 based transaction server for a client and I set myself some fairly tight deadlines. I actually developed the first version of The Server Framework for another ISO 8583 transaction server that I developed for this client back in 2002. It’s interesting to look back at the original code and see how the framework has evolved (see here for the latest version), it’s also nice to know that the first server is still running nicely and providing customers with the ability to top up their pay as you go mobile phones at PayPoint outlets.

Last week I mentioned that some of my tests for my Win32 Debug API class had suddenly started failing. It seems that I was right and the changes are due to some .Net fixes that have been rolled out recently. The code runs and the tests pass if I run on a clean instal Vista x64 VM and fail on my day to day development box. It seems that my plan to “stick a breakpoint in mscoree.