Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!decwrl!labrea!agate!helios.ee.lbl.gov!lll-tis!oodis01!uplherc!sp7040!obie!wsccs!terry
From: terry@wsccs.UUCP (Every system needs one)
Newsgroups: comp.dcom.modems
Subject: Re: Telebit Setup script
Summary: wonder no more
Message-ID: <773@wsccs.UUCP>
Date: 10 Nov 88 03:28:14 GMT
References: <260@eda.com>
Lines: 83

In article <260@eda.com>, jim@eda.com (Jim Budler) writes:
> I still
> wonder about that "no flow control" statement below, but they oughta know.
> 
> 
> 
> #        (S58=0) disables flow control.
> #                The UUCP protocol support handles flow control instead.

Wonder no longer.  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, it is possible to
implement flow control by simply not sending the ACK or NAK back from the
modem to uucp.  If you don't send back the ACK, it won't send you any more
data.

Another reason to avoid flow control is the fact that IXON is handled at
the kernel level.  What this means to you is that if you get XOFFed by the
modem, you will hang in your read or write until you receive an XON.  The
period of time you wait depends only on how long the interval is before
you get an XON.  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.

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.  With
the current Zmodem code, this cannot be easily handled in user-mode code, as
it may be swapped and Zmodem provides no mechanism for being clever about
avoiding swapping in the user-mode code handling XON/XOFF.

Not using XON/XOFF is also a good bet with binary protocols.  Xmodem, for
example, discounting that 1 out of 128 characters is a flow control character
and that most implementations of flow control ignore the 8th bit (making it
1 out of every 64 character - 2 times a packet), the packet sequence numbers
on packets 17 and 19 are ^Q and ^S, respectively.  Given a modem intercepting
these, all hell breaks loose.  In the best case, the ^S is passed through
delayed.  In the worst case, it is never sent to the other machine.  The
protocol breaks.

Nobody wanting to transfer files reliably will use a modem with flow control
turned on...

	On the other hand, since these very fast modems really aren'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.  This is a dilema.  Unfortunately, it won't be
resolved until one of four things happen:

	1)	Communications software is all 6-bit quoted, non-binary
		alphanumeric protocols, like kermit.  This will never
		happen.  The protocols are orders of magnatude slower
		than binary protocols.

	2)	Communications bandwith is limited to the throughput
		the line and modulation technique is minimally capable
		of, given worst-case compression, etc.  This will never
		happen.  Not doing this sells modems.

	3)	Manufacturers adopt a standard method of altering flow
		control parameters via software.  This is hard, and
		probably won't happen; one manufacturer is never going
		to agree with another on how his modem can tell the other
		guys modem at the other end of the line to turn off flow
		control (this is necessary; in terminal sessions, if only
		one end supports flow control it doesn't work for terminal
		sessions).  This still ignores the problems of using high
		speed modems for TCP/IP SLIP links or any other multiplexed
		terminal-session-while-you-transfer scheme.

	4)	End users realize they can't have real fast modems doing
		binary protocols and terminal sessions without reconfiguring
		both ends in between.  This, really, will never happen.

So you accept the rocks and live with them, one way or another until you
discover a tradeoff that is acceptable to your situation.  Oh well.


| Terry Lambert           UUCP: ...{ decvax, uunet } ...utah-cs!century!terry |
| @ Century Software        OR: ...utah-cs!uplherc!sp7040!obie!wsccs!terry    |
| SLC, Utah                                                                   |
|                   These opinions are not my companies, but if you find them |
|                   useful, send a $20.00 donation to Brisbane Australia...   |
|                   'I have an eight user poetic liscence' - me               |