The C++ framework for developing highly scalable, high performance servers on Windows platforms.

Release Notes - Socket Tools Library


You might also be interested in the release notes for the libraries that this one is built on:


Version 7.4
  • Remove support for Visual Studio 2015.
  • Remove deprecated functionality.

Version 7.3
Version 7.2
  • Removal of manual "#define include guards" now that all supported compilers support pragma once.
  • Removal of out of date lint directives.
  • Added support for Visual Studio 2022 Preview.

Version 7.1
Version 7.0
  • Major changes due to preparations for multi-platform support. Addition of CoreTools library which contains all cross platform code that was previously in Win32Tools.

Version 6.9.5
  • Added support for Visual Studio 2019 (16.5 - 16.9).
  • Updated project files to make release build optimisations consistent.
  • Rationalised precompiled header usage.
  • Removed unrequired includes.
  • Began to move towards removing JetByteTools\Win32Tools\Utils.h by splitting it into more functionally cohesive headers.
  • Changes to avoid explicitly catching JetByteTools::Win32::CSEHException now that it derives from JetByteTools::Win32::CException.
  • Added JetByteTools::Socket::CDebugLog which will form the basis of a new debug trace system that allows trace messages from the framework, and client code, to be configured at runtime.
  • Bug fix to JetByteTools::Socket::CFilterDataBase which prevents reference leaks.
  • Bug fix to JetByteTools::Socket::TStreamSocketConnectionManager<>::AsyncConnect() where we were failing to call ConnectionCreated() on the connection creator and this meant we weren't limiting connections correctly.

Version 6.9.4
Version 6.9.3
  • Fixed issued raised by Resharper++
  • Changed include path separators from \ to / so as to support compilation on Linux using CLANG and GCC
  • Fixed case of include file names to aid portability.
  • Migrating code towards 'modern C++' idioms.
  • Suppress warning C4355 "'this': used in base member initializer list" in Warnings.h and remove per file suppressions. We just use this idiom far too often for it to be a special case.
  • Added support for Visual Studio 2019 (16.3).
  • Dropped support for Visual Studio 2013.

Version 6.9.2
  • Added support for Visual Studio 2017 (15.6 - 15.9).
  • Added support for Visual Studio 2019 (16 - 16.2).
  • Removed JETBYTE_DATAGRAM_SOCKET_READS_CONTAIN_SEQUENCE_NUMBERS as the concept was broken and the client for whom we did it found they didn't really want it.
  • Added GetIdentifierA() to all socket code and made GetIdentifier() always available rather than conditional on some debug traces being enabled.

