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.

Something that I find myself wanting in a debugger from time to time are breakpoints that only fire if the code has been entered via a specific route. You know the problem, you’ve tracked a particular issue down to one specific call sequence that occurs at a specific point in the code. The line you want to break on in this instance is also hit a lot via other routes that you don’t care about.

It’s now around a month since I started shifting the bulk of my source code from CVS to Subversion. In that time I’ve move most of my internal use code, and a couple of clients. I’ve done several client releases and developed several new features for The Server Framework on isolated development branches which have then been merged back in to the main trunk. I’ve also updated my continuous integration server to use the new source code repositories and, generally, just got on with it and lived with the new system.

I’m downloading the Windows 7 Beta from MSDN Subscriber downloads right now and the new Microsoft File Transfer Manager appears to be very very crap. The MSDN site insisted on updating the file transfer component before I could download and this version seems to stop every few minutes with errors about web server headers being missing. I have no proxies of my own that could be causing problems so I assume it’s a wider problem than just me… Anyway, it’s a pain that I have to keep hitting the Resume button ever few minutes…

We’ve been engaged to build the initial version of a smart valve monitoring server for Eltav using The Server Framework. Len will kick start their team’s development by putting together a custom server shell which deals with the basics of their requirements and will introduce their developers to The Server Framework’s code.

Our Online Gaming Client has engaged us to continue developing the C++ side of their server system for them on an ongoing basis. This is to support new functionality and to aggressively improve existing performance.

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.

Converting a numeric type to a string format in C++ is one of those problems that was ‘solved’ a long time ago. The ‘standard’ method usually involves streaming the type to be converted into a std::stringstream and then extracting the resulting string representation. Something like this, perhaps: #include<iostream> #include<string> #include<sstream> using namespace std; string itos(int i) // convert int to string { stringstream s; s << i; return s.str(); } int main() { int i = 127; string ss = itos(i); const char* p = ss.

The CVS to SVN code migration is going well. As recommended by a commenter I’ve switched from using a script to pull my tools libraries from their repository into The Server Framework examples build tree to using svn:externals. This works nicely and plays well with branches and tags (as long as you remember to update the svn:externals definition on your branch or in your tag so that it points to the correspondingly tagged version of your externals (but this would have been the same if I were using a script).