December 6, 1985 CHANGES TO THE KERMIT WINDOWING DEFINITION DECEMBER 6, 1985 DRAFT ["KWINDOW5.TXT] ---------------------- There is one change in the draft KERMIT WINDOWING PROTOCOL definition between the draft dated November 11, 1985 and the draft dated December 6, 1985. An additional heuristic is added to section 4.4 "Error Handling on Both Sides". Here is the additional text: *** TIMEOUT AVOIDANCE HEURISTIC Section added through An additional heuristic will prevent most timeouts due to lost stars ACKs or NAKs. The sender re-sends the earliest packet (the packet below blocking the window) if the following conditions are true: 1. The Sender's window is blocked. 2. The Retry Count for the earliest packet is zero. 3. An ACK (or optionally also NAK) for any later packet has been received. This heuristic takes advantage of the fact that ACKs and NAKs should normally be received in order. Receipt of a later ACK implies that the earliest ACK was lost. Therefore, we can anticipate that a timeout is likely to occur and avoid it by resending (once) the packet blocking the window. The packet is only sent once (i.e. if the retry count is zero) to avoid *** complicating error recovery. NOVEMBER 11, 1985 DRAFT ["KWINDOW4.TXT"] ----------------------- There are two changes in the draft KERMIT WINDOWING PROTOCOL definition between the draft dated July 19, 1985 and the draft dated November 11, 1985. (** in the left margin indicates text changed from July 19 version.) They are: A) In section "4.3 The Sender's Handling of Confirmations", "...When the sender receives a NAK, the table boundaries are checked. A NAK inside the table boundary indicates that the sender must re-send the packet. The sender first tests the packet's retry counter against the retry threshold. If the threshold has been reached, then the transfer is stopped (by going to the Abort state). Otherwise, the retry counter is incremented and the packet re-sent. ** A NAK outside of the table boundary causes the sender to send ** the earliest unACKed packet, or if all have been ACKed, the ** next packet. The retry counter is tested and incremented as ** above." COMMENT: This section previously said that a NAK outside the table boundaries would be ignored. This change was made to accomodate the timeout condition where the receiver is sending a NAK for WINDOW_HIGH +1 (the next packet) which can happen if an ACK is lost. This change handles the scenario where: 1) An ACK is lost 2) Sender's window is blocked 3) The Receiver times out and sends NAK for next packet 4) Sender gets NAK for packet not yet sent B) In section "5.3 Receiver User Interrupt", "... Whenever the receiver checks for input from the data communications line, it also should check for user input. If that indicates that the file transfer should be stopped, the receiver sets an "interrupt indication" of X (for "stop this file transfer") or of Z (for "stop the batch of file transfers"). When the receiver later sends an ACK, it places an X or Z in the data field. When the sender gets this ACK, it goes to the Send_Eof state and sends the End_of_File packet with the Discard indication, as above. ** The sequence number of the End_of_File packet is the (sequence ** number of the ACK with Discard) + 1. ..." COMMENT: The July 19 draft made no mention of what the sequence number of the EOF packet should be under this condition. This addition defines the EOF packet sequence number.