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.
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.
In my last blog post I introduced the Windows 8 Registered I/O Networking Extensions, RIO. As I explained there are three ways to retrieve completions from RIO, polled, event driven and via an I/O Completion Port (IOCP). This makes RIO pretty flexible and allows it to be used in many different designs of servers. The polled scenario is likely aimed at very high performance UDP or High Frequency Trading style situations where you may be happy to burn CPU so as to process inbound datagrams as fast as possible.
Most of the buzz being generated around the Windows 8 Developer Previews at the moment seems to be centred on the new Metro user interface and the Windows Runtime. Whilst both Metro and WinRT are key components of the next Windows release I find the Registered I/O Networking Extensions to be far more interesting, but then I guess I would…
What are the Registered I/O Networking Extensions? The Registered I/O Networking Extensions, RIO, is a new API that has been added to Winsock to support high-speed networking for increased networking performance with lower latency and jitter.
Due to client demand we’re working on the WebSocket protocol again. Things have moved on since the work we did in December and this time the resulting option pack really will make it into the next release rather than simply being something that we tweak for each client that asks for it.
Back in December one of our gaming clients wanted WebSocket functionality in their game server so we did some work on the two versions of the spec that they wanted, the Hixie 76 draft and the HyBi 03 draft.
I’m in the process of completing a custom server development project for a client. The server deals with connections from thousands of embedded devices and allows them to download new firmware or configuration data and upload data that they’ve accumulated in their local memory. To enable maximum scalability the server use asynchronous reads and writes to the file system as well as the network.
One feature of the server is the ability to configure it to create per session log files.
The next release of The Server Framework, 6.4, includes code which allows a server to create a crash dump whilst it is running. Typically you might want to do this if some strange and possibly fatal exception gets thrown. Crash dumps are a great way to debug a server that is failing in production, the server generates the dump when something goes wrong and you can then load up the dump on your development machine and your debugger will be sitting on the line that caused the problem.
The CIOPool class’s constructor takes a ThreadIdentifier value which is used to allow the threads in the pool to know that they’re in the pool. The value is stored in thread local storage for each thread in the pool and can then be examined to determine if a thread belongs to the I/O pool. The value can also be queried and other threads can ‘be treated as I/O pool threads’ by setting the appropriate TLS slot to this value.
I’ve been doing a lot of performance related work over the past few months. Much of it has originally stemmed from work that I have been doing for our Online Game Company client. They want the asynchronous ENet-based server that we’ve built for them to be the fastest it can be and so I’ve been looking at all aspects of performance within the framework. The testing hasn’t brought anything too embarrassing to light; the I/O recursion limiter that was introduced in 6.
