This article presents the second in my series of example servers using the Windows 8 Registered I/O Networking extensions, RIO. This example server uses the event driven notification method to handle RIO completions. I’ve been looking at the Windows 8 Registered I/O Networking Extensions since October when they first made an appearance as part of the Windows 8 Developer Preview. Whilst exploring and understanding the new API I spent some time putting together some simple UDP servers using the various notification styles that RIO provides.

The best thing about Visual Studio 11 is that it doesn’t matter if you like the new style IDE or not. The project files are, at last, backwards compatible, so you can load them in Visual Studio 2010 and build with the new tool chain even though you ignore the new IDE - if that’s what you want to do. I don’t like the new icons, but I find I can work fine in the IDE as long as I don’t think about it too much… Probably pretty much like how I felt about all previous versions when they were at the beta stage…

I’ve been looking at the Windows 8 Registered I/O Networking Extensions since October when they first made an appearance as part of the Windows 8 Developer Preview. Whilst exploring and understanding the new API I spent some time putting together some simple UDP servers using the various notification styles that RIO provides. I then put together some equally simple UDP servers using the “traditional” APIs so that I could compare performance.

I’ve been looking at the Windows 8 Registered I/O Networking Extensions since October when they first made an appearance as part of the Windows 8 Developer Preview. Whilst exploring and understanding the new API I spent some time putting together some simple UDP servers using the various notification styles that RIO provides. I then put together some equally simple UDP servers using the “traditional” APIs so that I could compare performance.

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.

The year has kicked off to a very busy start for us with lots of work from our secretive Online Gaming Company. They’re doing a lot of work to enhance the product that we’ve helped them build so that it can run well in cloud environments for their clients and also form the core of their cloud-based service. Much of our current work for them is to do with server to server communications so that they can build a scalable system that can use resources in the cloud to grow on demand.

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.

I know I’ve said this before, but now it’s really done… The WebSocket protocol is now an official RFC. There are a small number of changes between RFC 6455 and the draft WebSocket protocol version 17; the only important ones being he addition of two new close status codes. The rest is just a case of tidying up the draft. There will be a 6.5.3 release of The Server Framework to include these changes.