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