barkdoll@cattell.psych.upenn.edu (Edwin Barkdoll) (03/10/91)
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)] I'm on a machine running Ultrix 2.0 the other person was on SunOS 4.1. I noticed that the Ultrix man page for talk mentions: 'The version of talk released with ULTRIX V2.0 uses a proto- col that is incompatible with the protocol used in earlier versions.' What does that imply about incompatibility between different operating system protocols? Might this be the reason for the inability to talk b/w the machines? Thanks Edwin Barkdoll | "You are in a maze of twisty barkdoll@cattell.psych.upenn.edu | little passages, all alike..." Edwin Barkdoll | "You are in a maze of twisty barkdoll@cattell.psych.upenn.edu | little passages, all alike..."
torek@elf.ee.lbl.gov (Chris Torek) (03/10/91)
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