Tue Aug 24 10:38:04 CEST 2010
Unless one is trying to bind to a raw socket, I'd say that the behavior
implemented by Linux is the "proper" one, for socket is bound to the
transport end point, thus, regardless which network protocol you're
referring to, it should report EADDRINUSE.
In other words, using different networking protocol should not create
another address space at the transport layer.
Having said this, I am not quite sure if the same holds for multi-homed
host. For example, even if we're talking IPV4 only, but have a multiple
interfaces, if you bind to port P1 on the interface I1, should another
application be allowed to access P1 from another interface, say I2?
IMO -- not at all, for transport access point should be the same regardless
of which networking protocol is utilized.
From: [mailto:] On
Behalf Of Per Hedeland
Sent: 23 August 2010 07:12 PM
Subject: [erlang-questions] IPV6_V6ONLY
On Linux (and maybe some others), by default, when binding a socket to
the IPv6 wildcard address, the socket accepts both IPv6 and IPv4, the
latter in the form of IPv4-mapped IPv6. Trying to bind another socket
with the same port and the IPv4 wildcard results in EADDRINUSE.
On *BSD, by default (and always on Windows I believe), the situation is
the opposite - the IPv6-wildcard socket accepts only IPv6, and you need
to bind another socket for IPv4 if you want to support both.
I believe there is some consensus in the networking community that the
first behaviour is "bad" for various reasons. Be that as it may, it is
unlikely to change, and it seems applications tend to ensure the second
behavior by means of unconditionally using the IPV6_V6ONLY socket option
in order to get consistent behavior across OSes (and avoid the "badness").
Since one strong point of Erlang/OTP is to as far as possible isolate
the Erlang programmer from these annoying differences between OSes,
could it be considered to make inet_drv always apply IPV6_V6ONLY (if it
exists) for IPv6 sockets?
erlang-questions (at) erlang.org mailing list.
To unsubscribe; mailto:
More information about the erlang-questions