Xref: utzoo comp.sources.wanted:5867 comp.protocols.misc:422 comp.protocols.tcp-ip:5813 comp.bugs.4bsd:1162
Path: utzoo!attcan!uunet!mcvax!unido!fauern!faui44!eckert@faui10.UUCP
From: eckert@faui10.UUCP (Toerless Eckert)
Newsgroups: comp.sources.wanted,comp.protocols.misc,comp.protocols.tcp-ip,comp.bugs.4bsd
Subject: Re: 'Talk' command and protocol
Message-ID: <786@faui10.informatik.uni-erlangen.de>
Date: 21 Dec 88 11:57:51 GMT
References: <1468@cseg.uucp>
Sender: eckert@faui44.informatik.uni-erlangen.de
Lines: 46

From article <1468@cseg.uucp>, by dws@cseg.uucp (David W. Summers):
..
>    My main question is:  Is there a standard yet for this 'talk' protocol?  If
> so, where could I find it?  If not, then why not, and what would it take to
> produce one?  What is strange is that on each of our different types of
> computers, there was a 'talk   517/udp' entry in the /etc/services file which
> led me to believe that everyone knew about it.  However, I could find NOTHING
> that even referenced it during my search of the RFC's.

I do not think that talk was ever meant to be a _standard_. From my 
experiences with it i must conclude that it is a hack. While it is really
nice in its user interface, it has severe problems with its way to
exchange data. Talk uses the above mentioned structures CTL_MSG and
CTL_RESPONSE to exchange information about the partners through the net.
Talk does not use XDR or some other means of encapsulation when sending
this C structures. This causes problems when you want to run
talk between machines of different architectures. The 4.2BSD talk code
was written to run VAXen and on SUNs, and maybe on machines with similar
architecture. When receiving a CTL_MSG packet from the net, this code
does a plausiblity check about what type of machine this packet came from.
If swapping some bytes in the packet will result in a valid
IP address, then it will swap all bytes in the packet, because the program
has concluded that the remote machine must have a byte swapped architecture.
Another problem that this version of talk cannot handle at all is
the compiler alignement of structure elements. I once tried to compile talk
on a little endian machine that had an alignement to 4 byte boundaries.
Talk choked on this, and could not talk to Suns nor VAXen, because
those machines have a different alignement policy. This is what i call a
hack.
The talk supplied with 4.3BSD tries to solve this problem by
inserting some dummy char elements into this structures. But 4.3 talk
has also changed the overall structures, so it is truely incompatible
with 4.2 talk ( they use a different port for 4.3 talk though).

I have tried talk between a couple of machines ( Suns, Vaxen, Sequent,
Apollo), and there are couple of compinations that do not work. Its not
so easy to declare which version is broken, but in general it does
not work correctly.

Many other Manufacturers (HP, PCS, CRAY, ..) were so wise to leave 
talk out of their unix ports ;-)

I have previosly posted a request for a replacement for talk, but that
was only to comp.sources.wanted. Maybe that was the wrong audience.
Does someone on this lists knows if there is a suitable replacement for
talk, that does not suffer from the above mentioned problems ?