Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucsd!rutgers!cmcl2!phri!ccnysci!ciamac
From: ciamac@ccnysci.UUCP (Ciamac Moallemi)
Newsgroups: comp.mail.uucp
Subject: Re: Zmodem added to UUCP
Summary: A protocol that is a superset of Zmodem would be better
Keywords: Zmodem, UUCP
Message-ID: <3217@ccnysci.UUCP>
Date: 25 Sep 89 21:53:30 GMT
References: <3602@escargot.UUCP>
Reply-To: ciamac@sci.ccny.cuny.edu  (Ciamac Moallemi)
Followup-To: comp.mail.uucp
Organization: City College Of New York
Lines: 37


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!ciamac