szeto@aludra.usc.edu (Johnny Szeto) (09/20/90)
I have an interesting conversation with one of my friends in Canada. BTW, we were conversing over the 'talk' command on unix. But somehow I think there are some problems associated with the process. i) sometimes I got the mesg "target machine cannot be recognised" ii)other times, I got "addr has already been in use (48)" iii)last time it was even so frustrating: I was trying to connect with him while he was doing the same thing at the same time. I have got his talk-initiation mesg on my screen while my machine was pinging him! My questions are: why do these kinds of things happen? is there any documentation in RFC that a simple description of the algorithm can be found? I have had success sometimes but I had to request so many times before connection could be established. Thanks in advance. Truly, Leung
emv@math.lsa.umich.edu (Edward Vielmetti) (09/20/90)
In article <12052@chaph.usc.edu> szeto@aludra.usc.edu (Johnny Szeto) writes:
I have an interesting conversation with one of my friends in Canada.
BTW, we were conversing over the 'talk' command on unix. But somehow
I think there are some problems associated with the process.
Sounds like you need to get and install the "4.3" version of talk, also
known as "ntalkd", on one or both of the systems. It is available from
uunet.uu.net in the /bsd-sources directory.
My questions are:
why do these kinds of things happen?
Byte ordering problems are the culprit here. The protocol for in.talkd
on 4.2-based systems is architecture dependent and cannot be relied to
work between machines of different vendors.
--Ed
Edward Vielmetti, U of Michigan math dept <emv@math.lsa.umich.edu>
moderator, comp.archivesmikep@dirty.csc.ti.com (Michael A. Petonic) (09/20/90)
In article <EMV.90Sep19221142@picasso.math.lsa.umich.edu> emv@math.lsa.umich.edu (Edward Vielmetti) writes: > [ On why 4.2 BSD talk(1) is broken between machines. ] > My questions are: > why do these kinds of things happen? > >Byte ordering problems are the culprit here. The protocol for in.talkd >on 4.2-based systems is architecture dependent and cannot be relied to >work between machines of different vendors. See. You wouldn't have those problems with OSI.... :-) -MikeP
wls@uwm.edu (Bill Stapleton) (09/20/90)
> In article <12052@chaph.usc.edu> szeto@aludra.usc.edu (Johnny Szeto) writes: > > I have an interesting conversation with one of my friends in Canada. > BTW, we were conversing over the 'talk' command on unix. But somehow > I think there are some problems associated with the process. You're right about the problems. You're probably better off just using mail. In article <EMV.90Sep19221142@picasso.math.lsa.umich.edu>, emv@math.lsa.umich.edu (Edward Vielmetti) writes: > Sounds like you need to get and install the "4.3" version of talk, also > known as "ntalkd", on one or both of the systems. It is available from > uunet.uu.net in the /bsd-sources directory. > > Byte ordering problems are the culprit here. The protocol for in.talkd > on 4.2-based systems is architecture dependent and cannot be relied to > work between machines of different vendors. [By the way, just to state it explicitly, "4.2" and "4.3" talks are not compatible - You need the same version at both ends.] I don't think that's the case in this instance, since he indicates that it works OK sometimes. I think it's probably talk's use of the Unreliable Data Protocol (;-) that's at fault. Over a distance, there's just too many places for packets to get lost, with no checks or guarantees. Canada?? :-) -- Bill Stapleton wls@csd4.csd.uwm.edu uwmcsd4!wls
huopio@lut.fi (Kauto Huopio OH5LFM) (09/21/90)
In article <6461@uwm.edu> wls@uwm.edu (Bill Stapleton) writes: > I don't think that's the case in this instance, since he indicates that it > works OK sometimes. I think it's probably talk's use of the Unreliable Data > Protocol (;-) that's at fault. Over a distance, there's just too many > places for packets to get lost, with no checks or guarantees. Canada?? :-) Well, I've done many talks across the pond, with no significant problems. Anyway, a NEW talk protocol _standard_ might be an idea worth considering.. --Kauto -- ****************** Kauto Huopio (huopio@kannel.lut.fi) ********************** *US Mail: Kauto Huopio, Punkkerikatu 1 A 10, SF-53850 Lappeenranta, Finland * *****************************************************************************