Socket Servers

The test certificates that shipped along with the OpenSSL server demo that I posted here have expired. I’ll post some new ones shortly.

Way back in mid November, before we dumped our building’s managing agent for being worse than useless and possibly stealing from us, I was working on some POP3 code. I had some down time today so I decided to drop back into it and see if I could move things along a little. In summary, having lots of tests helped… I haven’t done any development on the POP3 code for 3 months.

Surprisingly enough the Bluetooth server “technology preview” has generated quite a bit of interest from potential clients, which is nice. In a similar spirit, I’m making the compiled version of our server that uses the OpenSSL Toolkit available for download. This code uses our freely available IOCP server framework and adds SSL support using OpenSSL. We have an SChannel version in the pipeline for those of you who don’t want to have anything to do with OpenAnything…

So, what brought on those musings on complexity? There’s a bug in the recent public release of The Server Framework code. It’s in one of the example servers. Some code got snipped out and it shouldn’t have been and the result is a memory leak. The code in question doesn’t have tests, but that’s not the point, it would be hard to write automated tests that would have caught the problem due to the fact that I, as a designer, made an unchangeable decision for the user of the code.

I find that these days I prefer my complexity to be obvious. Things with hidden complexity aren’t any less complex, they’re just less obvious. If you make all of your complexity obvious then you know which pieces of code are complex and you can focus your attempts at simplification on the right places… Some of this comes from the testing that I’ve been doing; liberal use of parameterize from above means that an object that uses several services is explicitly given those services when you create it.

Following my tooth brush revelation about AcceptEx earlier in the week I found some time today to test out my ideas. The implementation went pretty smoothly. It was helped by the fact that I had a previous attempt at using AcceptEx floating around. It was helped more by the refactoring that I’d done recently and the fact that it was easy to take the tests I had for the listen/accept version of the socket server code and adjust them to work with the new AcceptEx version.

I’m making the compiled version of our Bluetooth server shell available for download here. The source is not available at this time. The zip contains a simple server that advertises the following Bluetooth profiles: OBEX file transfer, Serial Port, Dial up Networking, LAN Access Server and OBEX object push. The server requires working Bluetooth hardware that uses the XP SP1 stack. If you don’t know what this means then chances are, you don’t have it.

So there I was, cleaning my teeth, about to get into bed and suddenly I saw a reason for using AcceptEx… I’ve known about AcceptEx for ages, and even written an article about how to use it but I always thought that it just wasn’t something I needed to use in our servers. I’d latched on to the officially advertised reasons for using it and ignored the more subtle advantages…

I had one of those “Doh!” moments yesterday. In summary, always put the performance monitoring code in early, looking at a program’s vital signs as a jiggly graph can show up all kinds of unexpected things… The work on the gateway server that I’m currently building for a client has been going well but yesterday I had a weirdness develop. Very rarely a test would fail because the server would fail to respond to a request.

I’m in a bit of a quandary. I’m writing a class that does processing on a byte stream. You poke bytes in, it does stuff, it gives you bytes out. My quandary revolves around how it gives you the bytes… The processor operates in two directions, that is, there’s an inside and an outside. It processes data traveling from inside to outside and also from outside to inside. Poking a set of bytes into the processor in one direction may or may not result in bytes being output in that direction and may or may not result in bytes being output in the other direction.