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.
I’ve been putting together a sample server for a client that shows how to cleanly terminate a socket connection. This should have been a simple thing to do, but in doing so I’ve discovered some gnarlyness within The Server Framework and the result has been some new TODO items for the 5.3 release…
When you have an active TCP/IP connection that you wish to terminate cleanly you need to initiate a TCP/IP protocol level shutdown sequence by calling shutdown().
The latest release of The Server Framework is now available. This release includes the following changes.
All code now builds with VC6, VS2002, VS2003, VS2005 and VS2008. The VS2005 and VS2008 builds support x86 and x64.
This is the first release built using continuous integration and there have been some project file fixes to fix incorrect output directories, etc so that x64 and x86 builds can be done in complete isolation.
I’m still reading the Richter book, highly recommended even if you’ve read one of the earlier versions. In fact it’s possibly MORE highly recommended IF you’ve read one of the earlier versions… It seems that lots of things have changed a little, and some things have changed a lot. Unfortunately the book doesn’t detail the actual changes. Note to publishers; I’d PAY for a slim book that DOES detail the changes between the APIs that are being discussed…
Well, it’s about a month since I started running Cruise Control .Net and things have settled down somewhat now and I can almost go a day or two without tweaking my configuration or being tempted to fix issues in Cruise Control itself.
For those of you that haven’t been following along:
First I realised that the latest (1.3) release of Cruise Control .Net wouldn’t work for me without some hacking.
The free version of the socket server framework contained code that could cause a deadlock during connection closure if you also have a lock in your derived class.
There’s a lock taken out in CSocketServer::Socket::IsValid() that isn’t really required and which can cause a deadlock if you have your own lock in your derived class which you lock in OnConnectionReset() or other server callbacks and which is also locked when you call into the framework via Write() or other calls.
There’s a new release of The Server Framework’s Free Framework, here. This includes the bug fix that was mentioned here.
I’m working on the next releases of The Server Framework, and I now have continuous integration (of a sort) so my build and test problems are being minimised… BUT… Keeping Visual Studio 6 support in the framework is becoming a bit of a mission. It’s mostly simple template stuff that fails but I find that I keep having to work around VC6 issues.
I’m proposing to drop VC6 support from version 5.
I’ve been tracking a bug for a client recently and yesterday I got a remarkably similar bug report from one of the users of my free socket server framework. The client’s code is pretty old and was originally based on a server framework that was based on the free version of the code and it hasn’t been upgraded to the latest version yet. The bug in my client code is also present in the latest (Feb 14 2006) version of the free socket server framework - found here.