Version 6.9.1
Version 6.9
Version 6.8
  • Made pragma once unconditional in headers.
  • Fixed issued raised by PC-Lint Plus.
  • Fixed issued raised by CppDepend
  • Fixed issued raised by Resharper++
  • Fixed issued raised by Resharper++
  • Use override rather than virtual for implementations of virtual functions in derived classes.
  • Changed JetByteTools::Socket::CAddressRenderer::AsString() so that throwing an exception on failure is optional. This defaults to the old behaviour but it's now possible to have the function return a string that simply states the address is not available.
  • Removed JetByteTools::Socket::CCompressingDatagramSocketConnectionFilter, JetByteTools::Socket::CDeflatingStreamSocketConnectionFilter and JetByteTools::Socket::CCompressingStreamSocketConnectionFilter and associated code.
  • Added A compile time option to use read sequencing on datagram reads. This is enabled by defining JETBYTE_DATAGRAM_SOCKET_READS_CONTAIN_SEQUENCE_NUMBERS to 1 in Config.h and adds the same sequencing logic that is applied to sequenced stream sockets to datagram sockets. Note that this is only useful if you are implementing a pseudo connection based UDP protocol where the datagrams themselves do not contain a sequence number. It's not guaranteed to ensure sequencing for this scenario but it helps considerably.
  • Bug fix to JetByteTools::Socket::CFilterDataBase::OnWrite() where a buffer chain is passed. We were previously dispatching the buffers separately by iterating the chain and pushing each buffer into the filter. This worked fine until we removed write sequencing in 6.7 as this was only required for Windows XP. The write sequencing was ensuring that our splitting the buffer chain as it entered the filter worked correctly as the filter then resequenced the buffers using the write sequence number. Without a write sequence number it is possible that the buffers would be intermingled with those from another write on another thread. We now handle chains with more than one buffer as an atomic unit and pass the chain itself into the filter and split it inside where we are guaranteed not to be pre-empted by another thread.
  • Changed how we managed shared flow control data in an instance of JetByteTools::Socket::CFlowControlDatagramSocketConnectionFilter and fixed a notification issue with shared flow control data.
  • Removed JetByteTools::Socket::CFullAddress::GetStorage(), JetByteTools::Socket::CFullAddress::GetSize() and JetByteTools::Socket::CFullAddress::GetWritableAddressRef() as it doesn't inherit from JetByteTools::Socket::IWritableAddress. If this breaks any code then I'll put it back and ensure that it also inherits correctly.
  • Removed code from JetByteTools::Socket::CSequencedStreamSocket as there is no longer any difference between it and JetByteTools::Socket::CStreamSocket in how writes are issued. This is code that should have been changed in 6.7 when we removed the Windows XP specific write sequencing code.
  • Bug fix to JetByteTools::Socket::CStreamSocketConnectionManager for writes that involve buffer chains. as with the bug in JetByteTools::Socket::CFilterDataBase::OnWrite(), we were relying on the Windows XP write sequencing code to ensure that multiple buffer writes were written sequentially without any other writes occurring in between the write of each buffer from the chain. Without the write sequence number it was possible that the buffers would be intermingled with those from another write on another thread and this the correctness of the stream would be destroyed. We now handle chains with more than one buffer as an atomic unit and pass the chain itself into the write using an array of WSABUF's and deal with splitting the chain during completion handling. This bug was introduced in 6.7.
  • Bug fix to JetByteTools::Socket::CFilterDataBase where we were being too agressive in recognising the read side of the connection being closed and restricting further application level reads. This resulted in a race condition during receipt of a client close whereby a filter could end up with data available to read inside it but no further application level reads would be processed. This would result in the final data on a cleanly closed connection being appearing to have been lost even though it had arrived successfully.

Version 6.7
  • Removed all of the code that was required to marshall I/O operations to the I/O threads on Windows XP.
  • Removed the concept of write sequencing. There's no need now that the marshalling code has been removed.
  • Removed the concept of "shared lock sockets" and, correspondingly "unique lock sockets". All socket objects now have their own lock.
  • Removed the option of setting a socket's lock's spinCount in the constructor of the socket allocator
  • Replaced some usages of JetByteTools::Win32::CCriticalSection with JetByteTools::Win32::CLockableObject
  • The stacking of connection filters that can generate their own writes has been deprecated.
  • Compressing and deflating socket filters are now deprecated.
  • Breaking change Where possible JetByteTools::IO::CSmartBuffer has replaced raw pointers and references to buffers. This massively reduces the need to reference count buffers during normal I/O operations and increases performance, especially on NUMA architectures.

Version 6.6.5
  • Added an override for JetByteTools::Socket::ISocketCallback::OnError() which takes a DWORD error code so that client code can selectively ignore errors by error code. Previously the only way to ignore errors was by the error message itself which is localised and therefore impossible to match reliably.
  • Rationalised the status changes for JetByteTools::Socket::TStreamSocketServer<> and JetByteTools::Socket::TStreamSocketServerEx<> to remove some strangeness when shutdowns are initiated after the server has already shut down.
  • Added new value to JetByteTools::Socket::ConnectionClosureReason, FatalErrorAbort. This is used if the framework itself needs to abort a connection for any reason.
  • 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.
  • Call the new JetByteTools::IO::IBuffer::OnBufferAddedToPool() and JetByteTools::IO::IBuffer::OnBufferRemovedFromPool() methods on a buffer from the socket's pool functions.
  • Added JetByteTools::Socket::CStreamSocketNamedConnectionCollection::GetConnectionName() which returns the name of a given connection.
  • Added JetByteTools::Socket::CStreamSocketBroadcastableConnectionCollection::BroadcastToAllExcept() which broadcasts a buffer to all connections except the supplied connection.
  • Added JetByteTools::Socket::StreamSocketBroadcastableNamedConnectionCollection.
  • Added JETBYTE_TRACK_ADDRESS_REFERENCES which defaults to 0 and when set enables reference tracking of JetByteTools::Socket::CAddressImpl objects in the same way that tracking can be enabled for sockets and buffers.
  • Added JETBYTE_STREAM_SOCKETS_DISPATCH_OTHER_SOCKETS_DURING_COMPLETION_HANDLING and JETBYTE_DATAGRAM_SOCKETS_DISPATCH_OTHER_SOCKETS_DURING_COMPLETION_HANDLING which both default to 0 and this changes the default behaviour from previous releases. These control how we deal with dispatching operations from other sockets whilst dispatching events from a socket... This only affects designs where one connection can write to another connection. In such a design, in earlier versions, we would allow processing of operations from the 'other' connection whilst we're processing operations from the main connection. For example. If we're in the read completion handler for a connection and we issue a read on another connection and that read completes immediately, inline, then we would begin to handle the completion and end up in the read completion handler for the other socket. This could cause issues with lock inversions if each connection needs to take out locks. The new default is to NOT handle the inline completions for the 'other' socket inline but instead to queue them until after the current socket's operation handler completes. You can revert to the old behaviour by setting these to 1 in your Config.h file.

