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.
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’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.
Version 6.5.3 of The Server Framework was released today.
This release updates the WebSockets Option pack to the final version of the protocol as detailed in RFC 6455 which was released yesterday. There is also a bug fix to WebSocket status reason processing. If you have 6.5 or 6.5.1 or 6.5.2 and you are NOT using WebSockets then you probably don’t need this release.
This release includes the following, see the release notes, here, for full details of all changes.
We have a new client profile available here for a new client who selected The Server Framework to help it expand its online gaming platform to incorporate a WebSockets interface.
We’ve just released a new version of WASP, our pluggable application server platform. This release is built with release 6.5.2 of The Server Framework and includes support for secure TCP connections using SSL/TLS via our SChannel Option pack.
Setting up a secure TCP endpoint with WASP is easy, simply add the Secure configuration option to the <EndPoint> node like this:
<?xml version="1.0" encoding="Windows-1252"?> <Configuration> <WASP> <TCP> <Endpoints> <EndPoint Name="Echo Server" Port="5050" HandlerDLL="[CONFIG]\EchoServer.
Version 6.5.2 of The Server Framework was released today.
This release adds some new functionality to the WebSockets Option pack and fixes some bugs in code that is only currently used by the WebSockets Option pack. If you have 6.5 or 6.5.1 and you are not using WebSockets then you probably don’t need this release.
This release includes the following, see the release notes, here, for full details of all changes.
We are dropping support for Visual Studio .Net 2002 from release 6.6 of The Server Framework which is due early next year. We don’t expect that this will cause anyone any problems as this compiler became unsupported by Microsoft in 2009, and most native C++ people seemed to skip this release entirely.
We are also considering dropping support for Visual Studio .Net 2003. This compiler is still supported by Microsoft until 2013 but we expect that most people interested in native C++ will have switched to Visual Studio 2005 or 2008 at the earliest opportunity.
We have a new client profile available here for a client that we’ve had since 2006 and who use The Server Framework in their equity trading systems.
One of the things that allows the Windows 8 Registered I/O Networking Extensions, RIO, to perform better than normal Winsock calls is the fact that the memory used for I/O operations is pre-registered with the API. This allows RIO to do all the necessary checks that the buffer memory is valid, etc. once, and then lock the buffer in memory until you de-register it. Compare this to normal Winsock networking where the memory needs to be checked and locked on each operation and already we have a whole load of work that simply isn’t required for each I/O operation.
