woerz@iaoobelix.UUCP (01/07/87)
We got some new Suns and some uVAXes here at our institute. Lately
someone tried to talk to a uVAX from a Sun and his partner got the
message:
Address family not supported by protocol family
on the uVAX. When we tried it the other way round, that is the talk
was initiated by the uVAX all worked well. I think, this may be due to
a different byte ordering between Sun and uVAX, which is handled by
the Sun, but not by the uVAX.
If I'm right and someone has already solved this problem, can you
please drop me a mail.
Thanks in advance
------------------------------------------------------------------------------
Dieter Woerz
Fraunhofer Institut fuer Arbeitswirtschaft und Organisation
Abt. 453
Holzgartenstrasse 17
D-7000 Stuttgart 1
W-Germany
BITNET: ...unido.bitnet!iaoobel.uucp!woerz
UUCP: ...seismo!unido!iaoobel!woerzfair@ucbarpa.Berkeley.EDU (Erik E. Fair) (01/08/87)
Sadly, the pinhead who wrote talk originally did not know that there is such a thing as "network byte order" in ARPA Internet land, and the talk program passes binary C structures around in packets to itself. Unfortunately, this means that a) you can only speak "talk" protocol to a machine with the same byte order as the one you're on or b) we all agree to speak "talk" protocol in VAX byte order which is different from just about everybody, and modify the talk program on non-VAXen... "talk" as distributed with 4.2 BSD UNIX is a badly written program. I am given to understand that the new version which is distributed with 4.3 BSD UNIX is much better behaved (and among other things, it is also backward compatible). Erik E. Fair ucbvax!fair fair@ucbarpa.berkeley.edu
forys@boulder.UUCP (Jeff Forys) (01/10/87)
In article <16784@ucbvax.BERKELEY.EDU> Erik E. Fair writes: > "talk" as distributed with 4.2 BSD UNIX is a badly written program. I dont know, certainly by todays standards it's poorly written, but it was probably the first of its kind and it did work pretty well in an all-vax environment... > I am given to understand that the new version which is distributed with > 4.3 BSD UNIX is much better behaved (and among other things, it is also > backward compatible). True, 4.3final `talk' finally speaks in network byte order, but it's not backward compatible -- in fact, it even uses a different port. It just *looks* backward compatible because the old talk daemon (well, actually inetd) hangs out on the old port (517) but tells you to respond using `/usr/old/talk' (same old 4.2 talk speaking VAX-ese). The new talkd sits on a different port (518), and says to use `talk' when responding. Of course, all this is hidden from the user and everything looks compatible. Clever idea. In my opinion, this *had* to be done... everyone remember hacking 4.2 talk (oh yeah, with that UDP checksum fix) to speak in a mixed machine environment. Whew! --- Jeff Forys @ UC/Boulder Engineering Research Comp Cntr (303-492-6096) Forys@Boulder.Colorado.Edu -or- ..!{hao|nbires}!boulder!forys
brian@sdcsvax.UCSD.EDU (Brian Kantor) (01/10/87)
Lo these many years ago, I got a set of patches from jsq@ut-sally to fix up talk. Another set were distributed by muller@ucsd. Talk uses binary transmission of a complicated C structure in its attempt to establish the connection. Thus you run into problems of byte order between VAXen and Suns. And to top it off, even if you don't have byte ordering problems (say, between a Pyramid and a Sun), you still have packing problems - the structure contains chars, shorts, and ints, and on different machines, word alignment constraints cause the compilers to pack the structure differently. This program should shoot itself and be replaced. One of these days... Brian Kantor UCSD Office of Academic Computing Academic Network Operations Group UCSD B-028, La Jolla, CA 92093 USA
roy@phri.UUCP (Roy Smith) (01/12/87)
In article <300@boulder.UUCP> forys@boulder.UUCP (Jeff Forys) writes: > I dont know, certainly by todays standards [4.2 talk is] poorly written, > but it was probably the first of its kind [...] I vaugely remember there being a talk-like facility on a TOPS-10 system I used back around 1976. It wasn't screen oriented, but it had the ability to have multi-way conversations with each person's contributions being copied to all the other terminals involved (there could be more than just 2), preceeded by the name of the person "talking". I don't remember for sure, but I think it was line-by-line buffered. Does anybody remember more about this? -- Roy Smith, {allegra,cmcl2,philabs}!phri!roy System Administrator, Public Health Research Institute 455 First Avenue, New York, NY 10016 "you can't spell deoxyribonucleic without unix!"
ron@brl-sem.ARPA (Ron Natalie <ron>) (01/14/87)
In article <300@boulder.UUCP>, forys@boulder.UUCP (Jeff Forys) writes: > I dont know, certainly by todays standards it's poorly written, but > it was probably the first of its kind and it did work pretty well in > an all-vax environment... I'm going to forstall a bunch of discussion on this as the statement about TALK being the first of it's kind as being outright wrong. Many systems had slick screen oriented and non-screen oriented talk to other users programs. ITS has at least three nice ways of doing it and of course you can always get nasty. TOPS-20 has at least two. UNIVAC's, DEC-10's, and IBM's all have at least a minimal procedure for this. UNIX had "write" before "talk" VMS phone is probably what the author of talk was thinking about when he wrote it. ...
grunwald@uiucdcsb.cs.uiuc.edu (01/14/87)
The PLATO educational computer system has had a talk-like facility for many years (mid-70's?). There were two incantations: one was called term-talk, which enabled a two-line conversation at the bottom of the screen without interrupting the current program (PLATO didn't have job-control or anything concept of it). The other program was called Talk-O-Matic, and it had "channels" where up to five people could hold a conversation with people entering & leaving in the middle. You could "lock" a channel, not letting anyone else in. Since PLATO had terminals spread around the country & the world, people found it interesting to sit in a channel & just talk to whoever came along. I think you could taga channel with a ``topic'' header as well, but it's been a while since I used Talk-O-Matic.
paul@osu-eddie.UUCP (Paul Placeway) (01/15/87)
In article <2555@phri.UUCP> roy@phri.UUCP (Roy Smith) writes: > I vaugely remember there being a talk-like facility on a TOPS-10 >system I used back around 1976. It wasn't screen oriented, but it had the >ability to have multi-way conversations with each person's contributions >being copied to all the other terminals involved (there could be more than >just 2), preceeded by the name of the person "talking". I don't remember >for sure, but I think it was line-by-line buffered. Does anybody remember >more about this? >Roy Smith, {allegra,cmcl2,philabs}!phri!roy Under Tops-20, there is even a better way. When you talk with someone, everything that is sent to your terminal (including the input echo) is also sent to everyone else who is in on the conversation. You just make a connection, and do stuff, and then break the connection when your done. It makes demonstrating commands very easy. There is, also a way to send your input to _thier_ job (read input queue), and a way to observe (spy) someone without letting them know that you are watching. These are, of course, privileged programs... --P
forys@boulder.UUCP (Jeff Forys) (01/17/87)
In article <576@brl-sem.ARPA> ron@brl-sem.ARPA (Ron Natalie <ron>) writes: >In article <300@boulder.UUCP>, forys@boulder.UUCP (Jeff Forys) writes: >> I dont know, certainly by todays standards it's poorly written, but >> it was probably the first of its kind and it did work pretty well in >> an all-vax environment... > >I'm going to forstall a bunch of discussion on this as the statement >about TALK being the first of it's kind as being outright wrong. Yikes! I never meant to imply that `talk' was the first "communication program ever written" -- I am not *that* naive! Hindsight informs me that I should have wrote "`talk' was probably the first network communications program written under 4BSD". Since the origional poster spoke of byte swap problems between BSD & SUN machines, I didnt think my statement would cause readers to traverse back to the epoch! --- Jeff Forys @ UC/Boulder Engineering Research Comp Cntr (303-492-6096) Forys@Boulder.Colorado.Edu -or- ..!{hao|nbires}!boulder!forys
mark@markshome.UUCP (01/18/87)
In article <2908@osu-eddie.UUCP> paul@osu-eddie.UUCP (Paul Placeway) writes: >Under Tops-20, there is even a better way. When you talk with someone, >everything that is sent to your terminal (including the input echo) is also >sent to everyone else who is in on the conversation. You just make a >connection, and do stuff, and then break the connection when your done. >It makes demonstrating commands very easy. Although not predating anything, the Maryland window system 'swsh' shell has a cloned-window feature done by Steve Miller. Anyone else on the network can get a clone of any of your windows, and then any input or output to that window happens to all its clones. Clones can be nested to any depth (the 'swsh' can run in itself, so it really is possible to run a swsh inside a swsh window, etc. with clones around here and there). Because the window system is responsible for virtual emulation of a vt100'sh type display in each window, screen-oriented programs (such as vi or emacs or rogue) can be shared over the network regardless of the terminal-types of any user. (I imagine this is not true for Tops-20 talk.) For security, you are notified via a popup if someone wanted to clone one of your windows, and you could refuse the clone. We don't use swsh any more since we all got suns, but it was nice while it lasted. -mark Spoken: Mark Weiser ARPA: mark@maryland Phone: +1-301-454-7817 CSNet: mark@umcp-cs UUCP: {seismo,allegra}!umcp-cs!mark USPS: Computer Science Dept., University of Maryland, College Park, MD 20742