Date: Mon, 7 Aug 1995 08:00:35 +0200 (MET DST) From: J Wunsch <j@uriah.heep.sax.de> To: freebsd-current@FreeBSD.org Subject: Re: workaround for talk's address problem Message-ID: <199508070600.IAA01971@uriah.heep.sax.de> In-Reply-To: <199508070036.RAA04944@gndrsh.aac.dev.com> from "Rodney W. Grimes" at Aug 6, 95 05:36:55 pm
next in thread | previous in thread | raw e-mail | index | archive | help
As Rodney W. Grimes wrote: > > The correct fix here is to do what ftp, telnet or any other TCP cleint > does, go to the next address if an error or timout occurs on the current > address. When we get to the end of the list of addresses, then exit > the program with an error. > > Adding options to force a negotiation address is not going to make > the users happy, but the above surely well. But the timeouts will be enormous, i don't believe this would make people happy either. :-( Remember, talk is using UDP, you cannot see if a ``connection'' has been established unless somebody has been answering. Perhaps you could ``multicast'' the requests with all known addresses and see where you got a response, but... I think most people here didn't really understand talk's special problem: the talk protocol uses a caller-provided addresses to respond to, even though the callee should better use the address as he's got it out of the IP header. My suggested change does only affect this address. Casting connection requests with various addresses around is IMO not a Good Thing. It will cause bogus (internal) addresses to be spread around that should never see the outside world (like 192.168.x.x in my example). I think the major problem is in the talk protocol and its actual implementation, but this doesn't help us very much since we cannot convert every talk daemon on the world. FWIW, the ytalk package does provide a very similar scenario (even though i didn't understand its usage yet :). -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199508070600.IAA01971>