Reserve a TCP port in Windows
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.
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?
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.
EDIT: 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.
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.
Background
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 ipc:// 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 tcp:// 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.
Answer
As mentioned by @vahapt you can modify the dynamic port range using netsh.
However, a better solution may be to use netsh to reserve the ports required by your application, leaving alone the default range of dynamic ports.
To do so:
- On Server 2008/2008 R2, install this Microsoft hotfix. This is not required on Server 2012 or later.
Stop any processes using the ports to be reserved. If a process is using a port included in the range of ports to be reserved, NETSH will return the following error and the reservation will fail:
The process cannot access the file because it is being used by another process.
Use the following NETSH command to reserve the ports:
netsh int <ipv4|ipv6> Add excludedportrange [protocol=]tcp|udp [startport=]<integer> [numberofports=]<integer> [[store=]active|persistent]For example, to reserve ports 55368-55372 for UDPv6, use the command:
netsh int ipv6 add excludedportrange protocol=udp startport=55368 numberofports=5
Notes:
- By default port reservations are persistent across reboots
- Ports may be reserved for either version 4 or 6 of a protocol, but not both (i.e. you cannot reserve port 60000 for both TCPv4 and TCPv6)
See https://support.microsoft.com/en-us/kb/929851 for more information, including how to view or delete existing port reservations.