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.
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.
So, this morning I’m back from my Easter break and working on some code for a client and the first thing I do is kick off my CI build and things start failing. It seems that my “cunning plan” to have my CI build use the preview version of Visual Studio 2022 whilst the client uses earlier versions has paid off again…
We build with all warnings enabled and treat warnings as errors.
As of the latest Chrome, Edge, Opera, and FireFox updates all of my ‘obsolete’ hardware (routers, NAS drives, network switches, etc) are inaccessible as they don’t use TLS 1.2. I’m unlikely to be alone in this. I can understand the technical decision but IMHO it’s wrong and, actually pretty stupid. To make it more than a click through warning to access these obsolete devices on my local subnet. Sure ban connections to other subnets (that would cause me pain too as I manage some stuff via a VPN) but 90% of users would be fine.
UPDATED: 23 August 2021 see here
As I mentioned a while ago, it seems there’s a strangely fatal bug in the Windows networking stack at present. This manifests as massive non-paged pool memory usage if a process creates a UDP socket, binds it to an address and fails to read from it faster than other people are writing to it. The issue appears to be present on all current Windows operating systems but is NOT present on Windows Server 2012 R2 if recent patches have NOT been applied but IS present as soon as the box is patched up to date… My test box was patched up until March 2020 and ran fine, as soon as it was patched to June 2020 it started to behave badly.
UPDATED: 23 August 2021 see here
One of my clients runs game servers on the cloud. They have an AWFUL lot of them and have run them for a long time. Every so often they have problems with DDOS attacks on their servers. They have upstream DDOS protection from their hosting providers but these take a while to recognise the attacks and so there’s usually a period when the servers are vulnerable.
I tend to develop code with JITT (Just in time testing), this is like TDD when I’m doing it but it doesn’t always get done. What does get done, generally, is the “first test” for each class. This ensures that subsequent testing is possible as the code doesn’t have hidden dependencies and it gives me a test harness that’s ready to go when I find that I need it. More complex code end up being TDD, easier bits end up as JITT where the tests are only written when I’ve wasted time banging my head on the desk trying to debug problems the “old fashioned way”.
So, it’s nearly a year since I first started noticing issues with VS2015 on my build servers. The bug in question now has an entry on Microsoft Connect and Google can help with some work arounds which don’t require turning the machine off and on again a random number of times until it works… There’s even a Visual Studio extension that fixes the issue for you (!).
I find it disappointing that this hasn’t been fixed, it’s a fundamental usability issue which seems to be causing lots of people lots of pain.
I’m looking at adding support for the TLS Application-Layer Protocol Negotiation Extension to The Server Framework as a precursor to looking into HTTP 2.0 support. This TLS extension is supported by both SChannel and OpenSSL. It’s relatively new (only having been included in SChannel since June 2014 (!)) but there seems to be no documentation on MSDN for the structures and how to use them to add the appropriate entries to the TLS handshake and then to select and validate the protocol of your choice… Searching today with Google for something like “SEC_APPLICATION_PROTOCOL_NEGOTIATION_EXT” just gives just the usual selection of hits to people who think it’s clever to run the Windows header files through their document generators and then publish the results on the web…
There should be a Developer Advocate position within Microsoft. They seriously need someone who doesn’t “Drink the Kool-Aid” who can step in and tell the Program Managers or Marketing bods or whoever it is who makes all the really STUPID decisions that the decision is stupid and that they should get back in their box and leave the developers who support the Windows ecosystem by building software that runs on it to just get on with their lives…
