Geek Speak

More \Device\Afd goodness

For a while now I’ve been playing around with the low-level access to the Windows networking stack that is provided by \Device\Afd. Recently I had a comment from a reader, Matt James, who pointed me in the direction of his work over at which does a lot more with the \Device\Afd interface than I have. It’s well worth checking out. This code includes, as reference, a set of NT Native API headers from the Process Hacker project, which in itself is interesting stuff, but Matt’s code goes far beyond my megre investigations and provides enough information to produce a full featured network API that appears to be able to everything you might need through the \Device\Afd interface.

Adventures with \Device\Afd - a simple server

The only difference between a client and a server is the way in which the connection is established. For a client, you create a socket and call “connect” on it. For a server, we have a socket that is “listening” for connections “accepts” new incoming connections and returns a socket that is then indistinguishable from a client connection. In the past, I’ve created bad abstractions at this point. A socket connection and a listening socket are both represented by the operating system API as the same type, and the only differences are the calls that you make on the type.

Adventures with \Device\Afd - a simple client

Now that I have a reasonably easy to use event-driven socket class I can start to use it. The first thing to build is a simple client. This will connect to a server and expect that server to echo anything that is sent to it. The client will send data and read it back and compare it with what it sent. A simple, single-threaded, client Last time, I put together a tcp_socket object that made it easier to work with the \Device\Afd interface that I’ve been playing with.

Adventures with \Device\Afd - test driven design

I’ve been investigating the ‘sparsely documented’ \Device\Afd interface that lies below the Winsock2 layer. Today I use a test-driven method for building some code to make using this API a little easier. Using the API In my previous posts on the \Device\Afd interface I focused on exploring and understanding the API itself. Since it’s ‘sparsely documented’ I used unit tests to explore and record my findings. This has left me with some code that is easy to come back to and pick up, which is lucky since it’s been quite a while since I last had some time to tinker with it.

How little things kick you out of the zone

I had an internet outage this morning. This shouldn’t have been much of a problem for me as all of the code that I needed to be working on is on my local git server and all of the dependencies are local. Or so I thought. The client has a c# shim layer that builds as part of the C++ server build. They rely on NuGet to grab some components from somewhere for some reason.

Adventures with \Device\Afd - test driven understanding

I’ve been investigating the ‘sparsely documented’ \Device\Afd interface that lies below the Winsock2 layer. Today I use a test driven method for understanding and documenting the API. TDU - Test Driven Understanding When trying to understand a new API I always like to end up with executable documentation in the form of tests that show the behaviour of the API. I write these tests in the same way that I write any tests; writing a test that fails and then adjusting so that it passes.

Quick and dirty analysis of memory allocations in Visual Studio code

Yesterday I was bemoaning encapsulation and how it was hiding what was going on inside my objects (and quite right too, what good would it be otherwise?). The issue is that the object I was interested in, and each of the objects that formed it, were allocating more memory that expected. It wasn’t so much that the object was bigger than expected, just that there were more allocations than I expected and that for some reason destroying lots of these objects is taking longer than I would expect.

The cost of encapsulation

I’m debugging performance issues with a C++ server that has been stalling and then failing to recover. I’ve reached a point where we can generate the problem using a network interruption that causes multiple connections to disconnect at the same time. The fixed sized thread pool that services these connections becomes overloaded with work that requires it to clean up connection objects for the disconnected connections and all of the threads in the pool spend far too long fighting over the lock to the heap as they try and return memory to it to clean up the connection objects.

Building OpenSSL 3.x for x86 and x64 on Windows for side by side deployment

Back in August 2012 I shared my scripts for building OpenSSL on Windows. These have changed a little since the ones I had for the 1.0.x and 0.9.x releases of OpenSSL. The main idea is the same, the scripts build the OpenSSL code as both static libs and DLLs for both x86 and x64 and allow you to have all of the files next to each other in the same directory by adding various ‘warts’ to the file names.

Practical Testing: 41 - GoogleTest

I’ve been writing a series of blog posts, called “Practical Testing”, about testing real-world, multi-threaded code. Up until now I’ve used my own, home grown, unit testing framework. When I started out with this series back in 2004 there wasn’t much in the way of mature testing frameworks for C++ and, over the years I haven’t really found a need to switch from my own stuff that I understand and that works pretty well.