I’ve just had a memory leak in the SChannel SSL code reported by a client. It’s a fairly fundamental leak has highlighted an omission in the mock buffer allocators that I use to test this kind of code; it also highlights that the SChannel code was somewhat rushed to release before Christmas.
I’m working on a fix now and the changes will be included in the 5.2.5 release of the SChannel code.
The latest release of The Server Framework is now available. This release includes the following changes.
The following changes were made to the libraries.
Admin Library - 5.2.5
No Change. C++ Tools Library - 5.2.5
No Change. Win32 Tools Library - 5.2.5
No Change. I/O Tools Library - 5.2.5
No Change. Socket Tools Library - 5.2.5
Fixed a bug in the dispatch of JetByteTools::Socket::IStreamSocketCallback::OnConnectionClosed() from within JetByteTools::Socket::CStreamSocket::OnFinalRelease(). We now ensure that the socket’s reference count is valid before calling the callback method.
A client has just reported a bug in version 5.2.4 of The Server Framework. The bug has, possibly, been present since 5.2.2 and relates to the dispatch of OnConnectionClosed() callbacks when a socket is released.
If a socket is still valid, i.e. it hasn’t been previously closed, when the socket is released for the last time then part of the clean up is to close the socket. Your code is informed of this by the OnConnectionClosed() callback being called.
In one of the original articles that introduced The Free Framework I mentioned that the original design was possibly lacking in that it required a critical section per connection and that this could be resource intensive. Shortly after I changed what was to become The Server Framework to use a lock factory which passed out instances of critical sections based on a hashing algorithm applied to a key that the caller supplied.
The latest release of The Server Framework is now available. This release includes the following changes.
The following changes were made to the libraries.
Admin Library - 5.2.4
We no longer support Visual Studio 6.
We now compile with /Wall (in VS2005 and later) to enable all warnings, even those that are disabled by default. Of course this means that the list of warnings that we disable in Warnings.h has grown a little.
I had reason to run my deadlock detection tool on a server built with an old version of The Server Framework as I needed to make changes to the server’s locking strategy and I wanted to make sure that I didn’t cause any lock inversions. The tool worked well and I tweaked it a little more to make it run faster (considerably faster actually!) and report better… The speed increase was pretty dramatic and consisted of adding a new option to the tool to prevent it from monitoring lock operations for locks that we have never seen created.
As of release 5.2.4, which is due for release in December, we will no longer support Visual Studio 6 builds of The Server Framework. I’ve recently had to deal with some weird multi-threaded problems for a client and upgrading them from Visual Studio 6 to Visual Studio 2005 seemed to remove several STL related issues. I then did some research and decided that it simply wasn’t worth supporting the old compiler any longer if the first thing that I’d do if a client had problems would be to recommend they upgrade the compiler…
I’m currently working on an SChannel version of the asynchronous SSL connector code that we use to provide SSL support in The Server Framework. This will eventually be an alternative to the existing OpenSSL support that we currently provide and should prove useful for people who want a tighter integration with Microsoft’s Certificate Stores than our current OpenSSL support provides.
In many ways the SChannel version of the code is more complex to implement than the OpenSSL version as the OpenSSL SSL_CTX context object deals with data accumulation and record splitting internally; you just push bytes into it and it eventually pushes cleartext out at you.
I’ve had a few questions from users and potential users of The Server Framework about how it compares to other available frameworks. One such framework is ASIO.
The first thing to realise is that The Server Framework and ASIO are very different both in design and functionality. ASIO’s strengths are that it’s cross platform, it provides low-level asynchronous I/O and that it uses a modern C++ design (i.e. lots and lots of templates and ‘interesting’ call stacks).
I’m in the process of adjusting the asynchronous file log that we use in some of our servers. The log works well and write performance is good for a variety of reasons that I deal with here. The current changes are mainly due to the fact that we have some clients who want to automatically create a new log file every so often whilst the server is running. This hasn’t been a requirement before because most of our servers don’t continually spew out log data.
