Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!ucsd!helios.ee.lbl.gov!nosc!crash!simpact!jeh From: jeh@simpact.com Newsgroups: comp.mail.uucp Subject: Re: RR0 on initial packet Message-ID: <795.2595f33f@simpact.com> Date: 25 Dec 89 17:15:27 GMT References: <1989Dec24.080341.11406@polyslo.CalPoly.EDU> Organization: Simpact Associates, San Diego CA Lines: 90 In article <1989Dec24.080341.11406@polyslo.CalPoly.EDU>, cambler@polyslo.CalPoly.EDU (Fubar) writes: > I am still getting RR0 on my initial packet. I retransmit the command > string as sequence 1 each time, and get RJ0 after each. > > Let me ask another question: > > What is the proper flow for commands? Here is how i see it, let me know > if i'm wrong. > > master sends packet, as 1 (this is the first thing), containing > "S [da da da da da da da da] 0666" and a bunch of nulls to fill it out > to the window size, in my case, 64 bytes. > > The slave will respond with RR 1. (this is where i get my RR0, but let's > imagine that this is the "perfect world."). > > The slave will THEN send > "SY" > > and then the transfer begins and everyone is happy... > > Did i overlook something?! > No, this looks right to me (subject to the comments below). All of this happens after the Shere/Smastername/Pprotos/Uproto/INITx sequence... but if you're getting a valid RR0, you've already gotten through all of that (successfully!). Comment: I think we have mentioned this before, but it's important to note that the RR 1 (which in my code I insist on calling an ACK 1, but never mind) is NOT a response to the S command... it's a response to Data message 1, which in this case just happens to be an S command. Keep the layers separate, both in your mind and in your code, and most especially in your data structures. Comment2: Some uucps will NOT send an explicit RR 1, but will instead use uucp's "imbedded ACK" capability. You'll get a data message containing an SY (or maybe an SN) with a 1 in the y field of the header. This implies "RR 1" and in fact should be treated in the code as such. In fact, every time you get a data packet, you should behave as if you also got an RR y, where y is the value of the packet's y field. Most of the Unix uucp's I've watched will emit RR periodically when "idling". And they're real shy about sending RJs (NAKs). If they get a packet and the checksum doesn't check they might just send RRs for the previous good packet, letting you timeout awaiting RRs and resend the whole window (ugh). Otoh the correct response to a header framing error (XOR failure, bogus stuff in the header, corrupted ctl-P), etc., is NEVER to send an RJ (you might send an RR for the previous packet, as that is always harmless, and in fact you have to be ready to receive "redundant" RRs); a bad header means you can't trust anything in the header, including the ctl-P, so what you got might not have been a header at all. So when you get a bad header, you just rescan the input looking for a header "later on", and ignore the noise. Conclusion: Either the checksum is failing or the header is corrupt at the receiving end. It's impossible to say which. Of course, something else might be going wrong too. Now, I have a question for the uucp gurus out there... Clearly the ctl-P, header XORs, packet checksums, and so on, are the g protocol's "data link layer". But, are the S commands, etc., considered part of g protocol? Obviously they're an upper layer, which I suppose could be labelled transport, or maybe even application... but are they specific to g? I ask because the routines that handle this stuff are packaged with the g data link layer in the only source I've looked at thoroughly (gnuucp). This implies that they're specific to g, and therefore that "g protocol" encompasses more than the data link layer. But, in the p-d f protocol which has been distributed on the net, which provides analogous routines, the same S, R, etc. commands are sent and received as in g. They're just sent and received in different ways. My suspicion is that g, f, etc., ONLY define the data link, and that the packaging of the routines merely reflects the fact that the way you hand an S command (or a part of a file) to the data link layer is specific to the data link layer... so the routines to send a message, send a file, etc., might as well be packaged with those that implement the data link layer (esp. since no one outside of the g proto module, or the f proto module, ever hands stuff to the data link layer directly). But I'd appreciate confirmation from the experts. --- Jamie Hanrahan, Simpact Associates, San Diego CA Chair, VMSnet [DECUS uucp] and Internals Working Groups, DECUS VAX Systems SIG -------------------------------------+----------------------------------------- Internet: jeh@simpact.com, | Future shock: A sense of bewilderment or if that fails, jeh@crash.cts.com | felt by those who were not paying Uucp: ...{crash,scubed}!simpact!jeh | attention. -- Analog (Jan 90)