cambler@polyslo.CalPoly.EDU (Fubar) (12/24/89)
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?!
--
Sig: ++Christopher(); | Fubar Systems BBS
Internet: cambler@polyslo.calpoly.edu | (805) 544-9234 3/12/24 8-N-1
Also: chris@fubarsys.slo.ca.us | San Luis Obispo, California
Bix: cambler | "G Protocol Sucks" -- Me. jeh@simpact.com (12/26/89)
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<last successfully-received message, or 0 if none> 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)
greg@cheers.uucp (Greg Onufer) (01/03/90)
cambler@polyslo.CalPoly.EDU (Fubar) writes: >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. Yes, one minor detail you left out is that the message may be sent in more than one packet if it is longer than the packet size (_not_ the window size). You must read (and ACK) packets until one contains a NULL character. These together make up the message. Also, the message packet is not, I believe, guaranteed to be padded with NULLs, only one NULL at the end of the message is guaranteed. The rest of that final packet may very well be garbage. Cheers!greg
jeh@simpact.com (01/04/90)
In article <MQH&K.1288@cheers.uucp>, greg@cheers.uucp (Greg Onufer) writes: > Yes, one minor detail you left out is that the message may be sent in > more than one packet if it is longer than the packet size (_not_ the > window size). You must read (and ACK) packets until one contains a > NULL character. These together make up the message. Yup! An interesting corollary is that if you send a message that is exactly <packetsize> long you must send another packet with the required NUL. > Also, the message packet is not, I believe, guaranteed to be padded > with NULLs, only one NULL at the end of the message is guaranteed. > The rest of that final packet may very well be garbage. > > Cheers!greg From a theoretical standpoint, I agree. But when I was bringing up VMS uucp, I found at least one Unix uucp that insisted that the "messages" I send it be padded with NULs out to the end of the packet. The "safe approach", clearly, is to expect only one NUL when receiving messages, but to send as many as necessary to pad out the packet. --- 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