From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Sat, 21 May 2016 10:04:01 -0700 To: arisawa@ar.aichi-u.ac.jp, 9fans@9fans.net Message-ID: In-Reply-To: <9154AB0B-6527-4B44-ABEA-6CADEC4AF038@ar.aichi-u.ac.jp> References: <9154AB0B-6527-4B44-ABEA-6CADEC4AF038@ar.aichi-u.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] bug in authdial() Topicbox-Message-UUID: 922165d2-ead9-11e9-9d60-3106f5b1d025 On Fri May 20 21:48:40 PDT 2016, arisawa@ar.aichi-u.ac.jp wrote: > parallel dialing would be fine. > I guess both cinap and erik have examined labs code. > any problem with it? i don't use this code. i think the problem with parallel dial is that like the tricks we used to= play in nsec()=E2=80=94it assumes things about the calling environment. for star= ters, it's going to break anything that's already forking as it may eat wait messages. it's been a while since i looked at this, but i think parallel dialing re= quires a bit more of a rethink of the dialing code than just hacking in a fork. w= ithout restructuring the system, i think one would be forced into a dial device = so that any forking/threading could escape the current running environment. the original problem this code was trying to solve was the fact that many= connections can't do ip6, and dialing ip6 slows down the connection quite a bit. this problem is a little easier to fix. cs needs to do a little more wor= k to filter out impossible connection types. for example, if one's internet connection i= s not ip6 capable, then cs should be instructed to not return ip6 addresses. - erik