Version 6.6.4
Version 6.6.3
  • Ran Visual Lint using Gimpel PC Lint on all code and adjusted to remove warnings and fix bugs.
  • Removed all use of exception specifications. We only ever used throw() but that's now gone too.
  • Protected non-virtual destructors on interfaces are now virtual even though they you can't delete the object via the interface.
  • All destructors that could throw exceptions now have optional "log and swallow" exception handlers which are enabled by default. This is better than ignoring the problem and being faced with a call to std::terminate() which can be hard to track down.
  • Bug fix to all WSASend() and WSARecv() calls to prevent multiple threads from calling into the API on the same socket at the same time. See here for more details.
  • Added JetByteTools::Socket::IAddress::IsSameAddress().
  • Bug fix to to JetByteTools::Socket::CFilterDataBase to ensure that each filter knows how many writes it has issued and that they pass completions to the next layer when they should.

Version 6.6.2
Version 6.6.1
Version 6.6
  • Much of the locking in this library has been updated to use the new locks, see Win32Tools for details.
  • Removed the "Debug" and "Release", non unicode, build configurations from the example servers. These build configurations are left over from when we supported operating systems that did not work in unicode mode by default. It's generally more performant to use the unicode builds and the presence of these configurations in the examples tended to encourage new clients to use them for production use.
  • Added JetByteTools::Socket::IFullAddress::IsWildcardAddress()
  • Added the concept of per-socket buffer pools.
  • Added the concept of queueing operations within each socket so that no more than one thread is processing completions at a time. This also removes the possibility of recursion from completions that complete 'in-line' when FILE_SKIP_COMPLETION_PORT_ON_SUCCESS is enabled.
  • All sockets and socket allocators now take two additional constructor arguments to specify the number of buffers that can be pooled in the socket and the number of consecutive operations to process. The number of consecutive operations allows you to tune systems so that sockets under heavy load with FILE_SKIP_COMPLETION_PORT_ON_SUCCESS enabled do not hog an I/O thread for the duration of their connection. After the configurable number of consecutive operations the next operation is posted to the IOCP so that other connections get a chance to process operations.
  • Added overloads of RequestWrite() for all socket types which take an instance of JetByteTools::IO::IIterateableBufferChain.
  • Added an CDatagramSocket::Shutdown() which is an overload that deals with ensuring that pending reads are cancelled when the socket is shutdown as this does not happen automatically and these pending reads could cause the socket to remain open after it has been shutdown in both directions. Note that the way this is done for XP is not ideal as we have to ensure we route a CancelIo() call to each thread in the I/O thread pool as we cannot use CancelIoEx() on this operating system. This routing to all I/O pools can cause the I/O pool processing to stall momentarilly.
  • Shared lock sockets have been deprecated. The resource limitations present on the machines from the NT4 era when this code was concieved are no longer an issue and the presence of the code encourages its use which is no longer recommended. In almost all situations it's far better to allocate a lock per socket rather than share locks. This code is no longer available unless you define JETBYTE_DEPRECATE_SHARED_LOCK_SOCKETS to 0 in Config.h. Note that if this code is enabled then you must also enable the deprecated shared critical section code in the Win32Tools library by defining JETBYTE_DEPRECATE_SHARED_CRITICAL_SECTIONS to 0 in Config.h.
  • Before dispatching an operation, such as a closure notification or a connection reset, to the pool for processing we first check to see if the thread currently holds the socket's lock. If it doesn't then it's safe to dispatch the notification directly rather than via the IOCP.
  • Changed how we deal with skipping marshalling to the I/O pool. We now do it earlier in the call stack rather than waiting until we get all the way down to the dispatch code.
  • Removed the custom buffer pooling in the JetByteTools::Socket::CDeflatingStreamSocketConnectionFilter as it now uses the per-socket buffer pooling which provides the same functionality.
  • Moved where we set write sequence numbers into the JetByteTools::Socket::CSequencedStreamSocket class. This simplifies the filtering and non filtering code paths within the connection mananager.
  • JetByteTools::Socket::CDeflatingStreamSocketConnectionFilter has been defprecated and is no longer available unless you define JETBYTE_DEPRECATE_DEFLATING_STREAM_SOCKET_FILTER to 0 in Config.h. This class is no longer required now that support for the "deflate-stream" Websocket extension is deprecated. If you require "deflate" functionality in a non WebSocket server then use JetByteTools::Socket::CCompressingStreamSocketConnectionFilter instead.
  • Added support for "out of band" or "urgent mode" data in TCP.
  • You can now configure the JetByteTools::Socket::CFlowControlStreamSocketConnectionFilter class with 0 for maxPendingWrites and maxPending buffers and if you do so the filter is NOT added to filter chain. This makes it easier to have the filter as an optional thing which is configured at runtime. Previously this would have caused an exception to be thrown.
  • Major rewrite to JetByteTools::Socket::CFlowControlStreamSocketConnectionFilter to fix problems and improve performance.
  • Breaking Change to JetByteTools::Socket::CFlowControlStreamSocketConnectionFilter::IProcessBufferList::OnListFull() which now takes two instances of JetByteTools::IO::IBufferChain rather than two instances of JetByteTools::Socket::CFlowControlStreamSocketConnectionFilter::BufferList.
  • Added operator==() and operator!=() to JetByteTools::Socket::IAddressType.
  • Removed the optional bool forceDispatchToPool from the JetByteTools::Socket::IAsyncSocket::TryWrite() methods.
  • Added an overload to JetByteTools::Socket::IAsyncSocket::TryWrite() which takes an JetByteTools::IO::IIterateableBufferChain of buffers. This can allow for efficient management of the locks required to build and send a series of buffers in one write.
  • JetByteTools::Socket::CReadSequencingStreamSocketConnectionFilter now uses JetByteTools::IO::CSortedBufferProcessor rather than JetByteTools::IO::CInOrderBufferList.
  • JetByteTools::Socket::CSequencedStreamSocket now never holds a lock over a read or write request. This prevents unpredictable locking semantics in the presence of completions that complete 'in-line' when FILE_SKIP_COMPLETION_PORT_ON_SUCCESS is enabled.
  • JetByteTools::Socket::CSocketReferenceTracker has been tuned a little with regards to custom context depths for some functions and now supports the concept of "instances". See the release notes for the Win32Tools lib, especially JetByteTools::Win32::CReferenceTracker. The number of instances supported can be configured in Config.h by defining JETBYTE_SOCKET_TRACKING_INSTANCES which defaults to 1. Note that tracking multiple instances increases the amount of memory required when tracking references and so multiple instances should only be turned on when required.
  • Changed how we report some connection errors and closures to clean up unexpected behaviour when sockets had already been shutdown.

