title: Reserve a TCP port in Windows
body: <p>I'd like to reserve a TCP port, to be bound by a service later, so that Windows doesn't inadvertently use the same number when assigning random port numbers. I know this is possible via the registry and a reboot, but I would like to avoid such a heavy-handed solution.</p>
  <p>How can a process reserve a port without actually binding/listening to it, and then safely (i.e., avoiding race-conditions) hand it over to another process on request?</p>
  <p>The port number needn't be determined in advance. It's OK for the first process to acquire a random port number, and pass it to the requesting process.</p>
  <p><strong>EDIT:</strong> It occurs to me that my question is somewhat poorly stated. What I really want is to separate the allocation of a dynamic port number from the bind-to-port-zero operation. This means not just avoiding accidental random allocation of that port number, but also preventing any other process from binding to the same address/port in the interim. Or, putting it another way, I want one process to start the bind-to-port-zero operation — immediately learning the port number that will be used — and let a nominated second process complete the bind operation sometime in the future.</p>
  <p>At the moment, the closest work-around I can think of is for the first process to bind to address/0 immediately, and stay bound until the second process requests it, at which point it unbinds and tells the other process the port number it acquired, which then binds to the address/port explicitly. This has two problems: 1) I'd rather not bind at all until the second process comes along; 2) there's a small time interval during which a third party could accidentally (or deliberately) usurp the port.</p>
  <h3>Background</h3>
  <p>You may be curious as to why I wish to do something so odd. I've been toying with ZeroMQ, and one major limitation is the absence of the <code>ipc://</code> transport on Windows. It struck me that a port mapper process (akin to the RPC endpoint mapper, or Erlang's epmd) would be just the ticket to implement a work-around using the <code>tcp://</code> transport with dynamic port allocations. However, ZeroMQ clients and servers are allowed to connect out of order (i.e., it isn't an error for the client to connect before the server binds), so I am trying to figure out how a connecting client can discover — with a very high degree of certainty — the port that will be used to communicate, before a server actually binds to that port.</p>