dws@cseg.uucp (David W. Summers) (12/21/88)
Hello NetLanders, We have a 'talk' command on our Harris HCX-7 computer that allows inter- computer 'talk' to take place. We are a binary site and also have a local area EtherNet network with a growing contingent of miscellaneous computers. Recently I 'FTP'ed the 'talk' command and the 'talkd' daemon source code from uunet.uu.net. Then, to my horror (1/2 :-) I found that the CTL_MSG structure defined in <protocols/talkd.h> was different for the Berkeley version and the Harris version that I found by talking to Harris. This means that the Harris version and the Berkeley version do NOT get along at all and completely ignore each other. To make matters worse, we have a HP 835 (I believe) and I haven't finished testing it yet but it may be different from one or both of the above versions! 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. My only solution at the moment seems to be to heavily hack the code to work for both Harris and Berkeley versions.....Hopefuly the HP will conform to one of those. As usual, any ideas, suggestions, pointers, or other help would be very much appreciated. Thanks in advance! - David Summers (dws@cseg.uucp)
barmar@think.COM (Barry Margolin) (12/21/88)
In article <1468@cseg.uucp> dws@cseg.uucp (David W. Summers) writes: > 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. You think it's weird that the Berkeley and Harris versions of talk are incompatible? The SunOS 3.5 and SunOS 4.0 versions won't work with each other (leading to problems in our network where we are incrementally converting workstations to 4.0)! Regarding RFC's, the DDN only standardizes the use of ports from 1 to 255. Any port number greater than 255 is not under the control of a DDN standard. Barry Margolin Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
jin@hplabsz.HPL.HP.COM (Tai Jin) (12/21/88)
Re: talk protocol There are two versions of the BSD talk protocol which are incompatible with each other. The 4.2BSD version uses the "talk 517/udp" services entry and the 4.3BSD version uses the "ntalk 518/udp" services entry. The one provided on the HP is most likely the 4.2BSD version. I would suggest that you get the 4.3BSD version and port that to all of your systems. ...tai
eckert@faui10.UUCP (Toerless Eckert) (12/21/88)
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 ?
guy@auspex.UUCP (Guy Harris) (12/22/88)
Hoo boy, have *you* opened a can of worms.... > My main question is: Is there a standard yet for this 'talk' > protocol? Not unless you count the code.... >If so, where could I find it? In the code. >If not, then why not, Beats me. Probably either 1) they were too lazy to write it down 2) they thought it was too err, umm, *specialized* to deserve a protocol spec 3) they didn't think it was finished yet or some linear combination of the above. >and what would it take to produce one? At minimum, a copy of the 4.3BSD version - which is different from the 4.2BSD version, and even uses a different port number (518 rather than 517), and which makes at least more of an attempt to be machine-independent. At most, some more work to fix it up to be machine-independent.... >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. "Everybody" who got a BSD source license and ported it, and "everybody" who got somebody else to do same (compute "transitive closure", if you will) knows about it. It's not an official Internet protocol, though, any more than say "rlogin" is. CCI got a BSD source license and ported it; that's why Harris has it. > My only solution at the moment seems to be to heavily hack the code to work >for both Harris and Berkeley versions..... Since you say "talk" and "517", rather than "ntalk" and "518", I assume the one on the Harris is the 4.2BSD version. The author of this version seemed not to be aware, or seemed to have forgotten, that not all machines have the same byte order as a VAX. One such machine is the HCX-7; it has the same byte order as a 68000, which is the opposite byte order to that of the VAX. This means that "talk" packets sent out by the VAX are gibberish to the HCX-7, and *vice versa*. The "ntalk" version puts the data into a standard byte order before sending it out on the wire. Unfortunately, it still sends C structures over the wire directly; fortunately, the structure *appears* to be laid out so that the alignment and padding will be the same on most C implementations where "short" is 2 bytes and "long" is 4 bytes. If you FTPed the "talk" daemon from the "AT&T-free BSD stuff" on "uunet", it's probably the 4.3BSD version. As such, it stands at least a fighting chance of, if successfully made to work on the HP and the HCX-7, working compatibly on both those machines, as well as many other machines on your network. First, check whether either the HP or the Harris have an entry of the form ntalk 518/udp in "/etc/services". If they do, they probably have the 4.3BSD version, which I suspect might work between at least some set of different machines. If not, try to make the 4.3BSD version work on them, and if you can do so, replace the native version with it. (The 4.3BSD version may depend on some 4.3BSD-isms that may not be present on the HP or the Harris; you may have to tweak the code a bit for that.) If *that* doesn't work, the stuff pushed out on the wire may, in fact, still be different; time to start digging and debugging.
andrew@stl.stc.co.uk (Andrew Macpherson) (01/07/89)
In article <786@faui10.informatik.uni-erlangen.de> eckert@faui10.UUCP (Toerless Eckert) writes: | 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 ? Look out for "Phone" which has a nicer user interface, and gets round your complaints. let's see: Ah yes, written by: J. Broome UCB 1985. I think I got it from the news network, but there must be somewhere nearer you to get it. -- Andrew Macpherson PSI%234237100122::andrew andrew@stl.stc.co.uk - or - ...!mcvax!ukc!stl!andrew "It is always a great mistake to treat the individual on the chance that he may become a crowd" -- Mr Justice Codd: (A.P.Herbert)
yee@ames.arc.nasa.gov (Peter E. Yee) (01/08/89)
In article <924@acer.stl.stc.co.uk> "Andrew Macpherson" <andrew@stl.stc.co.uk> writes: >In article <786@faui10.informatik.uni-erlangen.de> eckert@faui10.UUCP (Toerless Eckert) writes: >| ... Does someone on this lists knows if there is a suitable replacement for >| talk, that does not suffer from the above mentioned problems ? > >Look out for "Phone" which has a nicer user interface, and gets round your >complaints. let's see: I have the sources to phone (obtained from Jonathan back whenever). If there is enough interest, I could make them available for anonymous ftp or mail them to some people (if the number of interested folks is few). If it came out in 1985, and was posted to the net, it's probably in an archive somewhere, but I never can seem to find archives for mod and comp.sources. -Peter Yee yee@ames.arc.nasa.gov ames!yee
wisner@killer.DALLAS.TX.US (Bill Wisner) (01/10/89)
The sources to phone are already available for anonymous FTP. I put them up on EDDIE.MIT.EDU earlier this year. I think they're /pub/phone.tar.Z or something similar.
hanst@htsa.uucp (Hans Trompert) (01/10/89)
In article <20431@ames.arc.nasa.gov> yee@ames.arc.nasa.gov.UUCP (Peter E. Yee) writes: >I have the sources to phone (obtained from Jonathan back whenever). If there >is enough interest, I could make them available for anonymous ftp or mail them >to some people (if the number of interested folks is few). If it came out >in 1985, and was posted to the net, it's probably in an archive somewhere, >but I never can seem to find archives for mod and comp.sources. We sure are interested, and I think many others are interested as well. But we have no access to anonymous ftp, so why dont you post it on the net if many people are interested. -- Hans Trompert Algemene Hogeschool Amsterdam Technische en Maritieme Faculteit hanst@htsa.uucp.nl