Version 6.5.9
Version 6.5.8
  • Changes to how JetByteTools::Socket::CStreamSocketServerEx issues AcceptEx() calls to ensure that these calls are always made from an I/O thread. This is to help reduce the likely impact of the bug in Windows 8/Server 2012 with regard to the delay of AcceptEx() completions when the issuing thread is blocked in a synchronous ReadFile().
  • Bug fix to sequence writes. Due to a type size mismatch between JetByteTools::IO::IBuffer::SequenceNumber and the sequence numbers generated by JetByteTools::Socket::CSequencedStreamSocket::SequenceData a write stall could occur when the sequence number that was being generated (a signed long) wrapped as the "next" sequence number in JetByteTools::IO::CInOrderBufferList was a JetByteTools::IO::IBuffer::SequenceNumber which was a size_t which wrapped far later. The buffer list would wait for buffers with sequence numbers which could never be generated.

Version 6.5.7
Version 6.5.6
Version 6.5.5
Version 6.5.4
Version 6.5.3
  • No changes.

Version 6.5.2
  • Adjusted how JETBYTE_DUMP_STREAM_SOCKET_READ_TO_DEBUG_LOG, etc. work, you can now produce less debug data (faster) using JETBYTE_TRACE_STREAM_SOCKET_READ_TO_DEBUG_LOG, etc.

