Previously published This article was previously published on len-learns-rust.com. A full index of these articles can be found here. The first piece of code that I’m going to play with in Rust is a “reusable id manager”. This is a collection of numerical ids which can be allocated, used and then released back to a pool for later reuse. I tend to use this kind of code for network protocols where something like a peer-id is required; these ids can be within a given range (usually limited by the data type that represents them), and are “in use” for a period of time and then return to the collection.

Previously published This article was previously published on len-learns-rust.com. A full index of these articles can be found here. I’m a long term C++ programmer who is coming to Rust with lots of baggage. I’d like to write Rust in an idiomatic style but I may end up writing bad Rust in a C++ style. Hopefully people will help me avoid that. I’ve read the Rust Book1, or at least some of it.

I’ve had a client ask if it’s possible to rename his server log file whilst the server is running but not allow deletion. This is harder than you’d expect to achieve. The established view of “the internet” is that NTFS doesn’t support permissions to allow file renaming and still prevent file deletion. This is true. If you want to allow renaming you need to create or open the file with FILE_SHARE_DELETE access and this allows rename AND delete.

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.

2021 was another “interesting” year. We hope that things worked out OK for you. We’ve stayed nice and busy doing the things we love to do. So lots more C++ on various platforms for various clients. For us, and a few of our clients, 2021 was the year that NUMA really started to be a thing. Mostly, up until now, we’ve been able to ignore NUMA hardware. Most clients scale out across cheap hardware and we’re used to dealing with that.

Back in 2009 I mused on the idea of ‘breakpoint sequences’, where a breakpoint was only hit if a series of previous breakpoints have been hit. This functionality now exists in Visual Studio 2022, and it’s wonderful. It’s useful enough for me to immediately switch from VS2017 to VS2022 as my “day to day” IDE for Windows. Normally I take forever to make the move as I have tools that manage projects and solutions across all the compilers that I support, I just develop in the one that works best for me.

We’ve just found out that an email misconfiguration means that some emails to serverframework.com email addresses have been bouncing. This should be fixed now! Sorry about the inconvenience. If you have contacted us recently and not had a reply, please try again now!

As you’ll see, we released 3 new versions of The Server Framework today. Of these, only the 7.3 release includes code changes. The 7.2 release updates almost every header file in the framework to remove ‘old style’ include guards and touches lots of source files to remove lint directives that we no longer use. This kind of change creates a lot of noise in an update and so it has been done separately to the functional changes to make it easier for users of the framework to see what has actually been changed in 7.

Version 7.4 of The Server Framework was released today. This release includes no bug fixes and no new code. It removes deprecated code and removes support for Visual Studio 2015.

Version 7.3 of The Server Framework was released today. This release includes bug fixes and new code. As always, see the release notes here, for full details of all changes. Bug fixes: Fixed a bug with JetByteTools::Core::CCallbackTimerWheel which would show up if the time provider was providing ticks at a different granularity than the granularity of the wheel. Fixed a bug in CDatagramSocketConnectionManager and CDatagramSocketServer where the buffers returned in write and sendTo completion callbacks had an incorrect number of bytes set as ‘used’.