SO_REUSEPORT and gen_tcp

Andrew Lentvorski <>
Mon May 22 13:17:38 CEST 2006

Well, I will take your answer as simply that nobody actually has asked 
for it.

I was more interested if there was some sort of problem with this kind 
of overloading of multiply bound sockets to the same address.  I see no 
reason for there to be (everything looks normal since the OS handles 
dispatching everything and it all looks like normal sockets at the API 
level), but I wanted to check before just blindly adding the option to 
the Erlang source code.

Fredrik Thulin wrote:

> Even though it's called reuseaddr, the documentation you quoted above 
> says it is about port numbers. reuseaddr is, in my experience, 

I believe that you are correct on Windows.  However, I do not believe 
that is correct on any of the Unix flavors.

There the two options have different semantics and do not imply one another.

SO_REUSEADDR primarily allows servers to be restarted even before the 
TCP timeouts close a previous socket.  This is primarily useful when 
servers crash.

SO_REUSEPORT actually allows completely duplicate socket bindings for 
the same local IP address/port combination.  This is not the case for 
SO_REUSEADDR.  It was supposed to be used for multicast, but has turned 
out to be useful for getting past NATs.

The advantage here is that the same local IP address/port can be used for:

1) a connection to a rendezvous server to discover the external mapping
2) an initiated connection to the other peer to open a hole in the NAT
3) the bind() so that an incoming connection on that port can connect.

> Btw, if you're into NATs (which I'm not), you might be interested in 
> STUN. I have a basic STUN server written in Erlang in the YXA source 
> repository.

STUN is unfortunately only useful for UDP.  For most applications, you 
wind up having to duplicate some of the semantics of a TCP stack 
(retransmission and throttling, primarily), anyway.  Consequently, it is 
generally worth the extra pain to punch the hole using TCP rather than UDP.


More information about the erlang-questions mailing list