Socket Servers

The refactoring and testing of The Server Framework code has gone pretty well. It’s not complete but at least we have some tests now and the code is broken down into slightly more cohesive lumps… Once the tests were in place and working we had to integrate the changes with the various projects that use the library; each of these projects pull the library in slightly different directions so the integration took a while.

I get quite a bit of feedback about the socket server code but I don’t really know what people are using it for. So, if you can, leave a comment or drop me a mail and tell me.

After breaking the socket server into more manageable chunks I started writing the tests. CAsyncSocketConnectionManager is pretty easy to test, it only has one public function; Connect(). So, what exactly do these tests look like? I don’t use a unit testing framework at present, I haven’t found a need. Whilst NUnit and JUnit are great I don’t feel that the C++ version adds much as C++ doesn’t support reflection and that’s where these frameworks really seem to win.

I’m writing tests for some code. I have a function that I’m testing that looks something like this: bool CAsyncSocket::Read(bool throwOnFailure = false); If C++ allowed us to overload a function call based on return type then we wouldn’t need the horrible throwOnFailure wart and the compiler could pick the right version depending on if we try to use the return value or not… So a call like this: bool ok = pSocket->Read(); would return errors and a call like this: pSocket->Read(); would throw exceptions…

So I have some time on my hands and I’ve decided that The Server Framework code could do with some tests but before I can do that I need to refactor because the code was written before I became test infected and, well, it’s not as good as it could be… Step one, as always, is to work on decoupling the code to the point that it’s easy to test. This generally involves breaking the code apart into more cohesive chunks and then writing tests for the chunks.

I have a couple of days to myself. We’ve just shipped some code to a client a couple of days ahead of schedule and we’re waiting to recieve a purchase order from another client so I find myself without any client work to do. I’ve decided to try and refactor The Server Framework code that we’re using a lot right now. Whilst working on the code that we’ve just shipped I realised that the new code I was writing was much easier to test than the socket server library that formed a major part of the project, so now that I have some time I’m going to try and rectify that.

And this is why I hate TDD, testing is a great thing. But testing too early is bad, and you are obviuosly doing that. First you need to know what your code has to do in full. For instance even if you wanted to have both sync. and async. APIs (I personally abhore sync. APIs due to non-scalability) the obvious implementation is to have something like… James Antill - in a comment on my Tangled Testing entry.

I had a bit of spare time today so I finished the POP3 server integration. It went nice and smoothly and I tested the result with telnet and Outlook. During the Outlook testing I noticed the ’this server requires a secure connection (SSL)’ checkbox. I hadn’t been aware that there was a standard port (995) for accessing a POP3 server over SSL. My server currently only supports port 110 for unencrypted transport but I’ve got code that can turn my server into an SSL enabled server… Looks like it’s time to harvest that into The Server Framework.

The latest release of the free version of my asynchronous, windows, IOCP based, socket server framework can now be obtained from here at ServerFramework.com. I’ve updated the code for two more of the socket server articles. More merging, project file updating, and testing… [NOTE: This code leaks when adjusted to build with Visual Studio 2005. This seems to be due to a bug in VS2005’s STL. See here for a workaround.

The latest release of the free version of my asynchronous, windows, IOCP based, socket server framework can now be obtained from here at ServerFramework.com. For some time I’ve been promising to update the socket server articles to use the latest version of my code. Today I finally updated the code for the first article. I’m going to update the article itself soon, but in the meantime I’m posting the new code here.