Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.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: <1034@faatcrl.UUCP> Date: 10 Oct 89 00:54:26 GMT References: <1024@faatcrl.UUCP> <710@lakart.UUCP> <1029@faatcrl.UUCP> <688.252e37c2@simpact.com> <1032@faatcrl.UUCP> <1989Oct9.003603.3693@esegue.segue.boston.ma.us> Organization: FAA Technical Center, Atlantic City NJ Lines: 62 johnl@esegue.segue.boston.ma.us (John R. Levine) writes: >Zmodem is undoubtedly a better protocol than 'g' for a full-duplex >transparent connection such as that provided by 2400 bps modems, 9600 bps >V.32 modems, or by packet switch networks. PEP, though, is really a >half-duplex protocol, and fakes full-duplex by turning the line around. That >means that the zmodem ACK packets cause a performance hit and spoofing would >still be a win. Hmm.. Zmodem doesn't send ACK packets back to the sender, unless it's in some silly mode (portal and GEnie seem to use that block/ack mode). Normally, Zmodem just thunders along, sending data, and the reciever sucks it up. The control info (sector number, command sequences, and CRCs) are embedded into the constant stream of data at intervals known to both the sender and receiver (whatever the current packet length is.. Anywhere from 64 {32 ?} bytes to 1Kb). The only time the receiver ever sends data back to the sender is when there is a problem (a bad CRC, sector length, etc, etc), or to ACK the ZFIN (Zmodem end of file packet) at the end of the transfer. >If someone who actually understands the details of how Telebit's spoofing >works, and what sort of protocol they really use, that would be great. PEP >uses a large number of very slow channels, and I don't know whether spoof >mode means that they use a few of the channels for the ACKs and the rest >for the data, or if they use bigger blocks and still turn the line around. PEP is an "error free" protocol between the two PEP modems. The Telebits simply ack every block they get from 'g' on the computer, unless there is a fatal error in the PEP link, in which case they cancel the transfer (I don't know how one cancels a 'g' transfer.. maybe just NAK it out).. In other words, the modem just tells 'g' what it wants to hear, while the real data transfer handshaking/ error correction/etc is done between the modems in PEP. This is how all spoof modes work on Telebits.. >(Gee, Jim, I never had any trouble sucking down news from you using 'g' >spoof mode.) :-). Yeah, but I bet our xfer times would have been MUCH faster if it used Zmodem.. :-). Actually, UUCP could be scrapped all together if Zmodem were used exclusively.. I don't know if it was ever implemented, but in Zmodem, there is a provision for passing commands to a shell through the protocol. Some kind of "command packet" in which a string is sent which gets stuffed into a shell. But forget that! UUCP works fine the way it is, 'cept for the protocols used by uucico, IMHO.. It would be nice to have Zmodem.. sigh.. -- +------------------------------------------------+--------------------------+ | 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 . | | +------------------------------------------------+--------------------------+