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.
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.
Version 6.6.3 of The Server Framework was released today.
This release is mainly a bug fix release but it also adds support for Visual Studio 2015 and Windows 10 (though we don’t explicitly use any Windows 10 APIs). There are quite a lot of small changes due to us running Gimpel Lint over the code. Most of the changes will have fixed potential issues rather than issues that have actually been reported.
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.
The 7.0 release of The Server Framework, which is likely to be released early next year, will no longer support Visual Studio 2005 or Visual Studio 2008.
The 6.6.x releases will be the last to support these compilers.
Please get in touch immediately if this will be a problem for you.
The 7.0 release of The Server Framework, which is likely to be released early next year, will no longer support Windows XP or Windows Server 2003.
The 6.6.x releases will be the last to support these operating systems. Release 6.6.3, is due shortly and is a minor bug fixing release. We may release subsequent 6.6.x bug fix releases but no new development will occur on the 6.6 branch.
Removal of support for these operating systems allows us to clean up the code considerably and to remove lots of code that’s required purely to work around ‘interesting’ twists in various Windows APIs pre-Vista.
We have a new Option Pack, The Streaming Media Option Pack. This allows you to easily add streaming of H.264 and MPEG audio and video to your clients and servers using RTSP, RTP and RTCP.
With more and more Internet Of Things devices supporting rich media streaming for remote monitoring it’s becoming essential to have the ability to manage these media streams within your device management servers and clients. Whether it’s recording device streams for later analysis or arbitrating between multiple clients and devices, manipulating streaming media is becoming more and more important.
