On Thu, Sep 07, 2006 at 07:51:28PM +0200, Adrian Knoth wrote:
> No problem, just two hours ago, Christian and me decided to drop
> the idea of oob/tcp6 and go on with only one oob-tcp-component.
> It shouldn't be that hard and I'll try it tonight or tomorrow.
Looks quite promising:
adi@ipc654:~/ompi/trunk/test$ (orterun -np 2 -host amun,ipc654 netstat -tpln)
2> /dev/null | grep orte
tcp 0 0 0.0.0.0:44012 0.0.0.0:* LISTEN
1332/orted
tcp 0 0 0.0.0.0:42706 0.0.0.0:* LISTEN
1329/orterun
tcp 0 0 0.0.0.0:36376 0.0.0.0:* LISTEN
27961/orted
tcp6 0 0 :::56783 :::* LISTEN
27961/orted
tcp6 0 0 :::34615 :::* LISTEN
1329/orterun
tcp6 0 0 :::39837 :::* LISTEN
1332/orted
This is one component with two listening sockets.
The main work isn't done yet: the mca_oob_tcp_peer_start_connect.
I've extended it a little bit:
static int mca_oob_tcp_peer_start_connect(mca_oob_tcp_peer_t* peer,
uint16_t af_family);
where af_family is one of {AF_INET, AF_INET6}. I start with AF_INET
and within mca_oob_tcp_peer_start_connect, I call this function
again with AF_INET6 (one level of recursion) to try the other
address family.
This approach (coded last week when I still had a single component)
is bad (long timeouts before trying AF_INET6) and probably wrong:
for the accepting sockets, I've added
opal_event_t tcp6_send_event;
opal_event_t tcp6_recv_event;
and perhaps something like this is necessary for peers, too (don't
know this, yet. I'll have a look at it tomorrow).
So long
--
mail: a...@thur.de http://adi.thur.de PGP: v2-key via keyserver
Frauen verstehen entweder gar nichts oder alles falsch
