Harvest Time

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 SSL code was developed for a client; we retained the IP rights and have subsequently sold it on a few times. It takes the publically available socket server code and slips in a shim that does SSL encryption on the socket using the OpenSSL toolkit. It’s quite neat, even if I do say so myself ;). From the application programmer’s point of view it just works. You say you’re on an SSL link and set a few parameters in the server and that’s it. Everything you write out goes out encrypted and everything that comes in is decrypted before being given to you. Your first write can kick off the required SSL handshake and rehanshakes, etc, all happen at the layer below you; you need neither know, nor care.

Unfortunately, although most of the code that wraps the OpenSSL toolkit in a ‘JetByteTools’ friendly way is in a tools library the actual server shim isn’t. The original code grew from my Windows Developer Journal article on integrating OpenSSL with MFC’s CAsyncSocket. This was adjusted so that it didn’t use MFC types and so that it could work with the IO Completion port model of asynchronous sockets that The Server Framework uses. The wrapper library has been used in a couple of projects but the server shim has been different in each…

The first project to use the SSL server was, as usual, a simple packet echo server. This worked with an MFC client to demonstrate the server as a proof of concept thing; just add business logic… The second project was the poker game project. This server could operate concurrently in both secure and insecure modes; listening on different sockets. Because the code above the transport layer was the same for both types of connection we added a level of indirection so that we could deal with both SSL and plaintext transports in the same way; you can write a server with business logic and support both types of connection without duplicating any code. This is the code I now need and it’s not yet part of the framework…

All of our libraries tend to grow by harvesting working code from systems when we get to the point where the code is needed in another system. We don’t set out to write reusable code, we set out to write working code. However, sometimes the working code is useful ;) and we find that we’d like to use it again in another project. At this point we harvest the code into a library and adjust it so that it works with both projects. Of course not all code can, or should be harvested like this, but given the DRY principle (Don’t Repeat Yourself) ;) we find it works best to take the time to harvest useful code where appropriate so that we have less code to maintain…

So I need to harvest the SSL server shim. This entry was because I didn’t fancy starting on the actual work of doing it… ;)