Happy New Year

By Len on January 13, 2012 3:42 PM
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. We've been working with them on aspects of this for some time now and it's all starting to come together nicely. Additionally we've recently added WebSockets support to their server so that they can easily support a new breed of browser based clients.

We're also excited about working more closely with our Industrial Control Client who are sponsoring us for SC level security clearance so that we can get more involved with their systems; if we told you any more we'd have to kill you...

We've had more fixed price work for our Custom Electronics Manufacturer, adding SChannel based SSL support to their server. This server allows thousands of embedded devices to connect to their central servers to upload logs and download firmware.

We've still been too busy to do much work on the LockExplorer website but there's an update to the tools scheduled for the end of the month to include all of the recent changes and fixes that have been applied whilst we've been 'dog fooding' them with our clients and on The Server Framework's build machines.

Finally, we already have several releases planned for The Server Framework this year; watch this space!

Latest release of The Server Framework: 6.5.3

By Len on December 14, 2011 8:47 AM | 0 Comments | 0 TrackBacks
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.

  • Updated to support RFC 6455 - added close status codes 1011 and 1015.
  • Fixed a bug in the handling of long status result messages, we now truncate them correctly.

RFC 6455: The WebSocket protocol

By Len on December 14, 2011 8:46 AM | 0 Comments | 0 TrackBacks
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.

New client profile: Smart Moves Software Systems - Online gaming

By Len on November 23, 2011 8:38 AM | 0 Comments | 0 TrackBacks
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.

A new release of WASP, now with SSL/TLS support

By Len on November 22, 2011 10:10 AM | 0 Comments | 0 TrackBacks
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.dll"
          Secure="true">
        </EndPoint>
      </Endpoints>
    </TCP>
  </WASP>
</Configuration>
This tells WASP to secure the endpoint using a default certificate called "Wasp" that is located in the "MY" certificate store. You can add a self signed test certificate using the standard Microsoft "make cert" utility, makecert.exe and a simple script which creates and installs the correct type of certificate can be downloaded from here.

if you do not want to use a certificate called "Wasp" in the "MY" certificate store then you can configure the certificate used by adding the StoreName, CertificateName and UseMachineStore config values. 
<?xml version="1.0" encoding="Windows-1252"?>
<Configuration>
  <WASP>
    <TCP>
      <Endpoints>
        <EndPoint
          Name="Echo Server"
          Port="5050"
          HandlerDLL="[CONFIG]\EchoServer.dll"
          Secure="true"
          StoreName="OurSpecialStore"
          CertificateName="OurCertificate"
          UseMachineStore="true">
        </EndPoint>
      </Endpoints>
    </TCP>
  </WASP>
</Configuration>
Testing your new secure endpoint can be done using either our OpenSSL server test or our SChannel server test. These are example clients that ship with The Server Framework and that allow you to create thousands of concurrent connections and control how they send data to a server. This is an easy way to build a test system for your server as all of the complexity of managing and controlling the connections is done for you and you simply have to adjust the messages that are generated and how the response validation is done. The default message that is built is an network byte order integer length prefixed message and so this program can be used to stress test WASP with either of the first two example plugins that were discussed in the tutorial.

You can download the SChannelEchoServerTest program from here. See our for details of how to run this tool.

Latest release of The Server Framework: 6.5.2

By Len on November 21, 2011 8:25 AM | 0 Comments | 0 TrackBacks
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.

Dropping support for Visual Studio .Net 2002 and 2003

By Len on November 9, 2011 11:25 AM | 0 Comments | 0 TrackBacks
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.

Feedback is essential here. If you DO still need Visual Studio .Net 2003 support then we need to know, otherwise we may bring forward its retirement date...

New client profile: Takion Technologies - Equity trading platform

By Len on November 4, 2011 9:11 AM | 0 Comments | 0 TrackBacks
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.

Windows 8 Registered I/O Buffer Strategies

By Len on October 31, 2011 7:30 AM | 0 Comments | 0 TrackBacks
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. As always, take a look at this video from Microsoft's BUILD conference for more in-depth details.

RIO buffers need to be registered before use

The recommended way to use RIORegisterBuffer() is to register large buffers and then use smaller slices from these buffers in your I/O calls, rather than registering each individual I/O buffer separately. This reduces the book-keeping costs as each registered buffer requires some memory to track its registration. It's also sensible to use page aligned memory for buffers that you register with RIORegisterBuffer() as the locking granularity of the operating system is page level so if you use a buffer that is not aligned on a page boundary you will lock the entire page that it occupies. This is especially important given that there's a limit to the number of I/O pages that can be locked at one time and I would imagine that buffers registered with RIORegisterBuffer() count against this limit.
Continue reading Windows 8 Registered I/O Buffer Strategies.

Windows 8 Registered I/O and I/O Completion Ports

By Len on October 25, 2011 6:56 PM | 0 Comments | 0 TrackBacks
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. The event driven style may also help here, allowing you to wait efficiently rather than spin, but it's the IOCP style that currently interests me most at present as this promises to provide increased performance to more general purpose networking code.

Please bear in mind the caveats from my last blog post, this stuff is new, I'm still finding my way, the docs aren't in sync with the headers in the SDK and much of this is based on assumption and intuition.

How do RIO and IOCP work together?

RIO's completions arrive via a completion queue, which is fixed sized data structure that is shared between user space and kernel space (via locked memory?) and which does not require a kernel mode transition to dequeue from (see this BUILD video for more details on RIO's internals). As I showed last time, you specify how you want to retrieve completions when you create the queue, either providing an event to be signalled, an IOCP to be posted to or nothing if you will simply poll the queue. When using an IOCP you get a notification sent to you when the completion queue is no longer empty after you have indicated that you want to receive completions by calling RIONotify().
Continue reading Windows 8 Registered I/O and I/O Completion Ports.

Follow me on Twitter: @LenHolgate

About this Blog

I usually write about C++ development on Windows platforms, but I often ramble on about other less technical stuff...

This page contains recent content. Look in the archives to find all content.

Recent Entries

Recent Comments

I have other blogs...

Subscribe to feed The Server Framework - high performance server development
Subscribe to feed Lock Explorer - deadlock detection and multi-threaded performance tools
Subscribe to feed l'Hexapod - embedded electronics and robotics
Subscribe to feed MegèveSki - skiing

I also write about...