Latest release of The Server Framework: 6.9.1

Version 6.9.1 of The Server Framework was released today.

This release includes changes to support Visual Studio 2017 15.5 and some bug fixes. It's required if you're using Visual Studio 2017.

C++ Tools - Deleaker


I've just purchased a license for Deleaker by Softanics. I found out about the tool from Bartek's coding blog where he writes about the tool here.

I downloaded the trial edition and it found quite a few subtle issues in some of my unit test code. Nothing too serious, but stuff that other tools have missed. The run-time overhead doesn't appear to be that great, my server tests still run at a reasonable speed and nothing fails because of the instrumentation. My virus checker (Bitdefender) hates the tool, probably due to the code injection and whatever that's required. The developer is easy to talk to and interesting in dealing with any issues that you have.

The price is a little steep, but I got a decent discount for being a reader of Bartlomiej's blog and that helped. I'm not sure I would have purchased otherwise. At the discounted price it's a useful addition to my toolbox.

C++ Tools - CppDepend - 2017 update...


I've been trying various static analysis tools on the C++ code of The Server Framework. I've now been using Resharper C++ quite regularly for over a year and I still use the Gimpel PC-Lint Plus Beta on a regular basis. I haven't used CppDepend as much, mainly because once I'd fixed the issues that it raised, and that I decided I needed to fix, I pretty much left it alone. This is possibly because I run it as an external tool and I run both Resharper and PC-Lint as fully integrated Visual Studio extensions.

Full disclosure. I have been given another CppDepend license.

As I've said before, whilst CppDepend is easy to get hold of, easy to install and "just works" I don't find it that useful. I tried installing the Visual Studio add-in this time around and found that I then had problems removing the add-in. I've no idea why and it was probably just me, but I decided to stick with the stand-alone tool.

As I said last time, I can certainly remember large enterprise clients where this kind of tool would be invaluable for management level analysis of large codebases but for a small development team of competent people it's less immediately useful. It still fills some gaps so it's still useful to me; perhaps I need to try harder with the Visual Studio add-in.

There are some nice new features to this latest edition: Smart Technical Debt estimation looks like a good way of preventing a codebase degrading over time and helping you to focus on issues that can be fixed quickly, or issues that are really complex and will take ages to fix.... Being able to navigate to types with the most technical debt is useful. I also like the idea of the Quality Gates concept. The html reporting stuff also looks useful, though I'd have to get CppDepend running on my build servers as part of the build and release process to get the best benefit from it.

All in all I like the new features but I'm still not sure that I would purchase a license for this tool but I know clients that could benefit from using it.

Latest release of The Server Framework: 6.9

Version 6.9 of The Server Framework was released today.

This release includes lots of code change due to: the removal of support for Visual Studio 2012 and the results of lots of static analysis.

VMWare bridged networking intermittently failing

This is one of those 'note to self' postings...

I have a VMWare box that uses bridged networking and has a static DHCP address that I use for a specific client's testing as a db server. Every so often the virtual machine fails to connect to the network properly and ends up with a bogus ip address. I then spend ages trying to work out what's going wrong...

This link, may help. It explains about using vmnetcfg.exe to adjust the bridged networking settings on the host machine.

The reason that the automatic bridging fails sometimes on my development box is that I have several NICs on the box. One pair are teamed and provide my internet access. Another is the 10Gb test network that I have wired back-to-back with my test server. When the test server is on and the 10Gb NIC is active the automatic bridging gets confused and the virtual machine's network connection fails.

The solution, for me, is to use vmnetcfg.exe to adjust the bridge networking settings and unselect the 10Gb NIC.

WebRTC, TLS hardening and Scalable game servers

This year is proving to be yet another busy one for us. We've continued to work with Eonic Gaming on their servers for the Turf Battles Triumphus 3D MMORPG and we have done quite a bit of work with various clients regarding hardening their TLS servers. The main focus though has been digging into WebRTC data channels.

The WebRTC work is nice, though fairly complex. It's based on lots of RFCs and the initial learning curve was pretty steep. WebRTC data channels, in themselves, are pretty simple, but they're built on a huge stack of other technologies: SCTP, DTLS, ICE, STUN, etc. Getting all of that working to the point where we get a simple "hello world" message from browser into the server and back has taken some time. There's lots of open source stuff out there but much of it needs a lot of work to understand fully as documentation, comments and naming often leaves a lot to be desired.

We're looking at producing a highly scalable implementation of WebRTC data channels from the ground up for a client who wants to add this kind of connectivity to their application servers; WebRTC is often used for peer to peer connections where both peers are browsers, our system has the server as one of the peers. Right now we're doing a custom implementation specifically for this client but eventually we expect to produce an Option Pack with a slightly more general purpose WebRTC implementation.

