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          .     |     |
+------------------------------------------------+--------------------------+