On Fri May 20 21:48:40 PDT 2016, aris...@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()—it assumes things about the calling environment. for starters, 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 requires a bit more of a rethink of the dialing code than just hacking in a fork. without 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 work to filter out impossible connection types. for example, if one's internet connection is not ip6 capable, then cs should be instructed to not return ip6 addresses. - erik
