🚀 go-pugleaf

In article <230kiB4w164w@lambada.UUCP> cory@lambada.UUCP
(Cory West) writes:

>                                                     I still think
>that for DOS <--> DOS transfers, a Zmodem style transfer would work well.

I would strongly recommend AGAINST using Zmodem for your UUCP
transport layer.  This is my opinion only, of course.

Zmodem works well for its intended purpose; user-supervised
uploads/downloads.

However, most UUCP communication is unsupervised.  Zmodem does not
require ANY ack's from the receiving system.  Zmodem is quite
capable of thus continuing to dump data for hours into a system
that has hung, died, modem unplugged from computer, etc.

Three window, 64-byte packet UUCP-g does far too many ack's at 9600
baud, but going to no acks at all is not a great solution.

Even for local calls, a hung recipient under Zmodem could tie up
the sending modem.  And any replacement for UUCP-g that you propose
has to be acceptable to those who do long-distance transfers!

----------------------------------------------------------------------------

Designing a protocol that works and recovers from errors is much
more difficult than it looks.  UUCP-g works; the problem is the
compiled-in limits of three windows and 64 bytes.  The solution is
not to throw out a system that has worked for many thousands of
sites for many years and replace it with something radically
different, but to use larger parameters.  Somebody with source to
Waffle should just change these values in uucico.

A "bigger" uucico would also have a big advantage over a Zmodem
replacement:  The new UUCP-g protocol would be compatible with all
the existing uucico systems, since window and packet sizes are
negotiated between the two systems at start up.

- Paul Colley
University:  colley@qucis.queensu.ca
Home:        pacolley@ember.uucp   watmath!ember!pacolley  +1 613 545 3807
"Quantum Mechanics:  The dreams stuff is made of"    - Ken Burnside