chrisb@escargot.UUCP (Chris Bradley) (09/24/89)
Greetings again everyone!
I have spoken briefly with Chuck Forsberg himself, and he says that there
isn't a Zmodem standard for UUCP. I would like to elect myself as "Head of
the project", so to speak. I have come up with, what I believe to be, a
very good extension to Zmodem. Not only is it versatile, it's very simple to
understand. I would like to open it for debate to the net, therefore, I'm
posting the protocol description. Please feel free to e-mail or post responses.
Chances are there is something I have overlooked, but if you find something,
please let me know.
------
Zmodem Protocol Extension To UUCP Startup Sequence
--------------------------------------------------
This file describes the zmodem extension to the UUCP protocol. UUCP Is
started up as a normal UUCP session with the addition of the "z" to the list.
Sender Receiver
------ --------
<------- \020Shere\0
\020S<mastername> <sw>\0 ------->
<------- \020ROK\0
<------- \020PgXyz\0 (1)
\020Uz\0 ------->
<------- ZACK
or
<------- ZCAN, ZCAN, ZCAN, ZCAN, ZCAN
(1) Capital X, lower case y, and z have been reserved for Xmodem, Ymodem,
and Zmodem respectively.
At this point, the receiver can back out of Zmodem if it can't link to its
Zmodem program. Otherwise, it tells the sender to go ahead and sent the files
in Zmodem batch mode.
ZRQINIT ------->
(Normal Zmodem batch takes place)
ZFIN ------->
<------- ZFIN
OO ------->
The "OO" is a Zmodem "Over And Out" standard. It isn't a requirement that the
receiver hear the two "OO"'s.
Once the initial transfer has completed, both machines know that it's time to
turn the line around. Therefore, the receiving computer, below, says "Let's
use the Zmodem protocol".
<------- \020Uz\0
ZACK ------->
or
ZCAN, ZCAN, ZCAN, ZCAN, ZCAN ------->
Here again, it gives the sender the opportunity to cancel out if it can't
link to the Zmodem receive program.
Upon receipt of five ZCAN's, the two systems will disconnect.
<------- ZRQINIT
(Normal Zmodem batch takes place)
<------- ZFIN
ZFIN ------->
<------- OO
(Systems disconnect)
Not much more to be said. Fairly self-explanatory.
I kept in mind to keep the above exchange as simple as possible to keep
programming time and complexity to a minimum.
-------
Comments anyone?
-->Chris
UUCP: ..tektronix!tessi!escargot!chrisb "I didn't like the Mercury Sable,
Phone: (503) 644-3585 (Call anytime!) So I bought a Ford Taurus instead!"csg@pyramid.pyramid.com (Carl S. Gutekunst) (09/26/89)
In article <3602@escargot.UUCP> chrisb@escargot.UUCP (Chris Bradley) writes: > This file describes the zmodem extension to the UUCP protocol. UUCP Is >started up as a normal UUCP session with the addition of the "z" to the list. If I understand this proposal correctly, what you have described is a way to use uucico as a protocol selection frontend to the standard ZModem file trans- fer routines. Likewise for XModem and YModem, yes? A useful idea, but please do not call it 'z', a code that Rick Adams and I are trying to reserve for a native UUCP ZModem protocol implementation. Call yours 'Z' or something like that. If someone really wants to do a native UUCP Zmodem protocol, I'd be happy to discuss it with them. It's about a two-day hack for someone who already knows UUCP. (Romain keeps implying he doesn't have enough work to do. Here's some- thing I could throw at him.... :-)) <csg>
ciamac@ccnysci.UUCP (Ciamac Moallemi) (09/26/89)
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.
Make use of the full bandwidth of the connection by sending and
receiving data at the same time. This also requires being able to
send and receive files in the same call to rz/sz.
o Encryption
Be able to use private and maybe public key encryption on the data
sent and received.
o Data Compression
Zmodem already supports RLE and LZW. RLE is a joke. LZW would
probably be to slow and I have not seen it actually implemented. A
good alternative would be splay tree Huffman encoding with 64 Markov
states. This compresses faster than 16-bit compress, performs just
slightly worse, and uses much less memory (2k per state, 128k total).
Systems with more memory could add more states and therefore acheive
better compression. Built-in logic could be added to detect
compressed (.Z), zoo, arc, etc. files and avoid 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.
//cm
--
Ciamac Moallemi | ciamac@sci.ccny.cuny.edu
Dept. of Earth and Planetary Sciences | ciamac@ccnysci.BITNET
City College of New York |
...!{cmcl2,philabs,phri}!ccnysci!ciamactneff@bfmny0.UU.NET (Tom Neff) (09/26/89)
In article <85418@pyramid.pyramid.com> csg@pyramid.pyramid.com (Carl S. Gutekunst) writes: >If someone really wants to do a native UUCP Zmodem protocol, I'd be happy to >discuss it with them. It's about a two-day hack for someone who already knows >UUCP. (Romain keeps implying he doesn't have enough work to do. Here's some- >thing I could throw at him.... :-)) ZMODEM UUCP would be terrific for long distance links, both for the excellent error checking and (if done right) for the ability to resume aborted transfers in mid-file. Its streaming features would also be welcome over packet switched networks like CPN. -- "Take off your engineering hat | "The filter has | Tom Neff and put on your management hat." | discreting sources." | tneff@bfmny0.UU.NET
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (09/26/89)
In article <85418@pyramid.pyramid.com>, csg@pyramid.pyramid.com (Carl S. Gutekunst) writes: | If I understand this proposal correctly, what you have described is a way to | use uucico as a protocol selection frontend to the standard ZModem file trans- | fer routines. Likewise for XModem and YModem, yes? Zmodem is a good idea. It works well over links with long time delay for turnaround, allows restart of file transfers, works very well over packetized connections, and lots of good things. However, I can't think of a single instance in which Xmodem or Ymodem would provide any gain over existing protocols. If the idea is to allow connection to non-uucp programs, there are better ways to do it, such as using Kermit for a front end (I posted a program to do this to alt.sources recently). As an extension for use on dificult lines I like it, but there seems to be no benefit to adding X and Y protocols, which seem to perform worse than g under any typical conditions. I'm not in favor of "protocol clutter." -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "The world is filled with fools. They blindly follow their so-called 'reason' in the face of the church and common sense. Any fool can see that the world is flat!" - anon
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (09/26/89)
In article <3217@ccnysci.UUCP>, ciamac@ccnysci.UUCP (Ciamac Moallemi) writes: | | o Bidirectional transmission. A very good idea. However, it doesn't buy anything on many common half duplex dialup modems, and should be optional. It can buy a lot with a full duplex connection, but it looks as if a MAJOR rewrite of uucp would be needed to support doing two things at once. | | o Encryption | | o Data Compression There are programs to do this offline, which avoids the posssibility of the encyrptor not being able to keep up with the line. There seems to be little to gain by adding a lot of features to uucp for doing things which are easily done by separate programs. Adding features which are not generally needed makes the program larger, more complex, and less reliable. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "The world is filled with fools. They blindly follow their so-called 'reason' in the face of the church and common sense. Any fool can see that the world is flat!" - anon
les@chinet.chi.il.us (Leslie Mikesell) (09/27/89)
In article <14730@bfmny0.UU.NET> tneff@bfmny0.UU.NET (Tom Neff) writes: >ZMODEM UUCP would be terrific for long distance links, both for the >excellent error checking and (if done right) for the ability to resume >aborted transfers in mid-file. Its streaming features would also be >welcome over packet switched networks like CPN. SysVr3.2 HDB uucp 'g' protocol is supposed to support resuming aborted transfers and the default window size is 7 packets (instead of the old 3). It's better, but still not enough for efficient use over a satellite link. Les Mikesell
csg@pyramid.pyramid.com (Carl S. Gutekunst) (09/27/89)
>| >| o Bidirectional transmission. > >It can buy a lot with a full duplex connection, but it looks as if a MAJOR >rewrite of uucp would be needed to support doing two things at once. Understatement. UUCP was never written for bidirectional transfers, and the entire model would have to change. Fork multiple processes, with semaphores among them, or perhaps schedule things with select(2). As far as encryption and compression, those are better placed higher level where they really do some good. Batch mode file transfer would be more useful, especially with half-duplex devices like the TrailBlazer. But that can be done in external code, too. Someone mentioned partial file transfers. Honeyman's own HDB does this, so rumor has, though of course it only works if you have matching uucicos at both ends. <csg>
csg@pyramid.pyramid.com (Carl S. Gutekunst) (09/27/89)
> Zmodem is a good idea. It works well over links with long time delay >for turnaround, allows restart of file transfers.... Note that lots more would have to happen to uucico to allow this than just doing a ZModem protocol module. Rumor has Honeyman's own uucico does partial file transfers; someday before the return of the Heechee you'll see AT&T ship it in SVRn, where (4 < n <= inf). <csg>
csg@pyramid.pyramid.com (Carl S. Gutekunst) (09/27/89)
In article <14730@bfmny0.UU.NET> tneff@bfmny0.UU.NET (Tom Neff) writes: >ZMODEM UUCP would be terrific for long distance links, both for the >excellent error checking.... Actually, the error checking is sloppy if you are using a non-error-corrected dialup lines. Whenever an error occurs, the sending side has to back up and retransmit starting from the block with the error, and that could be a lot of data. (Or has ZModem added per-window retransmission and I just missed it?) <csg>
lyndon@cs.AthabascaU.CA (Lyndon Nerenberg) (09/29/89)
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) writes: >| o Encryption >| >| o Data Compression > There seems to be little to gain by adding a lot of features to uucp >for doing things which are easily done by separate programs. Adding >features which are not generally needed makes the program larger, more >complex, and less reliable. There is another hidden problem here. If the compression or encryption algorithms change in a way that's incompatible with existing systems, you either have to change the protocol name, or add version numbering. I don't like the first solution since there are a limited number of protocol identifiers available, and the second requires your uucico to support ALL versions of the protocols, or reject connections with sites running older versions of the software (that you no longer support). -- Lyndon Nerenberg VE6BBM / Computing Services / Athabasca University {alberta,decwrl,lsuc}!atha!lyndon || lyndon@cs.AthabascaU.CA "I think every man should have a wife. You can't blame everything on the government." -- Jed Clampett
jeh@simpact.com (09/29/89)
In article <3602@escargot.UUCP>, chrisb@escargot.UUCP (Chris Bradley) writes: > I have spoken briefly with Chuck Forsberg himself, and he says that there > isn't a Zmodem standard for UUCP. I would like to elect myself as "Head of > the project", so to speak. I have come up with, what I believe to be, a > very good extension to Zmodem. Not only is it versatile, it's very simple to > understand. I would like to open it for debate to the net, therefore, I'm > posting the protocol description. Please feel free to e-mail or post responses. > Chances are there is something I have overlooked, but if you find something, > please let me know. > (...) In article <3217@ccnysci.UUCP>, ciamac@ccnysci.UUCP (Ciamac Moallemi) writes: > 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... Others have commented on the merits of the features suggested (bidirectional transmission, encryption, data compression). I will briefly add my opinions that (a) bidirectional transmission would require a major redesign of the entire uucp system; (b) the bulk of uucp traffic is news and mail; it is self-evidently ridiculous to spend a single cpu cycle to encrypt news, and mail encryption/decryption belongs in the mail user agent; and (c) the vast bulk of uucp traffic is (in my limited experience) news, which is already being compressed via modified Lempel-Ziv. But my main purpose here is to comment on the general direction of Mr. Moallemi's response. It is all too easy to listen to someone say, "gee, I'm thinking of doing A", and respond with "Well, that isn't really worth doing unless you also do A1, A2, and B, C, and D as well." (I know it's easy, because I've done it myself!) Such a response has a high probability of discouraging the original volunteer from doing anything at all. This is bad. It is much better to encourage volunteer efforts, regardless of whether they will end with all of the bells and whistles you'd eventually like to see. And if you really feel that, for example, ... > A good alternative would be splay tree Huffman encoding with 64 Markov > states. This compresses faster than 16-bit compress, performs just > slightly worse, and uses much less memory (2k per state, 128k total). > Systems with more memory could add more states and therefore acheive > better compression. Built-in logic could be added to detect > compressed (.Z), zoo, arc, etc. files and avoid compression. > These are just off of the top of my head.... ... fine -- go forth and implement! But don't sit back and tell others what they really *ought* to be doing. --- Jamie Hanrahan, Simpact Associates, San Diego CA Chair, VMSnet [DECUS uucp] and Internals Working Groups, DECUS VAX Systems SIG Internet: jeh@simpact.com, or if that fails, jeh@crash.cts.com Uucp: ...{crash,scubed,decwrl}!simpact!jeh
tneff@bfmny0.UU.NET (Tom Neff) (09/29/89)
In article <682.2522121c@simpact.com> jeh@simpact.com writes: > ... (b) the bulk of uucp traffic is news and mail; it is >self-evidently ridiculous to spend a single cpu cycle to encrypt news ... Everything else Jamie said was spot-on, but I would point out that B news can be used for proprietary in-company information purposes too, not just for the public newsgroups we read here. So encrypting some news might indeed make sense. But this should certainly be done before UUCICO gets hold of it, not in the protocol itself. I wonder if Chuck Forsberg (uunet!omen!caf) is reading this and would care to comment on the feasibility of adding a 'Z' protocol to UUCP. -- "Nature loves a vacuum. Digital \O@/ Tom Neff doesn't." -- DEC sales letter /@O\ tneff@bfmny0.UU.NET