[9fans] new dial, cs and dns for ipv6

[9fans] new dial, cs and dns for ipv6

[geoff at plan9.bell-labs.com]

Now that the world at large is waking up to IPv6, one problem I kept
tripping over is that dial(2) tries addresses serially, and since it's
not unusual for IPv6 connectivity to be broken, and since DNS servers
randomise the order of IP addresses they return, it's quite possible
to hang for a long time trying to connect to a v6 (or, with
multi-homing, v4) address before getting to one that works.

I've just pushed out to sources a new dial implementation and changes
to ndb/cs and ndb/dns to cope better in this new world, including
updated manual pages.

The new dial dials multiple addresses concurrently and uses the first
connection that completes.  The dial change will cause dozens of
programs to be recompiled on sources later today.

ndb/cs will now return IPv6 addresses obtained from DNS AAAA records
when queried for IP addresses.  This behaviour can be disabled by
invoking cs with -4 and can be toggled by writing "ipv6" to /net/cs.

ndb/dns now has shorter time-outs and fewer UDP retransmissions, and
uses millisecond (rather than second) resolution internally for most
time-outs.  If this is a problem for you, you may want to adjust the
enum constants at the top of ndb/dnresolve.c, but beware that they can
multiply connection delays.

[9fans] new dial, cs and dns for ipv6

[erik quanstrom]

good deal.  thanks, geoff.  i look forward to trying this
out.

one problem i've kept tripping over is a purely internal
and mechanical one.  ndb doesn't ever refresh its databases
line.  this is a problem at coraid, since each engineer has
a /120 network, and a ndb file to match (this facilitates
finding owners).  and we are happier to see a new face
and add a databases line, than to reboot all the cpu servers.

i have a solution that causes the databases line to be reread,
if anyone has interest.  i'm sure it could be more elegantly
done.  but it does make programs like consolefs(8) work
much more as expected.

- erik

[9fans] new dial, cs and dns for ipv6

[cinap_lenrek at gmx.de]

what about libthread programs that call dial from a shared threads
stack?  you can't call rfork(RFPROC) there.

--
cinap
-------------- next part --------------
An embedded message was scrubbed...
From: geoff at plan9.bell-labs.com
Subject: [9fans] new dial, cs and dns for ipv6
Date: Thu, 17 Mar 2011 15:42:28 -0400
Size: 3045
URL: <http://mail.9fans.net/private/9fans/attachments/20110317/637e8794/attachment.mht>

[9fans] new dial, cs and dns for ipv6

[cinap_lenrek at gmx.de]

correction: you can't do RFMEM|RFPROC.  RFPROC alone should work as long as
your current stack is not shared between the two processes.

i see some possible ways to implement multidial() without sharing memory
between the call workers and the caller of the dial().

use the waitmsg or a pipe to signal back a successfull dial job.

the caller can preallocate a filedescriptor per worker before fanout
and the worker signals successfull dial with a empty empty exit
string. or the dialed numerical filedescriptor number is returned in the exit
string or send on a pipe.

another way would be a shared segment, but thats kind of overkill and
ugly too.

--
cinap
-------------- next part --------------
An embedded message was scrubbed...
From: cinap_lenrek at gmx.de
Subject: Re: [9fans] new dial, cs and dns for ipv6
Date: Thu, 17 Mar 2011 21:23:37 +0100
Size: 5719
URL: <http://mail.9fans.net/private/9fans/attachments/20110317/48103708/attachment.mht>

[9fans] new dial, cs and dns for ipv6

[geoff at plan9.bell-labs.com]

Such programs need to be changed to use a proc rather than
a thread for dialing (or linked with the old version of dial.c
temporarily).  Sorry.

[9fans] new dial, cs and dns for ipv6

[cinap_lenrek at gmx.de]

the problem is that libthread procs are just threads running in a
separate plan9 proc, but still have ther stacks on the heap and not in
the plan9 stack segment.  so even iodial() will break with the new
multidial implementation.

--
cinap
-------------- next part --------------
An embedded message was scrubbed...
From: geoff at plan9.bell-labs.com
Subject: Re: [9fans] new dial, cs and dns for ipv6
Date: Thu, 17 Mar 2011 16:59:27 -0400
Size: 2152
URL: <http://mail.9fans.net/private/9fans/attachments/20110317/f601bd4b/attachment-0001.mht>

[9fans] new dial, cs and dns for ipv6

[erik quanstrom]

On Thu Mar 17 17:01:51 EDT 2011, geoff at plan9.bell-labs.com wrote:
> Such programs need to be changed to use a proc rather than
> a thread for dialing (or linked with the old version of dial.c
> temporarily).  Sorry.

i suppose that one could trot out an old trick and do

static int (*_dialrforkimpl)(int) = rfork;

int
_dialprocrfork(int)
{
	procrfork(...);
}

and let the thread library set this up, along with the few
other library functions that need to be overridden?

- erik

[9fans] new dial, cs and dns for ipv6

[cinap_lenrek at gmx.de]

thinking about it more...  all what needs to be parallelized is the
write of the connect message so no backchannel is needed except
for reporting error/success (already done with the waitmsg in
geoffs implementation).

so it looks quite doable without any shared memory.

still, might take some time to come up with a small and clean
implementation.

so what are you going todo for now geoff?

a lib9p like forker that gets filled in by libthread is kind of a
overkill.  also the code would need rewriting as you cant preserve
rfork semantics with shared stacks (you need to pass a function
pointer and arguments because the child has to run on a new allocated
stack).

--
cinap
-------------- next part --------------
An embedded message was scrubbed...
From: erik quanstrom <quanstro at labs.coraid.com>
Subject: Re: [9fans] new dial, cs and dns for ipv6
Date: Thu, 17 Mar 2011 17:38:03 -0400
Size: 2561
URL: <http://mail.9fans.net/private/9fans/attachments/20110317/123b5f2d/attachment.mht>

[9fans] new dial, cs and dns for ipv6

[cinap_lenrek at gmx.de]

theres a first attempt of a parallel dial implementation that doesnt
need shared memory to coordinate the the spawning:

/n/sources/contrib/cinap_lenrek/dial.c

it will run at maximum Maxconcurr connects in parallel at a time
until there are no more addresses to connect to left, a connection
is established or it got interrupted.

if there is only one address, it will not fork and do synchronous
connect.

its not more complicated than the shared memory version in my opinion
and will work with libthread programs without any tricks.

--
cinap

[9fans] new dial, cs and dns for ipv6

[erik quanstrom]

On Fri Mar 18 19:23:13 EDT 2011, cinap_lenrek at gmx.de wrote:
> theres a first attempt of a parallel dial implementation that doesnt
> need shared memory to coordinate the the spawning:
> 
> /n/sources/contrib/cinap_lenrek/dial.c
> 
> it will run at maximum Maxconcurr connects in parallel at a time
> until there are no more addresses to connect to left, a connection
> is established or it got interrupted.
> 
> if there is only one address, it will not fork and do synchronous
> connect.
> 
> its not more complicated than the shared memory version in my opinion
> and will work with libthread programs without any tricks.

is the new dial+cs+dns deterministic?

that is, say that you can connect to a host via a variety of
protcols, do you always pick the same one?  or does that
just depend on who answers first?

- erik