Version 6.5.1
  • Bug fixes to the new "ReadAgain" processing.

Version 6.5
  • Added JetByteTools::Socket::CAddress::Reset() and JetByteTools::Socket::CAddressImpl::WeOwnOnlyReference() to aid in safely reusing address objects that may be being used elsewhere. This helps to fix issues in datagram servers where the client code may wish to hold on to the address that a datagram arrived on but release the socket object relating to that datagram. Without these additions the address that you were holding could change under you when the socket was reused and another datagram arrived.
  • Bug fix. JetByteTools::Socket::CDatagramServerSocket::OnFinalRelease() now calls JetByteTools::Socket::CAddress::Reset() so that any held references to the address that this socket was using are not shared with a reused socket.
  • Added code to JetByteTools::Socket::TConnectionManagerBase<>::~TConnectionManagerBase() to dump all active socket connections when a connection manager is destroyed and socket reference tracking is enabled.
  • Added JetByteTools::Socket::IMaintainStreamSocketConnections::TryCancelConnectionRetries() which allows you to cancel connection retries for addresses which are currently not having connections maintained and simply returns false if the connection is not currently being maintained.
  • Added functionality to JetByteTools::Socket::CConnectionMaintainingStreamSocketConnectionFilter so that connections will be maintained with the send and receive buffer sizes specified for the original connection.
  • Added JETBYTE_DUMP_STREAM_SOCKET_READ_TO_DEBUG_LOG, JETBYTE_DUMP_STREAM_SOCKET_WRITE_TO_DEBUG_LOG, JETBYTE_DUMP_DATAGRAM_SOCKET_READ_TO_DEBUG_LOG and JETBYTE_DUMP_DATAGRAM_SOCKET_WRITE_TO_DEBUG_LOG which all default to the value set for JETBYTE_DUMP_SOCKET_READ_AND_WRITE_DATA_TO_DEBUG_LOG and allow you to tune the data that is dumped by selectively enabling the dumping rather than enabling dumping of all data.
  • Added JetByteTools::Socket::CDeflatingStreamSocketConnectionFilter which is a connection filter which uses deflate to compress the data sent.
  • Added the concept of "ReadAgain" to the connection managers. You can now post a read completion buffer back into the connection manager with a JetByteTools::Socket::TStreamSocketConnectionManager::IO_Read_Completed_Again operation. This pushes the buffer back through the read completion system as if it were a new read completion. This is useful in certain very specific filtering situations where you don't wish to process a buffer on the thread that you're currently running on. You can specify which point in the filter chain the processing starts again, so filters below the filter posting the read again do not need to see the buffer again. Note that this functionality requires a user data slot in every I/O buffer.
  • Changed JetByteTools::Socket::CFlowControlStreamSocketConnectionFilter::IProcessBufferList so that it's easier to manage the flow control. You can now get notifications when the queue is a certain % full and also when it's empty. Also made it easier to have the buffer that causes the queue to be classed as full be added to the queue anyway...
  • Added JetByteTools::Socket::IIPAddress::GetPort() and JetByteTools::Socket::IIPAddress::TryGetPort().
  • Bug fix. In JetByteTools::Socket::CSequencedStreamSocket::RequestWrite() when writing data larger than a buffer. There was the potential for the sequence of buffers written to have other writes intermingled.
  • Removed the debug output from JetByteTools::Socket::CStreamSocketServerExCallback::OnReadCompletionError() - override the function and provide your own debug logging if you need it. The reason for this removal is that there are often cases (during socket closure or server shutdown) when this callback would be called and the debug output is generally spurious in these cases.
  • Changed the order of callbacks from JetByteTools::Socket::TConnectionManagerBase::ReleaseSocket() so that filters are notified before user code. This allows filters to clean up before user code cleans up and this may be important if a filter needs to access user code during its cleanup.
  • Bug Fix. JetByteTools::Socket::CStreamSocket::HandleError() now calls JetByteTools::Socket::CStreamSocket::OnClientClose() if the error is WSAESHUTDOWN and we have not initiated the shutdown. This fixes a rare race condition bug where a client closed notification could be missed.
  • Added JetByteTools::Socket::CanEnableSkipCompletionPortOnSuccess() which is called from JetByteTools::Socket::TDatagramSocketConnectionManager, JetByteTools::Socket::TDatagramSocketServer and JetByteTools::Socket::TStreamSocketConnectionManager and determines if it's safe to enable FILE_SKIP_COMPLETION_PORT_ON_SUCCESS. See here for more details.

