Xref: utzoo comp.dcom.modems:3974 comp.mail.uucp:3255
Path: utzoo!mnetor!tmsoft!dptcdc!jarvis.csri.toronto.edu!rutgers!gatech!mcnc!uvaarpa!haven!adm!smoke!bogstad
From: bogstad@smoke.BRL.MIL (William Bogstad )
Newsgroups: comp.dcom.modems,comp.mail.uucp
Subject: Re: Telebits and uucp g-protocol
Keywords: Telebit Trailblazers, g-protocol, uucp
Message-ID: <10391@smoke.BRL.MIL>
Date: 10 Jun 89 13:31:19 GMT
References: <335@nixtor.UUCP>
Reply-To: bogstad@brl.arpa (William Bogstad (JHU|mike) <bogstad>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 46

In article <335@nixtor.UUCP> davidm@nixtor.UUCP (David Macklem) writes:
>I  have a number of questions about Telebits and the g-protocol
>spoofing that they do. Hopefully someone out there will explain.
>
>I understand that the Telebit TB+ modems can do the uucp g-protocol
>between themselves. This ability sure is nice but it doesn't really
>offload the CPU that much, does it? ...
	I believe that this is correct.

>... If so,
>why are there so many (about 5?) protocols supported by these modems?
>Why not just one?
	I assume because they are trying to sell to different
markets.  Unix machines normally talk to each other using
uucp, PCs xmodem or kermit, SLIP is used for IP links, etc.
Nobody has to rewrite any software to gain most of the advantage
of having a Telebit.

>My second question is related to the first. Since the Telebits can do
>the error-checking and correction themselves why don't all uucico's
>communicating using modems that agree on some protocol use the
>f-protocol? This protocol, as far as I can tell, is used over X.25
>lines and the master just sends the whole file and then waits for an
>acknowledgement from the slave.

	Well, I don't think that the f-protocol is in all versions
of UUCP and this would reduce the UNIX market.  I'm not familiar with
the f-protocol, but I would guess that it sends a single checksum for
the entire file.  Although the modem to modem link becomes error free
you have to worry about the serial line running between the host ports
and the modems.  If an error occurred here, the entire file would have
to be retransmitted.  Also some systems probably can't handle a full
speed 9.6K or 19.2K serial connection for the time it would take to send
an entire file.  You can't assume the same size machine on both ends of
the link or even that receive and transmit capabilities for a single 
machine type are balanced.  For terminal connections, the transmit side
almost always ends up with a higher usage and might have been designed
with that assumption.  The receiver might lose characters again
resulting in retransmit.  Actually, I would guess it was the marketing
consideration rather then any other which drove the initial decision to
do the "g" rather then "f" protocol.  The same consideration probably
is why the "f" protocol hasn't been developed yet.  SLIP gains a whole
new market.

				Bill Bogstad
				bogstad@crabcake.cs.jhu.edu