Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!usc!ucsd!helios.ee.lbl.gov!nosc!crash!simpact!jeh From: jeh@simpact.com Newsgroups: comp.mail.uucp Subject: Re: packet troubles Message-ID: <730.25606315@simpact.com> Date: 15 Nov 89 02:10:12 GMT References: <1989Nov7.090330.27599@polyslo.CalPoly.EDU> Organization: Simpact Associates, San Diego CA Lines: 66 In article <1989Nov7.090330.27599@polyslo.CalPoly.EDU>, cambler@polyslo.CalPoly.EDU (Fubar) writes: > ... > /* here's their response. I EXPECT a data packet with the "CY" in it, > but what i get is an xxx = 4, which is an RR 0. According to the > docs, g shouldn't acknowledge copy commands!!! It's not in ANY of > the other code i've looked at... the packets are all ok, as you > can see by the "sumok. packet received" message. */ I don't see why g shouldn't ack copy commands. In OSI terms, think of the message framing stuff (ctl-P, header XORs, checksums on packets, message numbers, RRs (acks), RJs (naks), etc., as the data link layer, and the C, S, R, H, etc., exchanges as, oh, I dunno, the application layer. The data link layer should have UTTERLY NO KNOWLEDGE of what is going on at the application layer. So an "S" message is just a data packet as far as the data link layer is concerned... and it gets ACKed like any other data packet. Now, having said that, I will mention that since uucp 'g' allows "piggybacked acks" (the number of the most recently-correctly-received packet appears in the 'y' field of outgoing data packet headers), you sometimes won't see an explicit ack for every data message. If your neighbor has a data message queued up to send to you, the ack can be implied by the y field in that message's header. Now, the only time this really has a chance to happen under uucp 'g' is during the start-of-file and end-of-file handshake stuff, and even then it doesn't occur often, since it's rare for the data link level to NOT get the explicit ACK out the door before the app. level sends the "SY" in resp. to the "S" or whatever. Also, at least one 'g' implementation (that in early Telebit ROMs; later ones have a fix) can't handle piggybacked acks in all cases, so it's best to explicitly ack everything. Piggybacked acks help performance in environments where the upper protocol layers make frequent full-duplex use of the data link... which doesn't describe uucp 'g'. In any case, the RR 0 is NOT an ack of your S command, it is a nak!!! Read on. Unix uucps are very shy about sending naks (RJs), and for good reason (sending too many naks in a windowed environment will confuse the hell out the sender). Instead they often just timeout and send a ack for the last correctly received packet, which variable is init'd to 0. Remember that your first data packet (the S packet) was packet number 1? (It better be!) You want to see an RR 1 in response. *** An RR , where n is less_than(modulo 8) the number *** of the packet you just sent, should be treated like an RJ. > a thought would be that i should ignore the RR 0 and continue, but > when i do, i then start getting funky RJ 0 and RR 0 packets alternating... Yup. You're ignoring a NAK. If you send too many unexpected packets Unix uucps will occasionally send an honest-to-God RJ. > should i ignore the RR 0 and send a null packet? SHould *I* RR the RR 0?! No, you never send ACKs for ACKs. You should find out why your neighbor system is rejecting your "S" packet. Maybe you still have some checksum calculation troubles. You appear to have some application-level troubles as well, as you shouldn't be expecting a CY after you send an S. After you send an S you should be expecting an SY or an SN. If SY you send the file, THEN you expect a CY or a CN as confirmation. --- Jamie Hanrahan, Simpact Associates, San Diego CA Chair, VMSnet [DECUS uucp] and Internals Working Groups, DECUS VAX Systems SIG Internet: jeh@simpact.com, or if that fails, jeh@crash.cts.com Uucp: ...{crash,scubed,decwrl}!simpact!jeh