Version 6.7 of The Server Framework was released today.
This release is mainly a code simplification release which removes support for legacy compilers and operating systems. See here for more details. However, there are some breaking changes where smart buffers have replaced buffer references and this causes function signature changes. In addition there has been considerable churn in the Streaming Media Option Pack with knock on changes in the HTTP library code which needed to be made more complete to deal with serving HLS streams.
So, it’s nearly a year since I first started noticing issues with VS2015 on my build servers. The bug in question now has an entry on Microsoft Connect and Google can help with some work arounds which don’t require turning the machine off and on again a random number of times until it works… There’s even a Visual Studio extension that fixes the issue for you (!).
I find it disappointing that this hasn’t been fixed, it’s a fundamental usability issue which seems to be causing lots of people lots of pain.
I hinted at the end of the last post that the 6.7 release might increase performance a little. Well, whilst the bulk of the changes in 6.7 are purely code cleaning and the removal of legacy support there is a fairly major functional change as well.
In most situations references or pointers to I/O buffers have been replaced with smart pointers. This change may cause some issues during an upgrade as you need to change some function signatures from IBuffer refs to CSmartBuffers.
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.
Version 6.6.5 of The Server Framework was released today.
This release is mainly a feature release with a few bug fixes.
As always, see the release notes here, for full details of all changes.
Bug fixes:
Bug fix to JetByteTools::Socket::TAsyncSocket::ProcessAndGetNextOperation(). We now wrap the body of the function in an exception handler and abort the connection with JetByteTools::Socket::ConnectionClosureReason::FatalErrorAbort if an exception is thrown during processing. This fixes a bug whereby the connection would otherwise hang in these situations.
We’ve been busy with lots of custom development work over the last few months. Working with Eonic Gaming on their server for the Turf Battles Triumphus 3D MMORPG. Working with one of our security company clients on their video streaming server, adding RTP over TCP and HLS streams to the RTP over UDP of the original design. Improving the performance and functionality of the pluggable server that we wrote for one of our other gaming clients as they scale out into the cloud.
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.
Version 6.6.4 of The Server Framework was released today.
This release is mainly a bug fix release for clients using WebSockets over SSL.
As always, see the release notes here, for full details of all changes.
Bug fixes:
Bug fix to JetByteTools::Win32::CallbackTimerQueueBase which prevents the timeout handle from ever being incremented to zero. It’s unlikely but possible. Bug fix to JetByteTools::Win32::CBuffer and JetByteTools::Win32::CLockFreeBuffer to make code take notice of when m_maxBytesToRead is set.
I’m looking at adding support for the TLS Application-Layer Protocol Negotiation Extension to The Server Framework as a precursor to looking into HTTP 2.0 support. This TLS extension is supported by both SChannel and OpenSSL. It’s relatively new (only having been included in SChannel since June 2014 (!)) but there seems to be no documentation on MSDN for the structures and how to use them to add the appropriate entries to the TLS handshake and then to select and validate the protocol of your choice… Searching today with Google for something like “SEC_APPLICATION_PROTOCOL_NEGOTIATION_EXT” just gives just the usual selection of hits to people who think it’s clever to run the Windows header files through their document generators and then publish the results on the web…
There should be a Developer Advocate position within Microsoft. They seriously need someone who doesn’t “Drink the Kool-Aid” who can step in and tell the Program Managers or Marketing bods or whoever it is who makes all the really STUPID decisions that the decision is stupid and that they should get back in their box and leave the developers who support the Windows ecosystem by building software that runs on it to just get on with their lives…