Version 6.4
Version 6.3.3
  • No changes.

Version 6.3.2
  • No changes.

Version 6.3.1
  • No changes.

Version 6.3
  • Lots of white space changes which make comparing actual changes with 6.2 quite hard. Sorry.
  • Added new values to the JetByteTools::Socket::ConnectionDirection enumeration. OutboundConnectionBound and OutboundConnectionInProgress these allow us to be a little more precise about when OnBindCompletion() callbacks occur.
  • All connection manager and socket server instances of ReleaseSocket() now takes a bool which indicates if the socket was a 'user socket' or not. To be a 'user socket' the socket must have been passed to a user callback before being released. This means that you now no longer get OnSocketReleased() callbacks for sockets that were pending accept via AcceptEx() or for datagram sockets that were queued to read new inbound datagrams.
  • Added exception handlers for std::exception to all existing exception handlers.
  • Removed JetByteTools::Socket::CDatagramSocket::Connected().
  • Added JetByteTools::Socket::CDatagramSocket::Bound().
  • Performance has been improved in socket code by enabling code that causes the framework to execute I/O operations on the requesting thread rather than marshalling them to an I/O pool thread on Windows Vista or later. You can disable this functionality, and revert to how things were done in 6.2 and before by defining JETBYTE_PERF_STREAM_SOCKETS_SKIP_MARSHAL_TO_IO_POOL to 0 to disable this option for stream sockets and JETBYTE_PERF_DATAGRAM_SOCKETS_SKIP_MARSHAL_TO_IO_POOL to disable this option for datagram sockets.
  • Performance can be improved in certain types of datagram server by enabling the immediate reuse of the socket and/or buffer that was used for a datagram read operation. Note that these structures are only reused if they're just about to be released back to the allocators but by enabling this option you avoid a trip back into the allocator to release the structures only to then have a new read issued which requires allocating new structures. To enable this functionality define JETBYTE_PERF_REUSE_DATAGRAM_SOCKET_AND_BUFFER_FOR_NEXT_READ_IF_POSSIBLE to 1 in your Config.h
  • Fixed a bug in JetByteTools::Socket::StreamSocketServerEx where we were failing to set the listen backlog correctly.
  • Fixed a bug in JetByteTools::Socket::StreamSocketServerEx where we were failing to handle a successful return from AcceptEx() correctly when JETBYTE_PERF_STREAM_SOCKETS_SKIP_COMPLETION_PORT_ON_SUCCESS was enabled.
  • Added JETBYTE_PERF_STREAM_SOCKETS_LIMIT_IO_RECURSION_TO and JETBYTE_PERF_DATAGRAM_SOCKETS_LIMIT_IO_RECURSION_TO which can be used to prevent uncontrolled recursion when JETBYTE_PERF_STREAM_SOCKETS_SKIP_COMPLETION_PORT_ON_SUCCESS and JETBYTE_PERF_DATAGRAM_SOCKETS_SKIP_COMPLETION_PORT_ON_SUCCESS are enabled.
    See here for more details.

Version 6.2
Version 6.1.1
  • Changed how JetByteTools::Socket::CSocketReferenceTracker works. You can now get it to include additional call stack context by defining JETBYTE_ADDITIONAL_SOCKET_TRACKING_CONTEXT (in Config.h) to the number of additional frames of context that you require.

