Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!seismo!lll-lcc!pyramid!ncc!lyndon
From: lyndon@ncc.UUCP
Newsgroups: comp.os.minix,comp.mail.uucp
Subject: Enhanced protocols (Was Re: uucp ...)
Message-ID: <1381@ncc.UUCP>
Date: Sat, 4-Apr-87 03:38:10 EST
Article-I.D.: ncc.1381
Posted: Sat Apr  4 03:38:10 1987
Date-Received: Sun, 5-Apr-87 09:43:01 EST
References: <480@gouldsd.UUCP> <43183@beno.seismo.CSS.GOV> <122@njitsc1.UUCP>
Distribution: comp.os.minix
Organization: Nexus Computing Corp.,  Edmonton, AB
Lines: 23
Keywords: uucp uucico kermit
Xref: utgpu comp.os.minix:501 comp.mail.uucp:404
Summary: g vs G

In article <122@njitsc1.UUCP>, bc@njitsc1.UUCP (Bill Cheswick) writes:
> [...]
> And while you are looking for a protocol, how about using one that transmits
> files in both directions at the same time?  There are many protocols that
> have solved this problem already.

Actually, the code for the 'g' protocol is very close to this already.
By implementing the Selective Reject feature, "piggyback ACKS", and a
proper sliding window, the protocol would be capable of handling 
concurrent bidirectional transfers (I wonder how well the hardware
would keep up to this on a PC running at 9600 baud). There are numerous
potential side effects involving state synchronization at each end that
have not been addressed (to my knowledge) before.

There are some nice features that can be adopted from Kermit. The
ability to automatically negotiate 7/8 bit data paths is the most
obvious, but there are others. With the rapid increase in the volume
of net traffic recently, it's probably not to soon to look at on the
fly data compression either...

--
Lyndon Nerenberg   UUCP: {mnetor!seismo, ihnp4, ubc-vision}!alberta!ncc!lyndon
			 {pyramid, winfree}!ncc!lyndon