As always we've also been working on several new releases of The Server Framework, a 6.8.1 maintenance release and continuing work on what could become massively modernised 7.0 release.

How to determine if a non-IFS LSP is installed


Enabling FILE_SKIP_COMPLETION_PORT_ON_SUCCESS on a handle associated with an I/O completion port can improve performance and reduce context switching by allowing the thread that calls the API that can complete asynchronously to handle the completion "inline" if the call can complete synchronously. This is especially useful for TCP reads when there's already data in the network stack's buffers, or writes when there is space in the buffers. Whilst there are design issues that must be taken into consideration before simply enabling this flag (beware recursion!) there's a little known issue where code outside of your control can prevent the IOCP from operating correctly when this flag is enabled.

If non-IFS Winsock Base Service Providers (BSPs) or Layered Service Providers (LSPs) are installed then you may not receive completions at all for handles with the flag set.

This Microsoft Knowledge Base article has been around for quite a few years and it's important and possibly becoming more so as more and more poorly written LSPs get installed by adware and other rubbish.

It's all very well knowing that you can't use FILE_SKIP_COMPLETION_PORT_ON_SUCCESS when you have a non-IFS LSP installed but how can you tell at runtime that this is the case?

We've had this code in The Server Framework since 2011 or so: it iterates the Winsock catalog and lets you know if any non-IFS LSPs are installed. You can then use the results of this to determine if it's safe to enable FILE_SKIP_COMPLETION_PORT_ON_SUCCESS or not.

static const int s_protocols[] = { IPPROTO_TCP, IPPROTO_UDP, 0 };

bool CanEnableSkipCompletionPortOnSuccess()
   // At some point we MAY want to check for UDP and TCP transports separately,
   // if we do that then we need to change this.

   TExpandableBuffer<BYTE> buffer;

   LPWSAPROTOCOL_INFOW pProtocolInfo = nullptr;

   DWORD bufferLength = 0;

   int error = 0;

   int numEntries = ::WSCEnumProtocols(
      const_cast<int *>(&s_protocols[0]),

   if (SOCKET_ERROR != numEntries)
      throw CException(
         _T("Expected first call to fail and return buffer size!"));

   int attempts = 0;

   bool done = false;

   while (!done)
      if (error != WSAENOBUFS)
         throw CWin32Exception(

      if (attempts++ > 3)
         // so the amount of memory required is always changing??

         throw CException(
            _T("Cannot allocate appropriate buffer: ") +


      pProtocolInfo = reinterpret_cast<LPWSAPROTOCOL_INFOW>(buffer.GetBuffer());

      numEntries = ::WSCEnumProtocols(
         const_cast<int *>(&s_protocols[0]),

      done = (SOCKET_ERROR != numEntries);

   bool ok = true;

   for (int i = 0; ok && i < numEntries; ++i)
      ok = ((pProtocolInfo[i].dwServiceFlags1 & XP1_IFS_HANDLES) == XP1_IFS_HANDLES);

   return ok;

Latest release of The Server Framework: 6.8

Version 6.8 of The Server Framework was released today.

This release includes important bug fixes, see here. It also includes lots of code change due to: the removal of support for Visual Studio 2010, adding support for Visual Studio 2017 and the results of lots of static analysis.

This release is essential for users of Release 6.7.

Bug in multi-buffer writes in 6.7


A bug has been discovered in Release 6.7 in the code that deals with TCP socket writes that involve more than a single buffer. These 'multi-buffer writes' are writes that involves either a buffer chain or a block of data passed as a pointer and a length where the length exceeds the size of the buffer allocator that the connection is using.

The bug prevents the 'multi-buffer write' from being executed as a single atomic write at the network layer and so can cause corruption of a TCP data stream if multiple sockets are writing to the same connection concurrently.

The bug is due to the removal in 6.7 of the code required to support Windows XP. In Windows XP we needed to include sequence numbers in write operations to allow for the way we always marshalled all I/O operations from the calling thread to an I/O thread to prevent I/O cancellation due to thread termination. This write sequencing code had the side effect of also protecting 'multi-buffer writes' from being interrupted by other writes.

The fix does not require the reintroduction of write sequencing but, instead, issues a single scatter/gather style write for the entire buffer chain. This is both efficient and correct.

A related bug also affects atomicity of 'multi-buffer writes' into filter layers, such as the SSL code. Similar fixes have been applied here.

The bug is fixed in Release 6.8 which will be released later today.

C++ Tools - JetBrains ReSharper C++ - purchased...


I've been looking at Resharper C++ by JetBrains for a while now and the trial period has finally run out. I immediately bought a license which shows how my feelings have changed about the product during the trial.

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.

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