This web mail archive is frozen.
This page is part of a frozen web archive of this mailing list.
You can still navigate around this archive, but know that no new mails
have been added to it since July of 2016.
Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.
On Mar 31, 2006, at 10:15 AM, Adrian Knoth wrote:
> On Fri, Mar 31, 2006 at 09:36:31AM -0500, Jeff Squyres (jsquyres)
>> I have no personal experience with IPv6, but one thought that
>> strikes me
>> is that the components might be able to figure out what to do by
>> at/parsing either the hostnames or the results that come back from
>> resolving the hostname...?
> Yes. You can ask the resolver for v4, v6 or any of them.
> The libc functions are standardized and handle both.
> The socket family, too. You just have to specify whether
> to use AF_INET or AF_INET6. That's all.
> Due to the new lookup functions, DNS lookups now return
> a linked list of dynamically allocated memory containing
> the results for probably multi homed hosts. The common way
> is to iterate over this list, try every given address/information
> and manually free the memory afterwards.
> The whole process in its naive implementation is straightforward.
> Are we getting trouble with listen()/accept()? If we use
> v6-mapped-v4 (::ffff:a.b.c.d/96), we only have one socket
> to bind to and to listen on. But if we create two separate
> sockets, are they non-blocking to each other? So to say:
> does OMPI already handle more than one listen socket?
> Would this be a problem in case of a btl/tcp6-component?
> (I really prefer the v6-mapped-v4 solution with a single
> socket, thus eliminating this problem)
We use an event library and select() to determine when things are
pending on sockets. However, I have to say that I would prefer have
one tcp btl / oob component and have it do the right things
internally. The space difference for storing an IPv6 vs IPv4 address
isn't that huge and maintaining all the extra code will be a
nightmare. At least, that's been my experience with similar things
in the past. Just my $0.02, of course.
The other question is what to do on platforms without IPv6 support.
I'm pretty sure we're going to run into them, so it would be good to
plan along those lines....