Category : C Source Code
Archive   : WKERMSRC.ZIP
Filename : KWCHANGE.DOC

 
Output of file : KWCHANGE.DOC contained in archive : WKERMSRC.ZIP

##################################################################
## KWCHANGE.DOC

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.



  3 Responses to “Category : C Source Code
Archive   : WKERMSRC.ZIP
Filename : KWCHANGE.DOC

  1. Very nice! Thank you for this wonderful archive. I wonder why I found it only now. Long live the BBS file archives!

  2. This is so awesome! 😀 I’d be cool if you could download an entire archive of this at once, though.

  3. But one thing that puzzles me is the “mtswslnkmcjklsdlsbdmMICROSOFT” string. There is an article about it here. It is definitely worth a read: http://www.os2museum.com/wp/mtswslnk/