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.
We’ve just found out that an email misconfiguration means that some emails to serverframework.com 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!
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.
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.
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.
We have a new client profile available here for a new client who is using The Server Framework to power their MMORPG game server.
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.
We have a new client profile available here for a new client who is using The Server Framework for secret things that they can’t tell us about!
We have a new client profile available here for a new client who selected The Server Framework to replace its previous networking layer in an M2M server which deals with 20,000 devices connected via GPRS.
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.
