athos@eyrie.img.uu.oz.au (David Burren) (02/06/91)
Some background: A local firm is working on a modem project that supports high speed transfers by a "ping-pong" protocol, and are implementing front-ends that support standard modem transfer protocols including Kermit, X, Y, Z-modem, etc. I'm trying to convince them to include some level of UUCP-g support. Whether this will involve spoofing the 'g' transactions in the same manner as a Trailblazer or just manipulation of the 'g' parameters, I do not yet know. My hope is to get a relatively cheap 9600 bps UUCP solution for some of the Usenet sites around here that are still on 2400 bps. To ensure that we (they & I) get it right, I have some questions about the protocol and the various implementations of it that are around. This includes PC & Amiga versions as well as Unix... My main reference for the protocol is the paper by Chesson. Any quoted passages are from that paper. ... the UNIX implementations no longer generate or response to SRJ messages. It is mentioned here for historical accuracy only, and one may assume that SRJ is no longer part of the protocol. Does this mean that an implementation should not respond to SRJ messages if they are received? Do any existing implementations generate them? With regard to INIT[ABC] messages, will existing implementations respond to them if they are received during a session? I understand that most (if not all) implementations will not initiate such a transaction, but will they respond to one? How many implementations will use the full 7-window, 4096-byte packet parameters? Will most only do 3 x 64? If appropriate, how can this be modified on various systems? (adb patching instructions accepted) I understand that some systems have problems with serial I/O buffers and have trouble with windows larger than 256 characters, and thus don't cope with the larger window and packet sizes. Any help you can give clearing these questions up will be most appreciated. Thanks! ___________________________________________________________________________ David Burren (Athos) img Consultants Systems Development (general dogs-body) G.P.O. Box 3304GG Melbourne, VIC 3001 Email: athos@img.uu.oz.au Australia Phone: +61 3 819 4554
zonker@diku.dk (Claus Engdahl) (02/07/91)
athos@eyrie.img.uu.oz.au (David Burren) writes: > . > . > . >My main reference for the protocol is the paper by Chesson. Any quoted >passages are from that paper. Which paper? (does anyone know where I can obtain a copy?). -- Claus Engdahl (zonker@diku.dk, postmaster@diku.dk, staff@diku.dk,,,,,) ---------------------------------------------------------------------- My motto is: Honi soit qui pense ;-)
jeh@dcs.simpact.com (02/08/91)
In article <3551@eyrie.img.uu.oz.au>, athos@eyrie.img.uu.oz.au (David Burren) writes: > Does [Chesson] mean that an implementation should not respond to SRJ messages > if they are received? Do any existing implementations generate them? My implementation of the protocol [within Decus UUCP] will log as an error, and continue, any SRJ messages. In a year and a half or so in the field, no one has reported seeing this error message in their log files. > With regard to INIT[ABC] messages, will existing implementations respond > to them if they are received during a session? I understand that most > (if not all) implementations will not initiate such a transaction, but will > they respond to one? The general rule is "be conservative in what you send, and liberal in what you expect" (author unknown). I ignore (other than logging as "unexpected control packet received) these after the initial init sequence has completed, and as with the SRJ issue, no one has complained of failures in this area. > How many implementations will use the full 7-window, 4096-byte packet > parameters? don't know. Although 7x4K is "latent" in my code (I use two eight-entry tables to keep track of received and xmtd packets) I haven't gotten around to turning it on because the normal way people get more speed is to buy trailblazers... which specify 3x64 in the inits they send to you, and which will never send you anything bigger than 3x64, even if you tell them you can take more. > Will most only do 3 x 64? I don't know how you define "most" (number of implementations, or number of installations?) but my impression is that the answer (either way) is yes, w/o modification, "most" only do 3x64. > If appropriate, how can this be > modified on various systems? (adb patching instructions accepted) I dunno. > I understand that some systems have problems with serial I/O buffers and > have trouble with windows larger than 256 characters, and thus don't cope > with the larger window and packet sizes. Correct. But the real issue here is, if a system tells you (via the init sequence) to use 3x64, don't ever send more. Note that this is not really parameter "negotiation", even though that is the term most often used to describe it. What is going on is that each receiver tells the xmtr at the other end what it [the receiver] can accept and the xmtr had damn well better not send anything bigger. I'll post my uucp protocol description (which is based on the Chesson paper, and on other things posted here, together with some experience from "the trenches") following. An implementation hint: I laced my g protocol module with statements which, if enabled via control file options, would induce errors on incoming and outgoing data, with adjustable probabilities. Dropping outgoing/incoming ACKs, corrupting checksums on i'ing/o'ing packets, corrupting i'ing/o'ing XORs on packet headers, stuff like that. This was very simple to implement and combined with much better logging than I've seen in typical Unix uucp debug files, allowed me to observe and analyze behavior under some truly pathlogical [simulated] line conditions... and to fix some bugs that we could NEVER have fixed with only reports from the field to go on. [enter brag mode] In fact, except for one little glitch wherein the trailblazers would insist on sending us an extra "initc" after we thought we were all done with the init sequence (I 'fixed' this by completely ignoring initc's after the init sequence was done, not even logging them), no one has reported bugs relating to our g protocol implementation -- a year and a half in the field, estimated over 100 sites. [leave brag mode] We'd have had a much harder time without the error simulator. A BERT [Bit Error Rate Test set -- a bit of hardware that you attach to a serial line, and set for how many bits out of n you want it to corrupt] would not have been as good. By doing it in software we could do specific stuff relating to the protocol (as opposed to just corrupting randomly-selected bits) and we could also put in log entries (e.g. "about to corrupt outgoing ACK") that made the subsequent log entries re. the error recovery a whole lot easier to interpret. --- Jamie Hanrahan, Simpact Associates, San Diego CA uucp protocol guru, VMSnet [DECUS uucp] Working Group, DECUS VAX Systems SIG Internet: jeh@dcs.simpact.com, or if that fails, jeh@crash.cts.com Uucp: ...{crash,scubed,decwrl}!simpact!jeh