Wait wait wait, so we’re not talking about nix yet?

Well, no! The service we have is pretty simple, and I want to complicate things a bit, to show how things would work in both the Dockerfile and the nix scenario.

And because I don’t like contrived examples, we’re going to do something somewhat real-world: we’re going to geo-locate visitors, and track how many visits we get from each country.

In the last article, we found where code was hiding in our samples/hello executable, by disassembling the whole file and then looking for syscalls.

Later on, we learned how to inspect which memory ranges are mapped for a given PID (process identifier). We saw that memory areas weren’t all equal: they can be readable, writable, and/or executable.

Up until now, we’ve been loading a single ELF file, and there wasn’t much structure to how we did it: everyhing just kinda happened in main, in no particular order.

But now that shared libraries are in the picture, we have to load multiple ELF files, with search paths, and keep them around so we can resolve symbols, and apply relocations across different objects.

In our last installment of “Making our own executable packer”, we did some code cleanups. We got rid of a bunch of unsafe code, and found a way to represent memory-mapped data structures safely.

But that article was merely a break in our otherwise colorful saga of “trying to get as many executables to run with our own dynamic loader”. The last thing we got running was the ifunc-nolibc program.

Async fn in trait… not

I was planning on showing the in-progress async_fn_in_trait feature in the context of my website, but it turns out, I can’t!

My website uses two databases: one local SQLite database for content, and a shared Postgres database for user credentials, preferences etc. Migrations are run on startup, and each migration implements one of the following traits:

ooc makes it easy to compile your application on all major platforms (Windows, OSX, Linux) - the compiler itself runs there, and the SDK supports all these platforms with basic functionality: data structures, file handling, time handling, networking, etc.

But between getting your application running on your dev environment with all the libraries installed, and getting it into a neat package for your users to run without having to install any dependencies by hand, there’s a bag of tricks. Fortunately, I have found the time to figure most of them out. I’ll try to explain these in detail here as clearly as possible, here in this article.

We’ve just spent a lot of time abstracting over LoadLibrary, but we still have all the gory details of the Win32 ICMP API straight in our main.rs file! That won’t do.

This time will be much quicker, since we already learned about carefully designing an API, hiding the low-level bits and so on.

Let’s add an icmp module to our program. Actually, we’ve been dealing with an IPAddr all this time, it also sounds like it could use its own package:

With the previous part’s VM still running, let’s try connecting to our machine over SSH.

Network addresses, loopback and IP nets

Normally, to connect to a machine, you’d find its IP address. On Linux, a decade ago, you would’ve used ifconfig. Nowadays you can use ip addr:

The loopback interface (lo) is local, so it’s not useful to reach the box from the outside: you can see it can be accessed over IPv4 at address 127.0.0.1 but not just! What we’re reading here is 127.0.0.1/8, which corresponds to the range 127.0.0.1 - 127.255.255.255

As the popular saying goes, there are only two hard problems in computer science: caching, off-by-one errors, and getting a Rust job that isn’t cryptocurrency-related.

Today, we’ll discuss caching! Or rather, we’ll discuss… “request coalescing”, or “request deduplication”, or “single-flighting” - there’s many names for that concept, which we’ll get into fairly soon.