From owner-freebsd-current Mon Aug 7 00:24:13 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id AAA21792 for current-outgoing; Mon, 7 Aug 1995 00:24:13 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.cdrom.com (8.6.11/8.6.6) with SMTP id AAA21785 for ; Mon, 7 Aug 1995 00:24:09 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de with SMTP (5.67b+/DEC-Ultrix/4.3) id AA17973; Mon, 7 Aug 1995 09:23:37 +0200 Received: by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id JAA22042 for freebsd-current@FreeBSD.org; Mon, 7 Aug 1995 09:23:36 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.6.11/8.6.9) id IAA01971 for freebsd-current@FreeBSD.org; Mon, 7 Aug 1995 08:00:36 +0200 From: J Wunsch Message-Id: <199508070600.IAA01971@uriah.heep.sax.de> Subject: Re: workaround for talk's address problem To: freebsd-current@FreeBSD.org Date: Mon, 7 Aug 1995 08:00:35 +0200 (MET DST) Reply-To: freebsd-current@FreeBSD.org In-Reply-To: <199508070036.RAA04944@gndrsh.aac.dev.com> from "Rodney W. Grimes" at Aug 6, 95 05:36:55 pm Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1656 Sender: current-owner@FreeBSD.org Precedence: bulk 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. ;-)