On Sat May 14 04:09:08 EDT 2011, r...@hemiola.co.uk wrote: > I notice that the dial implementaion has recently changed to support > dialling multiple ip addresses in parallel. > > If one dials a single-ip host that isn't responding to ip packets > then, after the tcp timeout expires, errstr is set to "connection > refused". > > If however one dials a host that has multiple ip addresses and none of > them respond then errstr is set to "progname pid: alarm". > > This doesn't seem consistent. Would it be possible to have "connection > refused" set in the second case too? I think both scenarios are > essentially the same as far as client code is concerned.
it also introduces some non-determinism that might be trouble. suppose that you can start an ip6 and ip4 connection, but for some reason the ip4 path has a too-low mtu, and no icmp return. with the first packet in winning, it's up to luck if the connection will work or not. it's not too hard to think about other reasonable situations that might usually fail. suppose that you have a ssh-based tunnel that you prefer to use. if the dialing sequence returned by cs also includes a non-encrypted path, you're pretty likely to get the unencrypted path returned first. the first thing that comes to mind as a solution is a pre-determined order. and a delay proportional to the time it takes to get the first response. but maybe that's too fancy. and, maybe at the same time not fancy enough. - erik
