Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!netsys!faatcrl!jimb From: jimb@faatcrl.UUCP (Jim Burwell) Newsgroups: comp.mail.uucp Subject: Re: New UUCP Protocol (was: Re: Zmodem added to UUCP) Message-ID: <1032@faatcrl.UUCP> Date: 8 Oct 89 18:56:06 GMT References: <1024@faatcrl.UUCP> <710@lakart.UUCP> <1029@faatcrl.UUCP> <688.252e37c2@simpact.com> Organization: FAA Technical Center, Atlantic City NJ Lines: 82 jeh@simpact.com writes: >In article <1029@faatcrl.UUCP>, jimb@faatcrl.UUCP (Jim Burwell) writes: >> lights, etc, it sure seems to me like there is some windowing going on. I'm >> not sure, but it seems that 'g' continues to send blocks before it gets acked. >> Either that, or some uucicos spoof it by sending acks before chcking the block >> or something. I guess I'll have to dig through some uucico source.. >> >> yes. increasing the packet size would really help, but it seems like a >> band-aid fix. I still want zmodem! (or some other streaming protocol..but >> why invent a new one ?) >> >uucp 'g' definitely "streams" (or, in more conventional parlance, does >windowing with transmit windowsize > 1; 3 is typical and is more than Hmm. FYI, I didn't say 'g' "streamed". I said it did some kind of windowing. I refered to zmodem as a streaming protocol, since that's what it is. >An increased packetsize will produce, at best, a marginal improvement. >We typically see at least 215 char/sec throughput with 64-byte packets. >Allowing 512-byte packets increases the theoretical max from 219.4 char/sec ^^^^^^^^^^^ >to 237.2, a whopping 8% increase. Not a big deal. And, as someone else >said, increasing the packetsize increases the expense of error recovery. I think 8% is a big deal.. What if it were an increase in your income tax, and not protocol throughput. I bet it would be a big deal then :-). >How would ZMODEM be a big improvement??? I typically get 237-238 cps @2400 bps zmodem transfers from the Sun 3/160 at work running rz/sz to my Amiga at home running JR-Comm. This isn't 'theoretical', it's real. It is very close to the theoretical cps limit form 2400 baud modems. ['g' error handleing deficiencies deleted] >Mind you, it doesn't pay to be too aggressive about sending NAKs either, >as the NAKs are nonspecific and will overlap with the sender's attempts to >resend the current transmit window, so the sender will resend the whole >window again, and... The VMS implementation sends a NAK on >the first data checksum error for a given packet and on every (transmit >windowsize) error after that; this has proved robust on some remarkably >bad lines (some artificially generated, some not), and still allows for >reasonably quick error recovery. Zmodem is probably the most robust protocol I've seen out there. I've had it survive some SERIOUSELY crappy phone connections. It just keeps trying and trying. >In practice, I typically see the receipt of an ACK or NAK for packet 'n' >during the transmission of 'n'+1, so it does not seem to me that either >increasing the windowsize or implementing selective retransmit (which, >by the way, limits your windowsize to 3, given g's 3-bit sequence numbers) >is going to help much. I think the answer would be to forget about 'g', and include Zmodem into uucico's protocol list. It would help a LOT. Just the throughput increases over packet switched networks would be enough to justify it. (A friend of mine gets his news feed over a packet network, and says it's HORRIBLY slow. Zmodem was designed for networks.) Also, I think we would see a big throughput increase with the many PEP modems out there in Unix land. Even though Telebits do all that funky spoofing, it still adds overhead to the transmission. With Zmodem, there wouldn't be a need for spoofing. It doesn't stop blasting data until it needs to (error). I hope we have it in UUCP soon. Bye. -- +------------------------------------------------+--------------------------+ | James S. Burwell | | | | "UseNet...A text network | | UUCP: | in a binary world" - Me | | ...!{ames!netsys|rutgers}!faatcrl | | | !jimb | "How do you say | | . | 'multitasking' in | | Internet: . | MS-DOSish? Network | | // jimb@faatcrl.UUCP . ** | File Server!" - Me | | // . **** | | | \\ // GEnie: Airwarior: . .** | | | \X/ JIMBURWELL Techrat . | | +------------------------------------------------+--------------------------+