February 2012 Archives

Latest release of The Server Framework: 6.5.4

Version 6.5.4 of The Server Framework was released today.

This release contains two important bug fixes and a selection of minor improvements. If you run your code on Vista/Windows Server 2003 or later and you don't explicitly disable FILE_SKIP_COMPLETION_PORT_ON_SUCCESS in your Config.h then you should install this update.

This release includes the following, see the release notes, here, for full details of all changes.

  • Bug fix. If FILE_SKIP_COMPLETION_PORT_ON_SUCCESS was enabled but JetByteTools::Socket::CanEnableSkipCompletionPortOnSuccess() returned false then the the code that handled issuing read and write calls would fail if ERROR_SUCCESS was returned because it would assume that FILE_SKIP_COMPLETION_PORT_ON_SUCCESS was enabled and that it should handle the completion directly but a completion would have been posted to the IOCP and so the completion would get handled twice. We now correctly whether we have actually enabled FILE_SKIP_COMPLETION_PORT_ON_SUCCESS rather than just whether we want to enable it.
  • Change to JetByteTools::Socket::CConnectionMaintainingStreamSocketConnectionFilter so that we do not attempt to maintain a connection if the reconnect delay is 0.
  • Added the concept of being able to force a write request to go via the I/O pool even if marshalling is currently turned off.
  • Added JetByteTools::Socket::IManageStreamSocketConnectionFilters::TryRequestWrite()
  • Changed how JetByteTools::Socket::CFlowControlStreamSocketConnectionFilter issues write requests and how it deals with write failure due to socket closure. We now purge any queued data when we detect the socket has been closed, rather than continuing to try and send more.
  • Added JetByteTools::Socket::IDatagramSendSocket which is a common base class for JetByteTools::Socket::IDatagramSocket and JetByteTools::Socket::IDatagramServerSocket.
  • Added JetByteTools::Socket::IFilterableStreamSocket::CanIssueFilteredWrite() which is now called instead of JetByteTools::Socket::IStreamSocketEx::CanWrite() by JetByteTools::Socket::CFilteringStreamSocketConnectionManagerBase::TryRequestWrite(). This removes a race condition during the shutdown of the write side of a socket in situations where filtering is being used and the filter wishes to write to the socket after the application level code has requested that the write side of the socket be shut down. We always tracked the outstanding write count before actually issuing the shutdown and the filter could manage this to allow it to be able to send after a shutdown had been requested BUT the filtered send could still fail as the socket's write shutdown flag would be set. This new function does not check the write shutdown flag and so allows the filter to write successfully.
  • Changed JetByteTools::IO::IAllocateBufferHandles::Flush() so that it returns a bool indicating if buffers were active when the flush was done. This brings it in line with JetByteTools::IO::IAllocateBuffers.
  • Changed the JetByteTools::IO::IAsyncIOStream::Write() methods so that they take an optional bool that enables you to force the write to go via the I/O pool even if I/O marshalling is turned off.
  • Changed JetByteTools::IO::CAsyncFileLog to monitor its own write thread to remove the chance that it might hang during destruction if the thread has terminated due to an exception.
Our Secretive Online Game Company client uses The Server Framework for their custom application server for the games industry. They have thousands of users who run their server on a very diverse set of hardware. This is great for us as it really helps to shake down The Server Framework. There's nothing like running your multi-threaded code on lots of different hardware to help find all of the hidden race conditions and whatever. I'm pleased that we have so few bug reports coming in from our clients. Especially knowing that our Online Game Company client has the latest code out in the field or at least in use internally on their cloud system. Unfortunately one of their clients has recently exposed a latent bug in a rarely used corner of The Server Framework.

One of the features of The Server Framework is that we track new features in various Windows operating systems so that you can take advantage of them simply by upgrading. Often you only need to adjust your Config.h file to enable powerful new features. One of these features is FILE_SKIP_COMPLETION_PORT_ON_SUCCESS, you can read more about it over on Len's blog. This allows some optimisation in thread scheduling and context switching and generally improves performance on busy servers.

Back in April 2011 we updated our FILE_SKIP_COMPLETION_PORT_ON_SUCCESS support to include protection from incompatible networking providers, see this Microsoft Knowledge Base article for details of the potential problem. In addition to the compile time support for FILE_SKIP_COMPLETION_PORT_ON_SUCCESS which can be used to turn the feature on and off in The Server Framework, we added a run time check to ensure that the machine on which the code was running did not have any incompatible networking providers installed.

Unfortunately this code wasn't tested as well as it could be and there was a bug in it which leads to problems on systems that have an incompatible networking provider installed and FILE_SKIP_COMPLETION_PORT_ON_SUCCESS support turned on. This leads to the completions for some operations being processed twice and subsequent reference counting (over-release) problems with the corresponding socket and buffer structures.

We've fixed this issue and it will be included in a 6.5.4 release which is currently in test. If you think you're suffering from the problems caused by this and need the fix immediately then please get in touch.

The offending networking provider in this case was the "AVSDA" provider which, a quick web search suggests, is part of Avira Anti virus.

WASP download of XP versions now fixed

I've just noticed a problem with downloading the XP versions of WASP.

This is now fixed. The XP versions can now be downloaded correctly again from here. Sorry for any inconvenience caused.

Follow us on Twitter: @ServerFramework

About this Archive

This page is an archive of entries from February 2012 listed from newest to oldest.

December 2011 is the previous archive.

March 2012 is the next archive.

I usually write about the development of The Server Framework, a super scalable, high performance, C++, I/O Completion Port based framework for writing servers and clients on Windows platforms.

Find recent content on the main index or look in the archives to find all content.