Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!hellgate.utah.edu!dog.ee.lbl.gov!elf.ee.lbl.gov!torek
From: torek@elf.ee.lbl.gov (Chris Torek)
Newsgroups: comp.unix.questions
Subject: Re: talk help: Ultrix 2.0 <-> SunOS 4.1
Message-ID: <10789@dog.ee.lbl.gov>
Date: 10 Mar 91 10:44:48 GMT
References: <38998@netnews.upenn.edu>
Reply-To: torek@elf.ee.lbl.gov (Chris Torek)
Distribution: na
Organization: Lawrence Berkeley Laboratory, Berkeley
Lines: 26
X-Local-Date: Sun, 10 Mar 91 02:44:49 PST

In article <38998@netnews.upenn.edu> barkdoll@cattell.psych.upenn.edu
(Edwin Barkdoll) writes:
>	I received the following message after being told of a talk
>request and responding 'otalk [address]':
>
>[Unable to connect with initiator : Address family not supported by
>protocol family (47)]

This occurs because the talk source is horribly broken.  It would have
nothing to do with the protocol, except that the main reason talk is
horribly broken is that the protocol the original author chose lends
itself well to horribly broken source.

Error 47, EAFNOSUPPORT, comes about when one makes a connect() system
call on a TCP socket but passes a sockaddr_in structure in which
sin->sin_family != AF_INET.  Talk (otalk) does this because it takes
whatever its peer sends it and uses it `as is'.  If the bytes do not
match up (and they rarely do), the resulting sockaddr_in is bogus.

The new protocol is better, but the whole approach remains a botch.
Inter-machine communication of this sort should have been done using
TCP in the first place.  (Among other things, this would remove a
whole bunch of code from `talk' itself.)
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab EE div (+1 415 486 5427)
Berkeley, CA		Domain:	torek@ee.lbl.gov