Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

From: Christian Kauhaus (ckauhaus_at_[hidden])
Date: 2006-04-03 08:24:56

Bogdan Costescu <Bogdan.Costescu_at_[hidden]>:
>What you propose here should work for the case of a single BTL that
>handles both IPv4 and IPv6. How about the case of 2 BTLs ? (as it's
>not clear to me from the rest of the discussion if one solution is
>better than the other)

The introduction of a new 'tcp6' BTL was mentioned several times in the
discussion. This would result in an enormous amount of duplicated code,
since the IPv4->IPv6 transition would only affect a small fraction of
the total tcp BTL codebase. This is clearly a violation of the DRY
principle (don't repeat yourself).

>Myrinet at the same time with GM over Myrinet, which also brings it to
>2 (or even 3) protocols over the same physical connection. So how
>should these situations be handled ? (this is more of a general
>question, not related to IPv6 implementation).

Very good point. Since we do not have Myrinet or IB in our institute
clusters, I cannot tell. Experiences and suggestions from others?

>Err, it's not OpenMPI, but the rsh/ssh client that tries the
>connections. My point however is a bit different as it also relates to
>the authentication behind the connection, where the IP (and therefore
>its flavour) which is used for making the connection counts:

When using rsh for startup, any interference between IPv6 and rsh/ssh is
beyond the scope of OpenMPI. I really don't know which part of the
OpenMPI code base is able to influence how rsh will authenticate some
addresses. If rsh/ssh cannot handle or authenticate IPv6 connections,
the admin must keep the IPv6 addresses out of the resolver, so that
getaddrbyhost() never returns an IPv6 address. That's it.

>> For example, we ran several weeks without an IPv6-enabled rsh, which
>What do you mean by "IPv6-enabled rsh" ? Was it the daemon, client or
>both ?

We had both client and server IPv6-enabled and IPv6 addresses in the
resolver, but the server did not listen on the IPv6 socket, resulting in
a connection failure for IPv6. The subsequent connection attempt with the
IPv4 address did succeed though.


Dipl.-Inf. Christian Kauhaus                               <><
Lehrstuhl fuer Rechnerarchitektur und -kommunikation 
Institut fuer Informatik * Ernst-Abbe-Platz 1-2 * D-07743 Jena
Tel: +49 3641 9 46376  *  Fax: +49 3641 9 46372   *  Raum 3217