Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!gem.mps.ohio-state.edu!ginosko!uunet!pyrdc!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: <1024@faatcrl.UUCP> Date: 29 Sep 89 14:52:17 GMT References: <3217@ccnysci.UUCP> <240@tabbs.UUCP> Organization: FAA Technical Center, Atlantic City NJ Lines: 65 aris@tabbs.UUCP (Aris Stathakis) writes: >From article <3217@ccnysci.UUCP>, by ciamac@ccnysci.UUCP (Ciamac Moallemi): >> Why use Zmodem? A protocol that is a superset of Zmodem would >> probably be better (maybe Zmodem itself needs to be revised). A few >> extra features that I can think of: >> >> o Bidirectional transmission. >> o Encryption >> o Data Compression >> >> These are just off of the top of my head. I think the Zmodem standard >> needs some revision before we do something big like add it to UUCP. >I think it's about time someone made a new UUCP protocol with some of these >features. Especially Bi-directional transmission. It has been done before >for MS-DOS, and i remember and old program for the APPLE II+ that did >bi-directional transfers. Bi-directional transfer would be nice on sites with full duplex modems, but wouldn't work well at all on sites with half duplex, or ping-pong type modems. There are many UUCP sites which use Telebit Trailblazers and T2500s. Bi-directional transfers wouldn't buy these sites anything. It would be nice for people with generic 2400 baud modems though. It would be difficult to implement in the current UUCP though. >The 'g' protocol is a bit outdated. We need something NEW and better. >Some ideas i had - >1) Variable size packets (that work with MNP5) >2) Bi-Directional transmission. >3) A bit of compression perhaps The 'g' protocol is a bit outdated. But it's not as bad as one might think. There is a bit of windowing involved, which makes 'g' much faster than other protocols which also require handshakes after every block (xmodem, ymodem). Zmodem would be a great addition to UUCPs standard protocols though. It would be the perfect protocol for the Telebit high-speed modems! Handshakeing is only done if it NEEDS to be done (a sector error or something). The file is "streamed" with no delays between bytes, and if a transfer is aborted, one can resume it on a block boundry from where it ended! I don't know how easy it would be to work a Zmodem "resume" type transfer into UUCP though. I don't think we need compression. Most news gets batched and compressed offline before it is sent anyway. It would be nice if mail could be compressed though, I suppose. The latest version of Zmodem does have compression built in, but I'm not sure how easy it would be to implement in UUCP, turning it on and off as needed. -- +------------------------------------------------+--------------------------+ | 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 . | | +------------------------------------------------+--------------------------+