Latest release of licensed socket server code: 5.2.3

Socket Servers

The latest release of The Server Framework is now available. This release includes the following changes.

The following changes were made to the libraries.

  • Some whitespace changes to remove incorrect tabs.

Admin Library - 5.2.3

  • Added a check for _WIN32_WINNT >= 0x0600 and JETBYTE_PLATFORM_SDK_VERSION < 0x060A as targetting Vista or later means we enable stuff that’s only available in the v6.0a Platform SDK.

  • Added The \ref AdminFAQ “Frequently asked project related questions” page.

  • Having done some more testing, you might need sal.h for VS.Net (2002) and VS 2003. A copy can be found in Admin\VC6Compatibility and you need to copy it to your compiler’s include directory if it complains about it being missing.

  • 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…

  • Adjusted Admin\UsingMFC.h so that it works for dynamic linking with MFC for all compilers rather than just working with VC6.

Win32 Tools Library - 5.2.3

  • Added JetByteTools::Win32::ICollectableThreadPool and JetByteTools::Win32::CThreadPoolCollection which allow you to dispatch items to a named thread pool to facilitate multiple thread pools for different types of work item.

  • JetByteTools::Win32::CThreadPool::WaitForShutdownToComplete() now returns a bool which is true if threads were terminated forcibly rather than being allowed to shutdown cleanly.

  • Added JetByteTools::Win32::CThreadPool::DisposeOfQueuedItems and JetByteTools::Win32::IThreadPoolWorkerThreadFactory::DisposeOfQueuedItemsAfterShutdown() which work together to allow you to process all work items that were held in a thread pool’s queue after the pool has been shutdown. This should be used to release resources used by items that were placed into the queue but that will now never be processed.

  • Corrected the data type used for JetByteTools::Win32::CIOCompletionPort timeouts.

  • Added JetByteTools::Win32::CThread::StartWithPriority(), JetByteTools::Win32::CThread::EnableThreadPriorityBoost(), JetByteTools::Win32::CThread::DisableThreadPriorityBoost(), JetByteTools::Win32::CThread::ThreadPriorityBoostEnabled(), JetByteTools::Win32::CThread::SetThreadPriority() and JetByteTools::Win32::CThread::GetThreadPriority().

  • Added JetByteTools::Win32::CSmartStatupInfo which takes ownership of any input or output handles supplied to it or creates the files and takes ownership of the handles if given file names.

  • Added JetByteTools::Win32::CMultipleFileDeleter which is a bit like JetByteTools::Win32::CFileDeleter but for multiple files…

  • Added JetByteTools::Win32::CJob, JetByteTools::Win32::CJobEventManager, JetByteTools::Win32::IMonitorJobs, JetByteTools::Win32::IManageJobEvents, JetByteTools::Win32::IHandleJobEvents, JetByteTools::Win32::IAssignProcessesToJobs and JetByteTools::Win32::CNullJobMonitor which, together, allow you to manipulate Windows Job Objects.

  • Added JetByteTools::Win32::CCallbackTimerQueueEx which uses JetByteTools::Win32::IProvideTickCount64 as its time source. See here: http://www.lenholgate.com/archives/000773.html for more details.

  • Changed the implementation of JetByteTools::Win32::CCallbackTimerQueue to the one that is detailed here: http://www.lenholgate.com/archives/000773.html.

  • Changed JetByteTools::Win32::CThreadedCallbackTimerQueue so that you can select which underlying timer queue implementation it uses, or provide a custom one of your own, and so that you can request that it dispatches timers without holding any internal locks. Note that the default behaviour is to hold the internal lock and this behaviour is backwards compatible with the previous releases. However, in certain designs, this makes it easy for you to deadlock. If you have a lock and you hold it whilst calling into any of the timer queue functions, and you try to acquire your lock when the timer queue calls into you then you will deadlock. Not holding the internal lock during timer dispatch means that you can’t deadlock when using the timer queue but the dispatch code is possibly slightly slower. This may be important to you in certain situations so we currently provide the choice. The changes are detailed here: http://www.lenholgate.com/archives/000795.html

  • Added JetByteTools::Win32::CThreadedCallbackTimerQueue::SetThreadName() which allows you to change the name of the timer queue thread. This name is displayed in the Visual Studio Debugger’s thread window. The constructor now sets the name of this thread to "TimerQueue" by default.

  • Added JetByteTools::Win32::CThreadPool::SetThreadName() which allows you to change the name of the worker threads that are managed by the pool. The constructor now sets the name of these threads to "ThreadPool" by default.

  • Added JetByteTools::Win32::CThreadPool::SetDispatchThreadName() which allows you to change the name of the dispatch thread that is used by the pool. The constructor now sets the name of this thread to "ThreadPoolDispatch" by default. Note that this must be called before calling JetByteTools::Win32::CThreadPool::Start() for it to have an effect.

  • Added JetByteTools::Win32::CThreadPool::SetThreadName() which allows you to change the name of the worker threads that are managed by the pool. The constructor now sets the name of these threads to "ThreadPool" by default. Note that this must be called before calling JetByteTools::Win32::CThreadPool::Start() for it to have an effect.

  • JetByteTools::Win32::CThreadPool::WorkerThread::Run() now catches exceptions of type JetByteTools::Win32::CSEHException that leak from JetByteTools::Win32::IIOCPWorkerThreadCallback::Process() and tries to shut the worker thread down cleanly; it might work in some cases.

I/O Tools Library - 5.2.3

  • Added JetByteTools::IO::CBufferHandleAllocator. This provides a pooling allocator for JetByteTools::IO::CBufferHandle objects. Buffer handles are used to broadcast data to multiple clients without needing to copy the data into separate buffers.

  • Added JetByteTools::IO::CJobEventManager. This works with the job object support in the Win32 Tools Library to provide an event manager which can work with a JetByteTools::IO::IIOPool.

  • Fixed a memory leak in JetByteTools::IO::CMemoryInputOutputStream where we were using delete rather than delete [].

  • Added JetByteTools::IO::CInOrderBufferList::Size() which returns the number of buffers in the list.

  • Added JetByteTools::IO::IBuffer::GetWSABUFCount(). This returns the number of WSABUFs in the array returned by JetByteTools::IO::IBuffer::GetWSABUF(). At present all buffer implementations return 1 for this, but this will allow for buffers which support ‘scatter/gather’ style multiple buffer writes.

  • Added JetByteTools::IO::IAllocatableBuffer which goes some way to being able to share the pooling aspects of the various buffer allocators.

  • Added JetByteTools::IO::CIOPool::SetThreadName() which allows you to change the name of the worker threads that are managed by the pool. The constructor now sets the name of these threads to "IOPool" by default. Note that this must be called before calling JetByteTools::Win32::CIOPool::Start() for it to have an effect.

Socket Tools Library - 5.2.3

  • 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.

Full details of the licensed version of the code are available here.

Full details of the free version of the code are available here.

No new documentation for this release.

Doxygen documentation for the latest release is available here.

If you’re an existing client and you’d like these changes let me know.