Bogdan Costescu :
>I beg to disagree. In a setup like the one mentioned, after orted is
>started via an IPv4-only rsh/ssh, OpenMPI applications could use IPv6
>without problems, just like they could use f.e. GM if Myrinet cards
>would be present. I see this very much like your past experience wi
* Bogdan Costescu wrote on Mon, Apr 03, 2006 at 05:34:56PM CEST:
>
> IMHO code can simply be shared and only the really different part
> should be made independent. This is more a question of whether the
> build system would allow such a scheme and of the runtime behaviour
> (for static linking
On Mon, 3 Apr 2006, Christian Kauhaus wrote:
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).
IMHO code can s
I think that would be okay - certainly makes a good starting point! If
it becomes an issue later, we can revisit at that time.
Thanks
Ralph
Christian Kauhaus wrote:
Ralph Castain :
Actually, we have some sensor network folks that are interested in
using OpenRTE for their ap
Ralph Castain :
> Actually, we have some sensor network folks that are interested in
> using OpenRTE for their applications. Their platforms can be small
> microprocessors, many with custom mini-operating systems. Almost
> none support IPv6 nor have any knowledge of that protocol.
I see. D
Bogdan Costescu :
>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 mentio
On Fri, 31 Mar 2006, Christian Kauhaus wrote:
So the resolver already does the complicated work for us, since it
returns all addresses associated to a given target (hostname or
IP-addr notation) in the order of decreasing preference.
What you propose here should work for the case of a single
