towfiq@interlan.Interlan.COM (Mark Towfigh) (07/03/90)
Note the followup group is comp.protocols.tcp-ip, as I don't read comp.unix.questions. In article <1990Jul3.040115.12000@hayes.fai.alaska.edu> wisner@hayes.fai.alaska.edu (Bill Wisner) writes: There is no RFC for talk. I know this is true -- it's a problem because there are incompatible versions of TALK out there. Specifically, it seems there was a change between the 4.2BSD talk/talkd and the one in 4.3BSD. I have a few questions: does the current TALK daemon support both the old and new versions? And what about the client? As far as I can make out, the new talkd can tell the difference between the two protocols, and when a remote user requests a connection, the local TALK daemon figures out whether they are TALKing 4.2-style or 4.3-style, and then tells the local user to run one of two programs, either /usr/ucb/talk or /usr/old/talk. All this aside, I have never seen this work with the 4.2 TALK, only the 4.3 flavor. Is there anyone out there running a system which can talk in both styles, and deal with incoming and outgoing TALK requests? -- Mark Towfigh, Racal InterLan, Inc. towfiq@interlan.Interlan.COM W: (508) 263-9929 H: (617) 488-2818 uunet!interlan!towfiq "The Earth is but One Country, and Mankind its Citizens" -- Baha'u'llah
jik@athena.mit.edu (Jonathan I. Kamens) (07/04/90)
In article <TOWFIQ.90Jul3095602@interlan.Interlan.COM>, towfiq@interlan.Interlan.COM (Mark Towfigh) writes: |> I know this is true -- it's a problem because there are incompatible |> versions of TALK out there. Specifically, it seems there was a change |> between the 4.2BSD talk/talkd and the one in 4.3BSD. I have a few |> questions: does the current TALK daemon support both the old and new |> versions? No. You have to run two different versions of talkd, one on the port reserved for the old talk protocol, and one on the port reserved for the new talk protocol. On our system, old talk is 517 (with the service name "talk"), and new talk is 518 (with the service name "ntalk"). If you don't have the right daemons running on the right ports, then talk clients are going to have trouble conversing with your machine. |> And what about the client? Nope, the old talk client knows how to talk only to the old talk port, and the new talk client knows how to talk only to the new talk port. Or, at least, that's how things *should* work, but alas, we live in an imperfect world.... |> As far as I can make out, the |> new talkd can tell the difference between the two protocols, and when |> a remote user requests a connection, the local TALK daemon figures out |> whether they are TALKing 4.2-style or 4.3-style, and then tells the |> local user to run one of two programs, either /usr/ucb/talk or |> /usr/old/talk. No, this isn't how it works, or at least not how it appears to be set up in 4.3BSD. There are two different talkd programs (/etc/talkd and /etc/ntalkd is what we've got them named, but I don't know how universal that is). The hard-coded client name in the old talk daemon is /usr/ucb/talk.old or /usr/old/talk, and the hard-coded client name in the new talk daemon is /usr/ucb/talk. The new talk daemon and the old talk daemon don't know about each other, and don't know about each other's protocols. Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8495 Home: 617-782-0710
brian@ucsd.Edu (Brian Kantor) (07/04/90)
There are two talk programs using two different protocols; the older one still found on Suns and such is architecture and compiler dependent and often won't work across heterogeneous hosts. The newer talk will work in such an environment but not everyone has it. Since it's part of the great Berkeley giveaway, you should get the newer talk and install it. It can coexist with the older talk because it lives on a different port and has a different name. 4.3-Tahoe-BSD comes with both. - Brian
emv@math.lsa.umich.edu (Edward Vielmetti) (07/04/90)
a word as to actual usage of these two talks across the nsfnet backbone -- in the months where port-by-port statistics are kept on nis.nsf.net (the *PORTS files) talk+ntalk (517+518) is in about the 0.2% - 0.3% range, with the amounts varying quite substantially and talk generally having more traffic than ntalk. Must be lots of suns, I guess. --Ed Edward Vielmetti, U of Michigan math dept <emv@math.lsa.umich.edu> comp.archives moderator
QOP@CORNELLA.BITNET (Caleb Strockbine) (07/05/90)
Steve- I've got one version of talk running already... the daemon doesn't run all the time (some daemon, eh?) but instead it's called by the "master internet daemon" called inetd, which also calls a bunch of the other communication daemons, but only when they're necessary. As far as I know, we don't have ntalk, which seems to be the newer version of talk, so maybe I'll look for that so we'll be able to talk to anyone. I wondered about that message about Mac/Unix connectivity, and whether that wasn't the same thing we're trying to do. Maybe I'm beginning to get the hang of this! -Caleb.
imp@dancer.Solbourne.COM (Warner Losh) (07/05/90)
In article <EMV.90Jul3171720@urania.math.lsa.umich.edu> emv@math.lsa.umich.edu (Edward Vielmetti) writes: >a word as to actual usage of these two talks across the nsfnet >backbone -- in the months where port-by-port statistics are kept on >nis.nsf.net (the *PORTS files) talk+ntalk (517+518) is in about the >0.2% - 0.3% range, with the amounts varying quite substantially and >talk generally having more traffic than ntalk. Must be >lots of suns, I guess. FYI, the talk/ntalk protocol is just used for connection setup. Once people agree to talk, both protocols contain "pointers" to TCP ports to carry the actual conversation on. In fact, these "pointers" are what caused the inability for "talk" to function in a heterogeneous environment (without all kinds of heuristic gyrations, that is). -- Warner Losh imp@Solbourne.COM