Last time I looked at way of using \Device\Afd to perform individual socket polling for readiness. This differed from the previous approach to using \Device\Afd, which batched up the sockets and issued a single poll for multiple sockets.
The individual socket polling approach appeals to me as it would appear to scale more easily, and putting together an echo server that supports multiple connections is now much easier. It doesn’t map as well to the way other operating systems do things though, so if that’s your primary goal, then you’re probably better off continuing with the ‘set of sockets’ approach.
Recently, I’be been exploring socket readiness notifications on Windows using the \Device\Afd interface. My initial forays into this were from a Linux epoll direction as the use of the \Device\Afd API provides a similar interface to the epoll API and makes it possible to build something almost the same on Windows which can help when writing cross platform code.
I’d got to the point where I had a simple client and server working nicely and had taken a pause before the next step which was to add support for multiple sockets.
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 https://github.com/Emjayen/napi 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.
Recently I spent quite a long time debugging a heap corruption bug. When I eventually found the issue, it was such a classic buffer overrun bug that it was actually quite laughable how long it had taken to track it down. It was just SO obvious that I immediately spotted it as soon as I looked at the code. The problem was that it took me so long to actually look at this piece of code.
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.
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.
Back in 2009 I started playing around with embedded assembly language on simple hardware with the intention of building a robot spider. This was hosted on a separate website, L’Hexapod.com It was a lot of fun but once my children came along the project took up too much time for me to focus on it.
Back in 2010 I thought that the birth of my first son, Scott, would be just a small blip in my journey into robotics but, looking back, it seems to have been the end of that chapter.
When your machine has multiple NUMA nodes it’s often useful to restrict a process to using just one for performance reasons. It’s sometimes hard to fully utilize multiple NUMA nodes and, if you get it wrong, it can cost in performance as the nodes need to keep their caches consistent and potentially access memory over a slower link than the memory that is closer to the node, these things can be relatively expensive.
I’ve had a sick PC for several weeks now. It has cost me a surprising amount of time and thought.
It started with my main work machine randomly hanging. This is Windows 11 with a Ryzen 9 5900X, and it has previously run faultlessly for two years or so. The hangs were, at first, annoying and I assumed that it was some driver that had been updated and was playing up, and initially I hoped that it would just fix itself with another update.
The manual process around updating broken links is due to be replaced by a simple link checker that I’ve been writing in Rust. It’s not quite ready yet but it’s nearly there…
I was updating a few broken links today and came across this from 2004;
“Software development is about discipline and detail; code quality starts to decay as soon as developers forget this. All code decays, but tests can help to make this decay obvious earlier.
