There’s a bug in the TCP OOB (out of band) data handling code in all versions of The Server Framework from 6.6 through to 7.4. This issue manifests as a purecall during socket destruction and is due to a race condition during the release of the last two references held on a socket. If you don’t use OOB then a simple work around is to comment out the following in TAsyncSocket.
Version 6.9.2 of The Server Framework was released today.
This release includes changes to support Visual Studio 2017 (15.9), Visual Studio 2019 (16.2), design changes to the PerfMon tools library to improve performance and some bug fixes.
As always, see the release notes here, for full details of all changes.
Bug fixes:
Bug fix to JetByteTools::Win32::TimeChangeNotificationMonitor and JetByteTools::Win32::CSystemShutdownMonitor so that we don’t truncate the pointer passed SetWindowLongPtr(). Truncation was rarely occurring to just the top bits.
A bug has been discovered in Release 6.7 in the code that deals with TCP socket writes that involve more than a single buffer. These ‘multi-buffer writes’ are writes that involves either a buffer chain or a block of data passed as a pointer and a length where the length exceeds the size of the buffer allocator that the connection is using.
The bug prevents the ‘multi-buffer write’ from being executed as a single atomic write at the network layer and so can cause corruption of a TCP data stream if multiple sockets are writing to the same connection concurrently.
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.
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.
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.
I’ve just found and fixed a bug in version 6.6 of the OpenSSL Option Pack which relates to how we deal with outbound connection establishment errors. Changes in 6.6 mean that the OpenSSL ‘connector’ holds a reference to the socket whilst the SSL connection is active. The bug prevents connections which fail to be established from closing and causes a socket leak.
Note that this is ONLY for outbound (client) connections that you establish with The Server Framework.
I’ve just found and fixed a bug which has been present in The Server Framework from the very beginning. The problem affects connections which are “sequenced” and which have had more than 2,147,483,647 writes performed on them. The observant amongst you will be thinking that it’s a counter wrap bug and you’d be correct. The annoying thing for me is that the code in question has unit tests which explicitly test for correct operation when the sequence number wraps; the tests pass but the bug is still there.
