Xref: utzoo comp.mail.uucp:5417 comp.dcom.modems:7237
Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cbmvax!grr
From: grr@cbmvax.commodore.com (George Robbins)
Newsgroups: comp.mail.uucp,comp.dcom.modems
Subject: Re: What should a new UUCP protocol do?
Message-ID: <15709@cbmvax.commodore.com>
Date: 8 Nov 90 07:36:41 GMT
References: <1990Nov07.155516.17815@ism.isc.com>
Reply-To: grr@cbmvax.commodore.com (George Robbins)
Distribution: usa
Organization: Commodore, West Chester, PA
Lines: 23

In article <1990Nov07.155516.17815@ism.isc.com> johnan@ism.isc.com (John Antypas) writes:
> Interactive Systems is now the fortunate owner of many different modems...
> 
> We are looking into placing a new protocol into UUCP which copes with
> the higher-speed modems, but doesn't require protocol spoofing, nor
> does it assume your running X.25 (no f protocol).  What characteristics
> should we shoot for when dealing with what we call, the new low-end
> high speed modem.

Please review carefully all existing BSD and AT&T protocols and see which
are salvagable.  The silly little "g" protocol should give good results if
you fix the buffer allocation stuff so you can actually negotiate packet
sizes.  It's easy...  **BUT** you also need to make sure the tty drivers will
support large "raw" queues - 255 characters isn't enough, and watch out
for other raw mode silliness.  It may all be fixed with streams???

I'd also suggest you get in touch with rick@uunet or csg@pyramid - these
and others have invested serious time into uucp problems and foibles..

-- 
George Robbins - now working for,     uucp:   {uunet|pyramid|rutgers}!cbmvax!grr
but no way officially representing:   domain: grr@cbmvax.commodore.com
Commodore, Engineering Department     phone:  215-431-9349 (only by moonlite)