Path: utzoo!attcan!uunet!cs.utexas.edu!uwm.edu!uwvax!umn-d-ub!umn-cs!nis!pwcs!stag!syntel!dal From: dal@syntel.mn.org (Dale Schumacher) Newsgroups: comp.mail.uucp Subject: Re: packet troubles Summary: Reality is stranger than fiction (ie: the g-proto spec) Keywords: g-proto, bugs Message-ID: <101789A8760@syntel.mn.org> Date: 17 Nov 89 16:43:20 GMT Reply-To: dal@syntel.mn.org (Dale Schumacher) Lines: 95 X-Member-Of: STdNET (ST Developer's Network) [cambler@polyslo.CalPoly.EDU (Fubar) writes...] > The troubles with G protocol continue. Here is a debug script from my > most bug-free version. It appears here unedited, comments in /* */ are > added by me as i interpret things. If this sparks any insight for any > g protocol hackers, PLEASE help!!! Having recently finished getting a 1-7 window g-proto implementation working in the face of misbehaving neighbors, I have sympathy for you. I've quoted only selections from the debugging script... > /* i'm sending the init-a, asking for a window of 3 */ > /* the remote system init-a's also, asking for a window of 7 */ > /* my init-b */ > /* their init-b. packet size req is 64. Note that my checksumming is working > just fine now... */ > /* i send my init-c. note also that these init packets are coming and > going just fine, with no problems, right? */ > /* their init-c. they still say 7. THis isn't a problem, yes? I realize > that the open is complete, i malloc my buffers, etc... everything's > ok as far as i can see... */ Seems ok. The implementation I'm working on (written by Peter Housel) is now "downshifting" it's INITC window request to the minimum of my window size and their window size. I send my maximum window size as my INITA, but if their INITA specifies a smaller size I send THE SMALLER size as my INITC. Since you're really only telling the remote sender how big your local receiver's window is, there's not a problem with specifying a bigger window than the remore sender can send, he simply fills the window to HIS capacity and waits for acknowledgements. > /* time to send my first send command... */ > G3: queued data packet seq = 2 len = 60 > G3: Sending data packet 1 > G3: sending: k = 2 tt = 2 xxx = 1 yyy = 0 size = 64 > G3: ctrl = 136 sum = 10981 > /* there it goes. checksumming is right, and the data is all there. */> > G3: reading... > G3: envelope in: tt = 0, xxx = 4, yyy = 0, need = 6 > G3: failure of getpkt, != TT_DATA > G3: got TT_CTRL, xxx = 4 > /* 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. */ First, all data packets are acknowledged. The fact that they are carrying a message is not relevent, since that is at the conversation level, and thus is above the packet protocol. The CONTROL PACKETS are not sequenced, ie INITA, INITB, INITC, RR, RJ, etc. Second, you're right that the RR 0 is a bit strange, but only in that it should be an RR 1 to acknowledge receipt of packet 1. I ran into this problem with some, but not all, of the systems that I talked to. _THIS_ _IS_ _A_ _BUG_! However, it must be dealt with, since there seem to be several "standard" systems which have this problem. My first approach to solving this was the ignore the "out of band" RR 0 and wait for a proper RR 1. The was not forthcoming, however, as the other system timed out and send ANOTHER RR 0, and so forth until we gave up. What I'm doing now is this, if I get an RR which is outside of the expected window, I reset the transmitter counter to the last unacknowledged packet and retransmit from there. This is ugly and painful, but "it shouldn't happen" anyway, so performance is not an issue here. The example sequence then goes like this: initialize send counter to 1 send packet 1 increment send counter to 2 receive RR 0 reset send counter to 1 send packet 1 receive RR 1 The transfer proceeds correctly from there. I've included similar code for handling out of band RJ's as well. Peter has been posting his uucico to comp.os.minix, and may soon post an update (to fix this and a couple of other bugs I've discovered). I'm working on the ST-Minix and ST-TOS versions of uucico (and smail) and plan to post those when they're ready. I suppose comp.sources.misc would be the place for the ST-TOS versions? It's all the same code, just #ifdef'ed for different machine/OS configurations. > Sig: ++Christopher(); | "I am not nuts. I am condements. > Internet: cambler@polyslo.calpoly.edu | I was promoted last thursday!" > Also: chris@fubarsys.slo.ca.us | > Bix: cambler | Support joint US/USSR trip to Mars. \\ / Dale Schumacher 399 Beacon Ave. \\ / (alias: Dalnefre') St. Paul, MN 55104-3527 >< ...umn-cs!midgard.mn.org!syntel!dal United States of America / \\ "What is wanted is not the will to believe, but the will to find out, / \\ which is the exact opposite." -Bertrand Russell