Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!rutgers!gatech!hubcap!ncrcae!ncr-sd!hp-sdd!hplabs!cae780!daniels From: daniels@cae780.UUCP Newsgroups: comp.sys.ibm.pc Subject: Re: Sliding Window Kermit? (Summary) Message-ID: <3846@cae780.TEK.COM> Date: Thu, 30-Apr-87 13:31:11 EDT Article-I.D.: cae780.3846 Posted: Thu Apr 30 13:31:11 1987 Date-Received: Sat, 2-May-87 03:16:09 EDT References: <367@nis.NIS.MN.ORG> <450@uhccux.UUCP> <1093@super.upenn.edu.upenn.edu> <3367@jade.BERKELEY.EDU> <454@uhccux.UUCP> Reply-To: daniels@cae780.UUCP (Scott Daniels) Organization: Tektronix, Inc., Beaverton, OR. Lines: 24 Summary: Sliding window protocols have another advantage In article <454@uhccux.UUCP> yuan@uhccux.UUCP (Yuan Chang) summarizes: >From: humu!nosc!Ralf.Brown@b.gp.cs.cmu.edu >...advantage of Sliding Window is a large effective transmission block, >but a small retransmission required on corruption. >From: >...to be very useful, the receiver is usually allowed to group multiple ACKS Another advantage of such protocols is that they allow a "reasonable use" of a carrier such as a sequence of "store-and-forward" style machines. When sending a huge file on such a medium without a "Sliding Window", the two strategies that are normally used are: 1) dribble (send,wait for ack,loop). This can be orders of magnitude slower than required for data transmission, tunring a large file transfer into an overnight event. or 2) Balloon: (dump everything into the network and then wait for an ack) This can use up all of the storage on a network very quickly (imagine the receiving end is processing input very slowly). In the extreme version of this technique, the network becomes a storage device. SW allows a sort of "load balancing" by limiting the total amount of data in the network at any one time, but allowing continuous transmission if the recieving end is keeping up with the transmitter (and the number of packets in the window is large enough).