Path: utzoo!utgpu!watmath!clyde!att!chinet!bigtex!james
From: james@bigtex.cactus.org (James Van Artsdalen)
Newsgroups: comp.dcom.modems
Subject: Re: Telebit Setup script
Message-ID: <10508@bigtex.cactus.org>
Date: 13 Nov 88 07:33:39 GMT
References: <260@eda.com> <773@wsccs.UUCP>
Reply-To: james@bigtex.cactus.org (James Van Artsdalen)
Organization: Institute of Applied Cosmology, Austin TX
Lines: 46

In <773@wsccs.UUCP>, terry@wsccs.UUCP (Every system needs one) wrote:

> Since the uucp protocol is what is called an ACK-NAK protocol... that
> is, it must receive an ACK before it transmits the next packet or a
> NAK before it retransmits the current one,

This is a little deceptive.  uucp 'g' (there is more than one protocol
in uucp but only 'g' is universal) actually has a window size: several
packets can be outstanding.  The sender doesn't wait for an ACK on the
last packet, but conceptually waits on the ACK from three or so
packets back (as many as seven).  Indeed, my 'g' driver does precisely
this: it sends the window size of packets, and then at each further
packet waits explicitly on an ACK N - window_size old.

> Another reason to avoid flow control is the fact that IXON is handled
> at the kernel level.  [...]  Since you are hanging in the kernel, any
> signals you have used to interrupt your read will be queued until that
> time.  If, then, you receive an XOFF and the line drops, you are
> stuck.  Forever.

Such a device driver would not be useful.  Presumably alarm(2) would
interrupt any such "hanging".

> This is why you will never see a Zmodem implementation for Xenix that
> works worth a darn.  Sliding windows require the capability for flow
> control.

Zmodem doesn't really use sliding windows, certainly not in the Kermit
sense.  Zmodem also coexists with XON/XOFF even with binary transfers.

> On the other hand, since these very fast modems really aren't,

I would think I would have long since noticed if my very fast modem
really wasn't.

> if you drive the modem at it's advertised speed, you will certainly
> overrun it's buffer.  You have to hold it down to the throughput the
> line is minimally capable of.

You appear to neglect hardware handshake.  My system talks to my TB+
at 19.2Kbps even when the modem is connected at 2400bps: Xmodem and
other binary applications work fine because the handshake is done via
RTS/CTS, out of band.
-- 
James R. Van Artsdalen      james@bigtex.cactus.org      "Live Free or Die"
Home: 512-346-2444 Work: 338-8789       9505 Arboretum Blvd Austin TX 78759