It seems amazing but the last time we did a release of The Server Framework was in 2021. Since then the mainline development of the framework has been pretty stable with no new bug reports. Most of the time the code doesn’t need a new release to handle minor changes in compiler version and often it’s easy enough for client’s to do these changes themselves. I’m planning a maintenance release, 7.

Recent release notifications

We’ve just found out that an email misconfiguration means that some emails to email addresses have been bouncing. This should be fixed now! Sorry about the inconvenience. If you have contacted us recently and not had a reply, please try again now!

Another release is coming...

We’ve only just shipped Release 6.6.5 of The Server Framework but we already have another release that’s just about to ship. This isn’t because some horrible bug has slipped through our testing, it’s because we’ve been planning to produce a ‘clean up’ release for some time. 6.7 is that release. Lets be straight here, 6.7 is a release for us more than for you. The aim is to simplify our build/test and release process, remove dead code whilst introducing no new bugs and removing no functionality that you rely on.

TLS 1.2 handshake failure for certificates signed with MD5

A while back a client of mine had an issue with a TLS 1.2 connection failing during the TLS handshake. We couldn’t see any issues with the code and if we only enabled TLS 1.1 on the server then the connection handshake worked just fine. Eventually we tracked the issue down to the fact that the certificate in use had been signed with MD5 and that MD5 isn’t a valid hash algorithm for TLS 1.

WSARecv, WSASend and thread safety

Last week I learnt something new, which is always good. Unfortunately it was that for over 15 years I’d been working under a misconception about how an API worked. TL;DR When using WSARecv() and WSASend() from multiple threads on a single socket you must ensure that only one thread calls into the API at a given time. Failure to do so can cause buffer corruption. It all began with this question on StackOverflow and I dived in and gave my usual response.

UDP flow control and asynchronous writes

I don’t believe that UDP should require any flow control in the sending application. After all, it’s unreliable and it should be quite OK for any stage of the route from one peer to another to decide to drop a datagram for any reason. However, it seems that, on Window’s at least, no datagrams will be dropped between the application and the network interface card (NIC) driver, no matter how heavily you load the system.

New client profile: Tricerat Inc. - Printer sharing

We have a new client profile available here for a client who uses The Server Framework in their Printer presence and print job transfer system. They use both the OpenSSL Option Pack and the SSPI Option Pack in their product. The ease of adding security and authentication which can communicate with a disparate selection of clients is one of the strong points of developing with The Server Framework.