The latest release is really just a bug fix and compiler compatability release. The code now supports Visual Studio 2005 (as well as VC6, Visual Studio .Net (2002) and Visual Studio 2003). I've fixed the memory leak bugs that were present in the
ThreadPoolLargePacketEchoServer sample and worked around the
iostream leak that's present in the Visual Studio 2005 version of STL. I've also included a set of build configurations for the basic echo server that builds the system with STLPort rather than the standard Visual Studio STL.
The bug fixes are reported here. Please note that this version of the code still suffers from poor handling of low resource issues; see here for the kind of things that could leave you with an unresponsive server.
I expect that this will be the last release of the free code. Though, I expected that last time too ;)
The example servers are as follows:
- EchoServer - the basic example server that simply echoes back the data it receives.
- PacketEchoServer - a server that echoes back complete packets, each packet starts with a length indicator. This is slightly more "real world" as many protocols have a header that indicates the length of the packet that follows.
- SimpleProtocolServer - a server that operates on variable length packets that are terminated with a
\r\nsequence. This is the other common way to determine how much data the client is sending in one "command". Things like SMTP and POP3 use this style of protocol.
- SimpleProtocolServer2 - a version of the SimpleProtocolServer above that uses a separate thread pool to actually process the requests. This is potentially useful if the requests will block (such as requests to a database, perhaps). If you have X IO threads and all of them are engaged in a blocking activity at once then your communications subsystem stops responding! This server architecture avoids that problem by passing complete command packets to another thread pool via an in process FIFO queue so that the blocking operations do not adversly affect the communications subsystem.
- ThreadPoolLargePacketEchoServer - a really contrived example that I've only ever used to demonstrate some theory. This server is a packet echo server that runs the communications subsystem with a small buffer size and yet requires that the server only echo packets that do not fit completely in the small buffer size. This means that the server copies data from the IO buffers into "transfer buffers" that it then passes to another thread pool to echo. I've never found a use for this architecture but it might be useful if your protocol uses buffers that are 99% one size and occasionally bigger...
I recommend using the simplest server architecture that you can. That means you're probably looking for something based on either the second or third example. If you access a database or other slow, blocking, non async device then you should probably use a variation on server four. If you think you really need to use the fifth server as a base get in touch and I'll talk you out of it ;)
Due to how I have my CVS repository structured and how I like to work on servers in isolation (I sometimes work on multiple servers at once and like to build/rebuild them without affecting other work in progress), each server has its own copy of the "tools" library.
Please report any bugs that you may find via email.
You probably need the platform SDK to build the code. See disclaimers on the previous release and on the original code project articles for more details.
If you need more than this free code provides then take a look at the rest of ServerFramework.com for details of The Server Framework a licensed and fully supported high performance server framework.
Updated: 18 Feb - fixed a bug in the new version of
Updated: 25 Feb - added the files for the
CStringConverter class so that the fix I added on the 18th actually compiles!
Updated: 27 Oct - bug fix for
CSocket::InternetAddress - see here for details
Updated: 14 March - link to the differences between this free version of the code and the licensed version: see here.
Updated: 10 Jan 2008 - bug fix for the write sequencing memory leak and data loss - see here for details
Updated: 12 Jan 2008 - bug fix for the potential deadlock bug - see here for details
Updated: 21 April 2009 - see here for a bug fix for a connection termination issue that leaves I/O threads unresponsive (note that this fix is not currently included in the code on this page.Updated: 4 October 2010 - moved the code to ServerFramework.com