Version 6.1
Version 6.0
  • Changes due to the merging of C++Tools and RegistryTools with Win32Tools.
  • Changes to how we share critical sections amongst sockets to take advantage of the JetByteTools::Win32::ICriticalSectionFactory changes.
    • Moved JetByteTools::Socket::IFilterableStreamSocket::GetLock() to JetByteTools::Socket::IStreamSocket
    • JetByteTools::Socket::CSocketAllocator and JetByteTools::Socket::TSocketAllocator now take a pointer to an optional instance of JetByteTools::Win32::ICriticalSectionFactory. If this instance is non null then the version of JetByteTools::Socket::CSocketAllocator::CreateSocket() that takes an instance of JetByteTools::Win32::ISharedCriticalSection is used for socket creation. If no lock factory is supplied then the version of JetByteTools::Socket::CSocketAllocator::CreateSocket() that only takes the number of user data slots required is used. Derived classes must provide implementations of both versions of CreateSocket() but can fail one or the other if they wish as long as their constructors ensure that either a lock factory is always passed through to the JetByteTools::Socket::CSocketAllocator base class or that one never is. Derived classes can use the new version of the CreateSocket() method to provide sockets that have their own unique lock and which can not ever share locks.
    • JetByteTools::Socket::CStreamSocket and JetByteTools::Socket::TAsyncSocket now take an instance of JetByteTools::Win32::ICriticalSection rather than an instance of JetByteTools::Win32::ICriticalSectionFactory in their constructors.
    • Added two new versions of all socket classes; e.g. JetByteTools::Socket::CUniqueLockStreamSocket and JetByteTools::Socket::CSharedLockStreamSocket. These are now the concrete socket classes which are allocated by the allocators. The unique lock versions have an instance of a JetByteTools::Win32::CCriticalSection inside them, the shared lock versions use a JetByteTools::Win32::CSmartSharedCriticalSection to manage their shared lock. This allows allocators to allocate either using a lock factory or using unique locks. Note that not using JetByteTools::Win32::CUniqueCriticalSectionFactory to provide unique (but conceptually shared) locks gives a space advantage as shared locks are larger than non shared locks. However, JetByteTools::Win32::CUniqueCriticalSectionFactory CAN be used to swap the lock allocation policy at run time rather than compile time...
  • Bug fix in SocketTools\WinsockWrapper.h for compilers earlier than VS2005 compiling with Platform SDK 6.1; we now use JETBYTE_MESSAGE to output the warning message.
  • Bug fix and subsequent changes to various JetByteTools::Socket::CSocket methods so that we report the correct 'last error' when errors occur.
  • Bug fix in JetByteTools::Socket::CAddressIPv6, we were failing to parse IPv6 address strings correctly, we now correctly parse [ffff:ffff:ffff:ffff:ffff]:port style address strings. This will have had a knock on effect with JetByteTools::Socket::CFullAddress also failing to parse these address strings correctly.
  • JetByteTools::Socket::IAsyncSocket::TryRead() is no longer 'nothrow' as it CAN throw an exception if the buffer that it is supplied has no space left in it.
  • Breaking Change Moved JetByteTools::Socket::CSmartBuffer to the IOTools library, the header is now in the IOTools library and the class is now JetByteTools::IO::CSmartBuffer.
  • Breaking Change JetByteTools::Socket::CFlowControlStreamSocketConnectionFilter::IProcessBufferList::OnListFull() now takes a socket reference. This allows you to close the connection if you need to.
  • Added JetByteTools::Socket::CSocket::TryBind() which attempts to bind and returns an error code on failure.
  • All socket allocators that do not require a lock factory now take an optional spinCount which is used to initialise the critical sections used by the sockets that it creates.
  • Changes to how JetByteTools::Socket::CFlowControlStreamSocketConnectionFilter works. All of the policy decisions regarding what to do when the buffer list fills up has now been passed on to an instance of the JetByteTools::Socket::CFlowControlStreamSocketConnectionFilter::IProcessBufferList interface, so you always need to supply one of these now. There's a new class JetByteTools::Socket::CFlowControlListProcessor which provides the old functionality of 'throw away earliest', and 'throw away latest' and also includes the option to abort the connection if too much data is being buffered. JetByteTools::Socket::CFlowControlStreamSocketConnectionFilter also handles write completion errors now, it used to pretend to but didn't. JetByteTools::Socket::IMonitorStreamSocketFlowControl has a new function which is called when a write completion error occurs and you can do something about it, if you can(!) and then return either true or false depending on if you want the failure to cause more data to be sent from the queued data or not.

