Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!rutgers!husc6!seismo!munnari!otc!metro!basser!uqcspe!miw From: miw@uqcspe.UUCP Newsgroups: comp.dcom.modems Subject: Re: SEA's Sliding Window XMODEM Message-ID: <1430@uqcspe.OZ> Date: Mon, 11-May-87 16:50:54 EDT Article-I.D.: uqcspe.1430 Posted: Mon May 11 16:50:54 1987 Date-Received: Sat, 16-May-87 15:18:38 EDT References: <144@lcuxa.UUCP> <2883@yale-celed.yale.UUCP> Reply-To: miw@uqcspe.UUCP (Mark Williams) Organization: Prentice Computer Centre, University of Queensland Lines: 59 Address: Prentice Computer Centre | |ACSNET: m.williams@uqkl10.decnet.uq.oz University of Queensland,| |ARPA: m.williams%uqkl10.decnet.uq.oz@seismo.css.gov St.Lucia, Qld, 4079 | |UUCP:.!seismo!munnari!uqkl10.decnet.uq.oz!m.williams Phone-No: +61 7 377 4079 -------- Couldn't get a reply through, so I am posting this article. If you know about sliding windows, then hit the junk key now. In Article <2883@yale-celed.yale.UUCP>, Jonathan Sweedler writes What does "sliding window" refer to? Why is it called this? Consider a simple ACK/NAK handshaking protocol. In this example, the sending device sends a packet/block/frame of data, and waits for an acknowledgement. The receiving device, on receiving the data, checks for errors using parity, CRC, Checksum, or whatever. If no error is detected, it sends back an ACK, or otherwise it sends a NAK. If the sender receives an ACK, it sends the next frame, if it receives a NAK it retransmits the last frame, and if it waits longer than a set timeout period without receiving either it also retransmits. It can be shown that if transmission delay is negligible, and the size of an ACK/NAK is small in comparison with the length of a data frame, then the handshaking overhead is not very great. The system starts to break down, however, when transmission delay becomes great, for example when a large number of intermediate switching nodes ar involved, or the physical channel is a sattelite link (round trip ~1/2 a second). In this situation, most of the time would be taken up with the sender waiting for the positive or negative acknowledgement. This is where sliding windows come in. The transmitting station numbers all its frames as it sends them, and maintains two variables. One is the number of the last frame for which a positive acknowledgement has been received, and the other is the number of the next frame to be sent. The Receiving station now includes the number of the frame it is acknowledging in its acknowledgement frames. The 'window', then, consists of those frames with numbers between the two numbers stored at the transmitting end. These frames are those frames sent but not acknowledged. The window size is the maximum number of frames which are allowed to be 'outstanding' at any time. This method saves waiting time, because the sender can wait the time required to send a windowfull of frames before an ACK is needed. There will be no wait due to transmission delay if the length of the window is greater than the transmission (round trip) delay. When an error is detected, there are two possibilities. The sender can go back and transmit the whole stream starting with the frame for which the NAK was received, (GO BACK N), or it can just retransmit the frame that got corrupted. (SELECTIVE REPEAT). The longer the transmission delay, the longer the window nneds to be, and the more advantage to use the latter method. IF you found this simplistic, it is. I do not intend this to teach one all about sliding window protocols. There are plenty of good books on the topic. All the same, hope this answers your question. Mark Williams --------