dbd%benden@lanl.gov (Dan Davison) (05/11/89)
The reason for the incompatible talk programs is that 3.x systems use the 4.2 talkd and 4.x uses the 4.3 BSD talkd. The incompatibilities are documented in the 4.3 System Manager's guide, I think. I have confirmed this "talk"ing with some friends at Harvard and Berserkley from 3.5 and 4.0 systems. If they run 4.2 BSD I can "talk" with them from 3.5 but not 4.0, and if they are running 4.3 BSD I can "talk with them on a 4.0 system but not from a 3.5 system. After I noticed that I went and read the Berserkely docs and found the note. If you need chapter and verse on this let me know and I will look thru the docs again. I pretty sure it wasn't on the man page, though. dan davison theoretical biology and biophysics t-10 ms k710 los alamos national laboratory los alamos, nm 87545 USA dd@lanl.gov 505-665-1355
guy@uunet.uu.net (Guy Harris) (05/12/89)
>The reason for the incompatible talk programs is that 3.x systems use the >4.2 talkd and 4.x uses the 4.3 BSD talkd. Uhh, no, it doesn't: Script started on Fri May 12 00:58:57 1989 auspex% cat /etc/motd SunOS Release 4.0 (AUSPEX) #1: Tue Apr 11 07:08:26 PDT 1989 auspex% egrep talk /home/unix_src/bsd4.3/sys/dist/services talk 517/udp ntalk 518/udp auspex% egrep talk /etc/services talk 517/udp auspex% egrep talk /home/unix_src/bsd4.3/sys/dist/inetd.conf talk dgram udp wait root /etc/talkd talkd ntalk dgram udp wait root /etc/ntalkd ntalkd auspex% egrep talk /etc/inetd.conf talk dgram udp wait root /usr/etc/in.talkd in.talkd auspex% script done on Fri May 12 00:59:11 1989 (Besides, I know for certain nobody put the 4.3BSD "talk" into SunOS 4.0 - I was there....) No SunOS release has picked up the 4.3 "talk" as of yet; they have, however, hacked the old "talk" up to try to make it work right between hosts with different byte orders (VAX and 68K, at least) and later, in 4.0, between hosts with different data alignments (68K and SPARC, at least). The 4.3 "talk" stuff was changed to 1) put things in network order before shoving them out on the wire and 2) set up the structures so that, with any luck, they'll have the same layout regardless of the alignment rules on your compiler. This makes them incompatible with the old "talk", so Berkeley changed the port number from 517 to 518. Unfortunately, the new version doesn't check whether there's a new version on the remote machine (it might be able to do this by detecting the error that an ICMP Port Unreachable generates - ECONNREFUSED, I think - by "connecting" to the remote host) and fall back on the old protocol; instead, I guess you're stuck with running "/usr/old/talk" if "talk" by itself doesn't work. >I have confirmed this "talk"ing with some friends at Harvard and >Berserkley from 3.5 and 4.0 systems. If they run 4.2 BSD I can "talk" >with them from 3.5 but not 4.0, and if they are running 4.3 BSD I can >"talk with them on a 4.0 system but not from a 3.5 system. After I >noticed that I went and read the Berserkely docs and found the note. 4.3BSD runs both an "old" and "new" talk daemon, by default; presumably, when you "talk" to a 4.3BSD system it contacts the old one. SunOS [34].x, as it comes from Sun, isn't going to try to talk to the new one.... If your friends aren't running "/usr/old/talk" to talk to you, then either your SunOS system or their BSD system has been hacked. As for the differences between the two, the only thing I can think of is that there's some difference between the 4.2BSD "talk" and the 4.3BSD "old talk" that affects interoperatibility with different flavors of Sun's "talk".
fkuhl@amadeus.mitre.org (F. S. Kuhl) (05/12/89)
dbd%benden@lanl.gov (Dan Davison) writes:
The reason for the incompatible talk programs is that 3.x systems use the
4.2 talkd and 4.x uses the 4.3 BSD talkd. The incompatibilities are
documented in the 4.3 System Manager's guide, I think.
I'm inclined to think there's more to it. When a colleague running 4.0.1
on a 386i talks at me (a 3/150 running 4.0.1) my attempts to respond abort
immediately. After he gives up I can initiate with him & he can respond
without difficulty.
--Frederick Kuhl, fkuhl@mitre.org