From: Paul Placeway <pplacewa@bbn.com>
Newsgroups: comp.sys.amiga.datacomm,comp.dcom.modems,comp.protocols.misc
Subject: Re: New modem transfer protocol
Date: 13 Apr 1992 21:38:24 GMT
NNTP-Posting-Host: bbn.com

karl@MorningStar.Com (Karl Fox) writes:

<       I guess the original author's question (not mine!) might be:
<    "Why frame the blocks at all?  If the size of the blocks is fixed
<    and known, then we can use that to determine which block we're
<    working on...

My reply to "Why frame the blocks at all?" is because Real Life isn't
fair.  Theoretically a 99.99999997% data protocol looks very nice, but
VERY few computers can withstand a sustained 57.6kbps async input
stream for many MB without blocking.  In fact, it's pretty hard to
guess just how big the burst-input buffer is; and the result of
guessing wrong is pretty bad -- if you guess too small, then you waste
time waiting, and if you guess too large then the receiver generally
drops some (but NOT all) of a block.  Most of the machines I've dealt
with (Unixen, PCs, and Macs) will start dropping characters after
about 4KB or so, with the above results.

So to work around this problem you have to have variable block sizes
(which could be in multiples of 10 or 16, but multiples of 256 is
definitely too small).  In order to properly quickly recover from an
overflow you have to put (possibly short) block beginning and ending
markers, further dragging down the efficiency.

Now if you are currently trying to shove several large packets (like
1KB each, times 4--8) into the remote side, and they NACK one, what
should you do?  If they NACKed because some line noise garbaged
things, then just resending the packet is OK.  On the other hand, if
they NACKed because the input queue just overflowed, then you
definitely DON'T want to just shove as much as possible back, but
instead you want to send some smaller part of the original packet.
Since in general you can't tell (like, say you just overflowed the
input queue of an Annex, Xyplex, etc. terminal server that you are
using to get to your Unix box), then the safe thing to do is always
resend in smaller packets then you tried, and SLOWLY raise the packet
size back up, trying to stop at a good estimate of just shy of what
you can get away with.

Also, you probably want to avoid sending an XON or XOFF as data,
because some part of the channel might be running in-band flow
control, and you don't want to kick it by mistake.  Also, if you have
a terminal server or something in the way, it might have an escape
character that you have to avoid.  This too will cut your efficiency.

At this point in the design you have a choice.  If you choose to try
to get away with slightly more than is realistically possible, you get
ZMODEM, which works fine for PC to PC with nothing but modems in
between, but can't handle a telnet connection without a lot of special
feeding.

Or you can try to be a bit extra cautious, and you get Kermit with
sliding windows, which isn't quite as efficient as possible, but is
pretty close, and will still send data through a pair of tin cans and
a wet string.  Kermit isn't quite as good as it should be -- it can't
send a smaller reply to a NACK than the original offending packet, but
it's just about perfect otherwise, considering the channel constraints
it can live with.

Personally, if I was going to pay the price of requiring an 8-bit
channel, I wouldn't bother with [XYZ]MODEM, but instead just run SLIP
or PPP and get real networking, with multiple interactive sessions,
tried and true file transfer, mail, news, clock sync., graphics, etc.

		-- Paul Placeway <pplacewa@bbn.com>