SO_REUSEPORT and gen_tcp
Mon May 22 13:17:38 CEST 2006
Well, I will take your answer as simply that nobody actually has asked
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
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
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