#2391 Network.listenOn (PortNumber n) Sometimes Picks IPv6
cjs at starling-software.com
Mon Jul 21 07:43:10 EDT 2008
On 2008-07-21 10:09 +0000 (Mon), Aaron Denney wrote:
> On 2008-07-21, Curt Sampson <cjs at starling-software.com> wrote:
> > 1. Listening on both IPV4 and IPV6, if I recall correctly,
> > introduces all sorts of interesting problems, and basically, you
> > don't want to go there. Or am I wrong about that?
> I don't see why it would introduce any more problems than listening
> on multiple IPv4 addresses, which is routine.
If I recall correctly:
If you're listening on interface '*', you just call accept() and block.
If you want to listen on two separate sockets, you can't do this. You
can listen on IPv4 and IPv6 addresses using one socket by using IPv4 to
IPv6 translation, but that was what got interesting.
I think that this was more or less what you were saying.
Anyway, I'm quite happy with having listenOn listen on all interfaces
that implement v4 and all interfaces that implement v6; it's just
whether it's implementable in some reasonable way that I worry about.
And you'll note, for example, we already distinguish between a PortID
for listening to "one of v4 or v6, depending on OS" (PortNumber Int) and
for listening on Unix domain sockets (UnixSocket String).
> Basically, my position is that listenOn is the wrong interface -- it
> should take the host addresses as well as the port.
Well, perhaps the idea there was that if you wanted to start doing this,
you should be using Network.Socket instead of Network, anyway.
> The ports are the same namespace -- it shouldn't matter (much) whether
> TCP is running over IPv4 or IPv6.
If you bind by hostname (e.g., "localhost") they have separate
namespaces. I suppose you could take only addresses, but then you need
some way to construct them, and before you know it you're starting to
get as complex as Network.Socket.
> We could get around this by returning a composite pseudo-socket,
> representing both, and modifying Network.accept to take this
> pseudo-socket and wait for connections on any of the real sockets.
> But it's a bit ugly. And these pseudo-sockets won't work with
> Network.Socket.accept. If we give it a new type, I'm not entirely sure
> it's that bad a thing though.
That's not an unreasonable option. But it's a lot more work to implement.
I think at this point I'm preferring the simple thing: just go for
PortNumber Int and PortNumber6 Int data constructors, and if you want to
do better than that, use Network.Socket.
Curt Sampson <cjs at starling-software.com> +81 90 7737 2974
Mobile sites and software consulting: http://www.starling-software.com
More information about the Libraries