SO_REUSEPORT and gen_tcp
Andrew Lentvorski
bsder@REDACTED
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,
> SO_REUSEPORT.
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.
-a
More information about the erlang-questions
mailing list