Version 5.2.5
Version 5.2.4
Version 5.2.3
  • Some whitespace changes to remove incorrect tabs.
  • Removed The ConnectionErrorSource.h header file and the whole concept that the enum represented. This has also led to the removal of the various OnConnectionError() callbacks as these errors are now handled by more appropriate callbacks.
  • Changed how some callbacks are dispatched to user code. See here for more details.
  • Make use of JetByteTools::IO::IBuffer::GetWSABUFCount() so that we can work with buffers that provide multiple WSABUF structures. Note that there aren't actually any buffers in the library that do this yet.
  • Added a new example server and client which demonstrate various methods of terminating a socket connection.
  • JetByteTools::Socket::CReadSequencingStreamSocketConnectionFilter now takes an instance of JetByteTools::Socket::IAllocateSequencedStreamSockets rather than JetByteTools::Socket::IAllocateStreamSockets. It actually only requires the opaque user data part of the interface but this change makes it clearer that the filter only works with sequenced sockets...
  • Some changes to WinsockWrapper.h for when JETBYTE_PLATFORM_SDK_VERSION == 0x0610 and we're building with anything earlier than VS2005 as version 6.1 of the Platform SDK defines a 'clever' template version of _WSPIAPI_COUNTOF from WSPIAPI.H and the earlier compilers can't deal with...
  • Fixed JetByteTools::Socket::CAddressRenderer so that it always passes NI_NUMERICSERV to JetByteTools::Socket::CNameInfo as otherwise you get a WSANO_DATA error on some Windows platforms if the port isn't a "well known" port.

Version 5.2.2
Version 5.2.1
  • VS 2008 support - Adding projects and solutions and excluding warning 4627...
  • This is the first release built using continuous integration, some project file fixes to fix incorrect output directories, etc so that x64 and x86 builds can be done in complete isolation.
  • A hacky fix in IServerControl.h to work around the InitiateShutdown macros that have been moved in a recent version of the Platform SDK. See the comment in the header for details.
  • In NameInfo.cpp, if _WIN32_WINNT < 0x0502 then use getnameinfo() as GetNameInfoW() isn't available on this platform.

Version 5.2
Version 5.1
  • Fixed a bug in JetByteTools::Socket::CReadTimeoutStreamSocketConnectionFilter whereby sockets that hadn't had a connection established on them would throw an exception when released. This mainly manifested itself in the JetByteTools::Socket::CStreamSocketServerEx server which has lots of sockets pending accept.
  • Changes to JetByteTools::IO::Mock::CMockCloseableOutputStream so that it takes an enum rather than a boolean to specify if we dump the data as a string or as a hex dump.
  • Added support for STLPort 5.1.x - the location of a file that we used to use to determine if the Admin.h settings were sane has moved and so there are some changes to Admin.h to reflect this.
  • Updated the docs on JetByteTools::Win32::IQueueTimers::DestroyTimer() so that it mentions that calling it on a handle which is invalid (and is set to JetByteTools::Win32::IQueueTimers::InvalidHandleValue) will cause an exception. We may change this in future so that it's allowed (in the same way that delete 0 is legal...).
  • Added a note to JetByteTools::IO::CAsyncFileWriter to remind me to investigate using InterlockedAdd64...
  • Added some .cvsignore files that seem to end up in the exported version of a release...
  • Adjusted how and when the contents of JB_MSWSock.h is used. This was originally included to make it possible to compile without a copy of the Platform SDK installed and was a copy of the mswsock.h file from the Platform SDK (it was bound to end in tears...). Now it seems that the version of mswsock.h in the latest Platform SDK has changed and so this file causes issues. I haven't tried a build with the latest Platform SDK yet, so this 'fix' may not help, but basically unless you have JETBYTE_NO_PLATFORM_SDK defined as 1 then JB_MSWSock.h simply includes mswsock.h, which is probably how it should always have been...
  • Added these release notes...

Version 5.0
  • Major refactoring - you'll need to port to it, if there's enough demand I'll write a porting guide... No 'derived server' compatible with the free version of the code, but then that's probably been the case for some time.
  • Moved most of the inheritance based class extension to be based on explicit callback interfaces instead. See here.
  • All connection manager and server callbacks now recieve references rather than pointers where appropriate.
  • Name changes for some callbacks; ReadCompleted() is now OnReadCompleted(), etc.
  • Separated the filtering interface so that it's easier and clearer to use. See here.
  • Added doxygen documentation.

There were no release notes prior to version 5.0

Generated on Sun Sep 12 19:06:45 2021 for The Server Framework - v7.4 by doxygen 1.5.3