This is, in part, a feature request (that I'm happy to implement myself) and seeing if you have a solution already.
As you probably remember from Google, allocating one-off unique ports for tests is kind of a problem. I have various tests (integration and otherwise) that spin up processes or modules that talk to each other via udp/tcp sockets (or at least, must open them). I currently use the "port-zero" trick: the test runner opens a socket with port 0, reads the kernel-allocated port number, closes the socket, and passes that port number to the processes or modules. Obviously, that is racy. At Google, there was a port allocation mechanism (that I think was baked into the distros, not sure exactly how it worked) to solve that problem. I haven't found any open-source equivalent, and searching or asking Gemini basically comes back with either "it's such a rare race condition, don't worry about it" or "just spin up a docker for every individual test". I disagree with those solutions, obviously.
So, here's the idea. Have a port-allocation server process that a test runner can spawn that is accessible through a unix-socket, like the subspace server. When a process / module wants to open/bind a network socket, it would use the same interface as it currently does, except using something like a RemappedPortAddress (or whatever name, naming is always the hard part!). When you open a socket with such an address, instead of directly calling the posix functions, it asks, via the unix-socket, the server to open a network socket. Then, that server opens a port-zero socket and passes the FD (and real port number) to the client. And records the port mapping in a table, so that if another process wants to receive data from a remapped port, it can also discover the real allocated port by asking the server. Effectively, making this port-allocating server a kind of private space of ports (that don't need to be dynamically reconfigured by the test runner) that maps fixed/hard-coded client ports to underlying available ports on the system and can do all that in a race-free manner.
First question is, of course, whether there is an obviously better existing solution that I totally missed.
If not, I thought that adding this solution to this library would make sense as it would allow for everything to be neatly wrapped inside the socket interfaces of this library. I could always implement this scheme on top of this library, but that would add an ugly layer of wrappers or an ugly extension (I don't like, in general, to have new classes derived from the base classes of an external library).
This is, in part, a feature request (that I'm happy to implement myself) and seeing if you have a solution already.
As you probably remember from Google, allocating one-off unique ports for tests is kind of a problem. I have various tests (integration and otherwise) that spin up processes or modules that talk to each other via udp/tcp sockets (or at least, must open them). I currently use the "port-zero" trick: the test runner opens a socket with port 0, reads the kernel-allocated port number, closes the socket, and passes that port number to the processes or modules. Obviously, that is racy. At Google, there was a port allocation mechanism (that I think was baked into the distros, not sure exactly how it worked) to solve that problem. I haven't found any open-source equivalent, and searching or asking Gemini basically comes back with either "it's such a rare race condition, don't worry about it" or "just spin up a docker for every individual test". I disagree with those solutions, obviously.
So, here's the idea. Have a port-allocation server process that a test runner can spawn that is accessible through a unix-socket, like the subspace server. When a process / module wants to open/bind a network socket, it would use the same interface as it currently does, except using something like a
RemappedPortAddress(or whatever name, naming is always the hard part!). When you open a socket with such an address, instead of directly calling the posix functions, it asks, via the unix-socket, the server to open a network socket. Then, that server opens a port-zero socket and passes the FD (and real port number) to the client. And records the port mapping in a table, so that if another process wants to receive data from a remapped port, it can also discover the real allocated port by asking the server. Effectively, making this port-allocating server a kind of private space of ports (that don't need to be dynamically reconfigured by the test runner) that maps fixed/hard-coded client ports to underlying available ports on the system and can do all that in a race-free manner.First question is, of course, whether there is an obviously better existing solution that I totally missed.
If not, I thought that adding this solution to this library would make sense as it would allow for everything to be neatly wrapped inside the socket interfaces of this library. I could always implement this scheme on top of this library, but that would add an ugly layer of wrappers or an ugly extension (I don't like, in general, to have new classes derived from the base classes of an external library).