Dec 132017
C Source code for "Sliding Windows" Kermit for most computers. W/docs.
File WKERMSRC.ZIP from The Programmer’s Corner in
Category C Source Code
C Source code for “Sliding Windows” Kermit for most computers. W/docs.
File Name File Size Zip Size Zip Type
AISC.H 9960 2686 deflated
ASIPORTS.H 12645 3879 deflated
CDISK.H 4891 1751 deflated
COMPILE.BAT 131 62 deflated
CSTDIO.H 2349 1012 deflated
CTYPE.H 2277 644 deflated
FNCTL.H 961 394 deflated
KWCHANGE.DOC 4278 1610 deflated
KWINDOW5.DOC 28093 7464 deflated
LCKCMD.H 1851 768 deflated
LCKDEB.H 2752 1181 deflated
LCKERM.H 3919 1459 deflated
LCKFIO.C 16958 5519 deflated
LCKFIO.DOC 4730 1267 deflated
LCKFNS1.C 31341 8879 deflated
LCKFNS2.C 13224 4385 deflated
LCKFNS3.C 12173 3717 deflated
LCKLINK.C 11012 3742 deflated
LCKMAIN.C 9048 3269 deflated
LCKMAIN.DOC 18833 5574 deflated
LCKPROT.C 14592 3060 deflated
LCKPROT.W 7518 2733 deflated
LCKTIO.C 16169 5098 deflated
LCKTIO.DOC 4809 1598 deflated
LCKUSER.C 24528 7394 deflated
LCKUSER.DOC 2984 1139 deflated
LCKUSR.H 4803 1794 deflated
LCKWART.ARF 126 45 deflated
LCKWART.C 14018 4572 deflated
LCKWART.DOC 4293 1785 deflated
PCKCOMP.BAT 598 168 deflated
PCKERMIT.ARF 219 107 deflated
PCKERMIT.DOC 40327 13490 deflated
PCKERMIT.MAP 25783 4673 deflated
PCKERMIT.UPD 1480 537 deflated
PCKLINK.BAT 106 41 deflated
SEN-REC.BAT 234 71 deflated
STDIOS.H 2246 851 deflated
TIMEDATE.H 775 337 deflated

Download File WKERMSRC.ZIP Here

Contents of the KWCHANGE.DOC file


December 6, 1985



There is one change in the draft KERMIT WINDOWING PROTOCOL definition
between the draft dated November 11, 1985 and the draft dated December 6,

An additional heuristic is added to section 4.4 "Error Handling on Both

Here is the additional text:

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.


There are two changes in the draft KERMIT WINDOWING PROTOCOL definition
between the draft dated July 19, 1985 and the draft dated November 11,

(** 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.

 December 13, 2017  Add comments

Leave a Reply