Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!wuarchive!zaphod.mps.ohio-state.edu!mips!wyse!bob
From: bob@wyse.wyse.com (Bob McGowen x4312 dept208)
Newsgroups: alt.sources.d
Subject: Re: v11i020: Idle demon
Message-ID: <2868@wyse.wyse.com>
Date: 24 Aug 90 02:43:24 GMT
References: <77@dlss2.UUCP> <1990Aug23.051212.24281@zorch.SF-Bay.ORG> <1990Aug23.143804.24954@ux1.cso.uiuc.edu>
Sender: news@wyse.wyse.com
Reply-To: bob@wyse.UUCP (Bob McGowen x4312 dept208)
Organization: Wyse Technology
Lines: 23

In article <1990Aug23.143804.24954@ux1.cso.uiuc.edu> peltz@cerl.uiuc.edu (Steve Peltz) writes:
>In article <1990Aug23.051212.24281@zorch.SF-Bay.ORG> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes:
>>                     ...  I'd be a little huffy about having my kermit
>>session killed in mid-download because I hadn't sent a keystroke in a
>
>But, but, kermit (and all other error-correcting download protocols) send in
		       ^^^

>keystrokes all the time!

If my understanding of "sliding window" protocols is correct, it IS possible
for a download to never (or seldom) have a response.  The basic idea is that
if an error has not occured, why spend the overhead to ack the packet.  So
a stream of packets flows until an error.  If no problems, then no input, so
line is idle and off we go in the middle of the transfer somewhere.

(The above is my deduction, not a quote so please be gentle in setting me
straight :-).  Thanks.)

Bob McGowan  (standard disclaimer, these are my own ...)
Product Support, Wyse Technology, San Jose, CA
..!uunet!wyse!bob
bob@wyse.com