home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / e / kproto.for < prev    next >
Text File  |  2020-01-01  |  248KB  |  4,389 lines

  1. 0
  2. 0
  3. 0
  4. 0
  5. 0
  6. 0
  7. 0
  8. 0
  9. 0
  10. 0                            KERMIT PROTOCOL MANUAL
  11. +                            KERMIT PROTOCOL MANUAL
  12. +                            KERMIT PROTOCOL MANUAL
  13. 0
  14.                                   _____ _______
  15. +                                 Sixth Edition
  16. 0
  17. 0                                 Frank da Cruz
  18. 0              Columbia University Center for Computing Activities
  19.                             New York, New York 10027
  20. 0
  21.                                     June 1986
  22. 0
  23. 0
  24. 0
  25.                              Copyright (C) 1981,1986
  26.              Trustees of Columbia University in the City of New York
  27. 0       __________ __ _______ __ ___ __________ __ ___________ __ ____ __
  28. +       Permission is granted to any individual or institution to copy or
  29.          ___ ____ ________ ___ ___ ________ _________ __ __  ______ ___
  30. +        use this document and the programs described in it, except for
  31.                          __________ __________ ________
  32. +                        explicitly commercial purposes.
  33. 1
  34. 0
  35.                           PREFACE TO THE SIXTH EDITION
  36. +                         PREFACE TO THE SIXTH EDITION
  37. +                         PREFACE TO THE SIXTH EDITION
  38. 0
  39.                                       ______ ________ ______
  40. +The sixth edition (June 1986) of the Kermit Protocol Manual is being issued for
  41.  two major reasons: to correct minor errors in the fifth edition, and to include
  42.  new  sections  on  two major protocol extensions: long packets and sliding win-
  43.  dows.  No attempt has been made to reorganize, rewrite,  or  otherwise  improve
  44.  the  protocol  manual.    The Kermit protocol has been presented in an entirely
  45.  different -- hopefully more thorough, organized, coherent, and useful  (if  not
  46.                                       ______  _ ____ ________ ________
  47. +more  formal) -- manner in the book, Kermit, A File Transfer Protocol, by Frank
  48.  da Cruz, Digital Press, Bedford MA (1986), ISBN 0-932376-88-6, DEC order number
  49.  EY-6705E-DP.    If  you have the book, you won't need this protocol manual.  On
  50.  the other hand, if you don't have the book, this manual  should  still  contain
  51.                                       ______ ________ ______
  52. +all  the necessary information.  The Kermit Protocol Manual will continue to be
  53.  freely distributed in perpetuity.
  54. 0The bare-bones C-language Kermit program that appeared as an appendix  in  pre-
  55.  vious editions has been removed.  It was not a particularly good example of how
  56.  to write a Kermit program, and made the manual unnecessarily thick.  For sample
  57.  Kermit  programs,  see  the  source  code for any of the hundreds of Kermit im-
  58.  plementations, or follow the program fragments in the book.
  59. 0
  60.                           PREFACE TO THE FIFTH EDITION
  61. +                         PREFACE TO THE FIFTH EDITION
  62. +                         PREFACE TO THE FIFTH EDITION
  63. 0
  64.  The fifth edition (March 1984) attempts to clarify some fine  points  that  had
  65.  been  left  ambiguous in the 4th edition, particularly with respect to when and
  66.  how prefix encoding is done, and when it is not, and  about  switching  between
  67.  block  check  types.   A mechanism is suggested (in the Attributes section) for
  68.  file archiving, and several attributes have been  rearranged  and  some  others
  69.  added  (this should do no harm, since no one to date has attempted to implement
  70.  the attributes packet).  A more complete protocol state table  is  provided,  a
  71.  few minor additions are made to the collection of packet types.
  72. 0
  73.                           PREFACE TO THE FOURTH EDITION
  74. +                         PREFACE TO THE FOURTH EDITION
  75. +                         PREFACE TO THE FOURTH EDITION
  76. 0
  77.  The  fourth  edition (November 1983) of the Kermit Protocol Manual incorporates
  78.  some new ideas that grew from our experience in attempting to implement some of
  79.  the features described in earlier editions, particularly user/server functions.
  80.  These include a mechanism to allow batch transfers to be interrupted gracefully
  81.  for  either the current file or the entire batch of files; a "capability mask";
  82.  a protocol extension for passing file attributes.  In addition, numbers are now
  83.  written  in  decimal  notation  rather  than octal, which was confusing to many
  84.  readers.  Also, several incompatible changes were made in minor areas where  no
  85.  attempts at an implementation had yet been made; these include:
  86. 0   - The format and interpretation of the operands to the server commands.
  87. 0   - Usurpation  of the reserved fields 10-11 of the Send-Init packet, and
  88. 1                                                                         Page 2
  89. 0
  90.       addition of new reserved fields.
  91. 0Most of the remaining material has been rewritten and reorganized, and much new
  92.  material  added, including a section on the recommended vocabulary for documen-
  93.  tation and commands.
  94. 0The previous edition of the Protocol Manual attempted to define "protocol  ver-
  95.  sion  3";  this  edition abandons that concept.  Since Kermit development is an
  96.  unorganized, disorderly, distributed enterprise, no requirement can be  imposed
  97.  on  Kermit  implementors  to include a certain set of capabilities in their im-
  98.  plementations.  Rather,  in  this  edition  we  attempt  to  define  the  basic
  99.  functionality of Kermit, and then describe various optional functions.
  100. 0The  key  principle  is  that any implementation of Kermit should work with any
  101.  other, no matter how advanced the one or how primitive the other.  The capabily
  102.  mask and other Send-Init fields attempt to promote this principle.
  103. 0
  104.                                  A FEW WORDS...
  105. +                                A FEW WORDS...
  106. +                                A FEW WORDS...
  107. 0
  108.  Before  deciding to write a new version of Kermit, please bear in mind that the
  109.  philosophy of Kermit has always been that is not, and never  should  become,  a
  110.  commercial  product, sold for profit.  Its goal is to promote communication and
  111.  sharing, and Kermit itself should be freely shared, and not sold.    Media  and
  112.  reproduction costs may be recouped if desired, but profit should not be the mo-
  113.  tive.  Vendors of commercial software, however, may request permission  to  in-
  114.  clude  Kermit  with, or in, their programs provided certain conditions are met,
  115.  including that credit for the protocol be given to Columbia and that the  price
  116.  of  the product not be raised substantially beyond media and reproduction costs
  117.  for inclusion of Kermit.  Contact the Kermit group at Columbia if you have  any
  118.  questions  about this.  Prospective Kermit implementors should check with us in
  119.  any case, to be sure that someone else has not already done, or started to  do,
  120.  the same thing you propose to do.
  121. 0Kermit  is  distributed  from  Columbia University on magnetic tape and certain
  122.  other media, and over various networks.  Write to  the  following  address  for
  123.  further information, including complete ordering instructions:
  124. 0
  125.      Kermit Distribution
  126.      Columbia University Center for Computing Activities
  127.      7th Floor, Watson Laboratory
  128.      612 West 115th Street
  129.      New York, NY  10025
  130. 1                                                                         Page 3
  131. 0
  132.                                 ACKNOWLEDGEMENTS
  133. +                               ACKNOWLEDGEMENTS
  134. +                               ACKNOWLEDGEMENTS
  135. 0
  136.  Bill  Catchings and I designed the basic Kermit protocol at Columbia University
  137.  in 1981.  For ideas, we looked at some of the ANSI models (X3.57,  X3.66),  the
  138.  ISO OSI model, some real-world "asynchronous protocols" (including the Stanford
  139.  Dialnet and TTYFTP projects, the University of Utah Small FTP project), as well
  140.  as at file transfer on full-blown networks like DECnet and ARPAnet.
  141. 0Bill  wrote  the  first  two  programs  to  implement the protocol, one for the
  142.  DEC-20, one for a CP/M-80 microcomputer, and in the process worked out most  of
  143.  the details and heuristics required for basic file transfer.  Meanwhile, Daphne
  144.  Tzoar and Vace Kundakci, also of Columbia, worked out  the  additional  details
  145.  necessary  for IBM mainframe communication, while writing IBM VM/CMS and PC-DOS
  146.  versions.
  147. 0Much credit should also go to Bernie Eiben of Digital Equipment Corporation for
  148.  promoting  widespread  use  of  Kermit and for adding many insights into how it
  149.  should operate, to Nick Bush and Bob McQueen of Stevens Institute  of  Technol-
  150.  ogy,  for  many  contributions to the "advanced" parts of the protocol, and for
  151.  several major Kermit implementations, and to Leslie Spira and her group at  The
  152.  Source  Telecomputing  for  adding full-duplex sliding window capability to the
  153.  Kermit protocol.
  154. 0Thanks to the many people all over the world who have  contributed  new  Kermit
  155.  implementations,  who have helped with Kermit distribution through various user
  156.  groups, and who have contributed to the quality of the protocol  and  its  many
  157.  implementations  by  reporting  or  fixing problems, criticizing the design, or
  158.  suggesting new features.  In particular, thanks to Ted Toal of Nevada City, CA,
  159.  for a detailed list of corrections to the fifth edition of this manual.
  160. 0The  Kermit  protocol  was  named after Kermit the Frog, star of the television
  161.  series THE MUPPET SHOW.  The name is used by permission of  Henson  Associates,
  162.  Inc., New York City.
  163. 0
  164.                                    DISCLAIMER
  165. +                                  DISCLAIMER
  166. +                                  DISCLAIMER
  167. 0
  168.  __  ________ __ ___ ________ ___ __ ___ ________ __ ___ _____________ ________
  169. +No  warranty of the software nor of the accuracy of the documentation surround-
  170.  ___ __ __ _________ __ _______  ___ _______ ___ _______ ___ ________ __________
  171. +ing it is expressed or implied, and neither the authors nor Columbia University
  172.  ___________ ___ _________ _________ ____ _______ __ _____________ ______
  173. +acknowledge any liability resulting from program or documentation errors.
  174. 1Introduction
  175. +Introduction
  176. +Introduction                                                             Page 4
  177. 0
  178.                                     CHAPTER 1
  179. +                                   CHAPTER 1
  180. +                                   CHAPTER 1
  181.                                   INTRODUCTION
  182. +                                 INTRODUCTION
  183. +                                 INTRODUCTION
  184. 0This manual describes the  Kermit  protocol.  It is assumed that you understand
  185.  the purpose and operation of the Kermit file transfer  facility,  described  in
  186.       ______  _____ _____
  187. +the  Kermit  Users Guide, and basic terminology of data communications and com-
  188.  puter programming.
  189. 0
  190.  1.1. Background
  191. +1.1. Background
  192. +1.1. Background
  193. 0The Kermit file transfer protocol is intended for use in an  environment  where
  194.  there  may  be  a  diverse  mixture of computers -- micros, personal computers,
  195.  workstations, laboratory computers, timesharing systems -- from  a  variety  of
  196.  manufacturers.    All  these systems need have in common is the ability to com-
  197.  municate in ASCII over ordinary serial telecommunication lines.
  198. 0Kermit was originally designed at Columbia University to meet the need for file
  199.  transfer  between  our  DECSYSTEM-20  and IBM 370-series mainframes and various
  200.  microcomputers.  It turned out that the diverse characteristics of these  three
  201.  kinds of systems resulted in a design that was general enough to fit almost any
  202.  system.  The IBM mainframe, in  particular,  strains  most  common  assumptions
  203.  about how computers communicate.
  204. 0
  205.  1.2. Overview
  206. +1.2. Overview
  207. +1.2. Overview
  208. 0The  Kermit  protocol is specifically designed for character-oriented transmis-
  209.  sion over serial telecommunication lines.  The design allows for  the  restric-
  210.  tions and peculiarities of the medium and the requirements of diverse operating
  211.  environments -- buffering, duplex, parity, character  set,  file  organization,
  212.  etc.   The protocol is carried out by Kermit programs on each end of the serial
  213.  connection sending "packets" back and forth; the sender sends file names,  file
  214.  contents,  and  control  information;  the receiver acknowledges (positively or
  215.  negatively) each packet.
  216. 0The packets have a layered design, more or less in keeping with  the  ANSI  and
  217.  ISO  philosophies,  with  the  outermost  fields used by the data link layer to
  218.  verify data integrity, the next by the session layer to verify continuity,  and
  219.  the data itself at the application level.
  220. 0Connections between systems are established by the ordinary user.  In a typical
  221.  case, the user runs Kermit on a microcomputer, enters terminal emulation,  con-
  222.  nects  to  a remote host computer (perhaps by dialing up), logs in, runs Kermit
  223.  on the remote host, and then issues commands to that Kermit  to  start  a  file
  224.  transfer,  "escapes"  back  to the micro, and issues commands to that Kermit to
  225.  start its side of the file transfer.  Files may be  transferred  singly  or  in
  226.  groups.
  227. 0                                                                     __________
  228. +Basic  Kermit  provides only file transfer, and that is provided for sequential
  229.  _____ ____
  230. +files only, though the protocol attempts to allow for various types of  sequen-
  231.  tial  files.    Microcomputer  implementations  of  Kermit are also expected to
  232. 1Introduction
  233. +Introduction
  234. +Introduction                                                             Page 5
  235. 0
  236.  provide terminal emulation, to facilitate the initial connection.
  237. 0More advanced implementations simplify the "user interface" somewhat by  allow-
  238.  ing  the  Kermit  on  the  remote host to run as a "server", which can transfer
  239.  files in either direction upon command from the local "user" Kermit.  The serv-
  240.  er  can  also  provide  additional functionality, such as file management, mes-
  241.  sages, mail, and so forth.  Other optional features  also  exist,  including  a
  242.  variety  of  block  check  types,  a mechanism for passing 8-bit data through a
  243.  7-bit communication link, a way to compressing a repeated sequence  of  charac-
  244.  ters, and so forth.
  245. 0As  local area networks become more popular, inexpensive, and standardized, the
  246.  demand for Kermit and similar protocols may dwindle, but will never wither away
  247.  entirely.   Unlike hardwired networks, Kermit gives the ordinary user the power
  248.                                                       ___  ___
  249. +to establish reliable error-free connections between any  two  computers;  this
  250.  may always be necessary for one-shot or long-haul connections.
  251. 1Definitions
  252. +Definitions
  253. +Definitions                                                              Page 6
  254. 0
  255.                                     CHAPTER 2
  256. +                                   CHAPTER 2
  257. +                                   CHAPTER 2
  258.                                    DEFINITIONS
  259. +                                  DEFINITIONS
  260. +                                  DEFINITIONS
  261. 0
  262.  2.1. General Terminology
  263. +2.1. General Terminology
  264. +2.1. General Terminology
  265. 0___
  266. +TTY:  This  is the term commonly used for a device which is connected to a com-
  267.  puter over an EIA RS-232 serial telecommunication line.  This  device  is  most
  268.  commonly  an  ASCII  terminal,  but  it  may be a microcomputer or even a large
  269.  multi-user computer emulating  an  ASCII  terminal.    Most  computers  provide
  270.  hardware (RS-232 connectors and UARTs) and software (device drivers) to support
  271.  TTY connections; this is what makes TTY-oriented file transfer  protocols  like
  272.  Kermit possible on almost any system at little or no cost.
  273. 0_____
  274. +LOCAL:  When two machines are connected, the LOCAL machine is the one which you
  275.  interact with directly, and which is in control of the terminal.    The  "local
  276.  Kermit"  is the one that runs on the local machine.  A local Kermit always com-
  277.  municates over an external device (the micro's communication port, an  assigned
  278.  TTY line, etc).
  279. 0______
  280. +REMOTE:  The REMOTE machine is the one on the far side of the connection, which
  281.  you must interact with "through" the local machine.  The "remote  Kermit"  runs
  282.  on  the  remote  machine.    A  remote Kermit usually communicates over its own
  283.  "console", "controlling terminal", or "standard i/o" device.
  284. 0____
  285. +HOST: Another word for "computer", usually meaning a computer that can  provide
  286.  a home for multiple users or applications.  This term should be avoided in Ker-
  287.  mit lore, unless preceded immediately by LOCAL or REMOTE, to denote which  host
  288.  is meant.
  289. 0______
  290. +SERVER:  An  implementation of remote Kermit that can accept commands in packet
  291.  form from a local Kermit program, instead of directly from the user.
  292. 0____
  293. +USER: In addition to its usual use to denote  the  person  using  a  system  or
  294.  program,  "user"  will also be used refer to the local Kermit program, when the
  295.  remote Kermit is a server.
  296. 0
  297.  2.2. Numbers
  298. +2.2. Numbers
  299. +2.2. Numbers
  300. 0    _______
  301. +All numbers in the following text are expressed in decimal (base  10)  notation
  302.  unless otherwise specified.
  303. 0Numbers  are  also  referred  to  in terms of their bit positions in a computer
  304.  word.  Since Kermit may be implemented on computers with various word sizes, we
  305.  start  numbering  the  bits from the "right" -- bit 0 is the least significant.
  306.  Bits 0-5 are the 6 least significant bits; if they were all  set  to  one,  the
  307.  value would be 63.
  308. 0A  special  quirk  in  terminology,  however, refers to the high order bit of a
  309.  character as it is transmitted on the communication line,  as  the  "8th  bit".
  310.  More  properly, it is bit 7, since we start counting from 0.  References to the
  311. 1Definitions
  312. +Definitions
  313. +Definitions                                                              Page 7
  314. 0
  315.  "8th bit" generally are with regard to that bit which ASCII  transmission  sets
  316.  aside  for  use  as a parity bit.  Kermit concerns itself with whether this bit
  317.  can be usurped for the transmission of data, and  if  not,  it  may  resort  to
  318.  "8th-bit prefixing".
  319. 0
  320.  2.3. Character Set
  321. +2.3. Character Set
  322. +2.3. Character Set
  323. 0     __________
  324. +All  characters  are in ASCII  (American national Standard Code for Information
  325.  Interchange) representation, ANSI standard X3.4-1968.  All  implementations  of
  326.  Kermit  transmit and receive characters only in ASCII.  The ASCII character set
  327.  is listed in Appendix III.
  328. 0_____ _________ __________
  329. +ASCII_character_mnemonics:
  330. 0NUL     Null, idle, ASCII character 0.
  331.  SOH     Start-of-header, ASCII character 1 (Control-A).
  332.  SP      Space, blank, ASCII 32.
  333.  CR      Carriage return, ASCII 13 (Control-M).
  334.  LF      Linefeed, ASCII 10 (Control-J).
  335.  CRLF    A carriage-return linefeed sequence.
  336.  DEL     Delete, rubout, ASCII 127.
  337. 0  _______ _________
  338. +A control_character is considered to be any byte whose low order 7 bits are  in
  339.  the  range 0 through 31, or equal to 127.  In this document, control characters
  340.  are written in several ways:
  341. 0Control-A
  342.          This  denotes  ASCII  character 1, commonly referred to as "Control-A".
  343.          Control-B is ASCII character 2, and so forth.
  344. 0CTRL-A  This is a common abbreviation for "Control-A".  A control character  is
  345.          generally  typed  at a computer terminal by holding down the key marked
  346.          CTRL and pressing the corresponding alphabetic character, in this  case
  347.          "A".
  348. 0^A      "Uparrow"  notation  for  CTRL-A.  Many computer systems "echo" control
  349.          characters in this fashion.
  350. 0  _________ _____ _________
  351. +A printable_ASCII_character is considered to be any character in the  range  32
  352.  (SP) through 126 (tilde).
  353. 0
  354.  2.4. Conversion Functions
  355. +2.4. Conversion Functions
  356. +2.4. Conversion Functions
  357. 0Several  conversion functions are useful in the description of the protocol and
  358.  in the program example.  The machine that Kermit runs on need operate  only  on
  359.  integer data; these are functions that operate upon the numeric value of single
  360.  ASCII characters.
  361. 0tochar(x) = x+32
  362.                                _
  363. +    Transforms  the  integer  x,  which is assumed to lie in the range 0 to 94,
  364. 1Definitions
  365. +Definitions
  366. +Definitions                                                              Page 8
  367. 0
  368.      into a printable ASCII character; 0 becomes SP, 1 becomes  "!",  3  becomes
  369.      "#", etc.
  370. 0unchar(x) = x-32
  371.                               _
  372. +    Transforms the character x, which is assumed to be in the  printable  range
  373.      (SP through tilde), into an integer in the range 0 to 94.
  374. 0ctl(x) = x XOR 64
  375.      Maps  between  control  characters  and  their  printable  representations,
  376.                                         _
  377. +    preserving the high-order bit.  If x is a control character, then
  378. 0        x = ctl(ctl(x))
  379. 0    that  is,  the same function is used to controllify and uncontrollify.  The
  380.      argument is assumed to be a true control character (0 to 31,  or  127),  or
  381.      the  result  of  applying  CTL to a true control character (i.e. 63 to 95).
  382.      The transformation is a mnemonic one -- ^A becomes A and vice versa.
  383. 0
  384.  2.5. Protocol Jargon
  385. +2.5. Protocol Jargon
  386. +2.5. Protocol Jargon
  387. 0  ______
  388. +A Packet is a clearly delimited string of  characters,  comprised  of  "control
  389.  fields" nested around data; the control fields allow a Kermit program to deter-
  390.  mine whether the data has been transmitted correctly and completely.  A  packet
  391.  is the unit of transmission in the Kermit protocol.
  392. 0___
  393. +ACK  stands  for "Acknowledge".  An ACK is a packet that is sent to acknowledge
  394.  receipt of another packet.  Not to be confused with the ASCII character ACK.
  395. 0___
  396. +NAK stands for "Negative Acknowledge".  A NAK is a packet sent to  say  that  a
  397.  corrupted  or incomplete packet was received, the wrong packet was received, or
  398.  an expected packet was not received.  Not to be confused with the ASCII charac-
  399.  ter NAK.
  400. 0   _______
  401. +A  timeout is an event that can occur if expected data does not arrive within a
  402.  specified amount of time.  The program generating the input request can  set  a
  403.  "timer  interrupt"  to  break  it out of a nonresponsive read, so that recovery
  404.  procedures may be activated.
  405. 1System Requirements
  406. +System Requirements
  407. +System Requirements                                                      Page 9
  408. 0
  409.                                     CHAPTER 3
  410. +                                   CHAPTER 3
  411. +                                   CHAPTER 3
  412.                                SYSTEM REQUIREMENTS
  413. +                              SYSTEM REQUIREMENTS
  414. +                              SYSTEM REQUIREMENTS
  415. 0The Kermit protocol requires that:
  416. 0   - The host can send and receive characters using 7- or 8-bit ASCII  en-
  417.       coding  over  an  EIA RS-232 physical connection, either hardwired or
  418.       dialup.
  419. 0   - All printable ASCII characters are acceptable as input  to  the  host
  420.                                              1
  421.       and  will not be transformed in any way .  Similarly, any intervening
  422.       network or communications equipment ("smart  modems",  TELENET,  ter-
  423.       minal concentrators, port selectors, etc) must not transform or swal-
  424.       low any printable ASCII characters.
  425. 0                    _______ _________
  426. +   - A single ASCII control character can pass  from  one  system  to  the
  427.       other  without  transformation.    This  character is used for packet
  428.       synchronization.  The character is normally Control-A (SOH, ASCII 1),
  429.       but can be redefined.
  430. 0   - If  a  host  requires a line terminator for terminal input, that ter-
  431.       minator must be a single ASCII control character, such as CR  or  LF,
  432.       distinct from the packet synchronization character.
  433. 0   - When using a job's controlling terminal for file transfer, the system
  434.       must allow the Kermit program to set the terminal  to  no  echo,  in-
  435.       finite  width  (no  "wraparound"  or  CRLF insertion by the operating
  436.       system), and no "formatting" of incoming or outgoing characters  (for
  437.       instance,  raising  lowercase letters to uppercase, transforming con-
  438.       trol characters to printable sequences, etc).  In short, the terminal
  439.       must  be  put in "binary" or "raw" mode, and, hopefully, restored af-
  440.       terwards to normal operation.
  441. 0   - The host's terminal input processor should be capable of receiving  a
  442.       single  burst  of 40 to 100 characters at normal transmission speeds.
  443.       This is the typical size of packet.
  444. 0Note that most of these requirements rule out the use  of  Kermit  through  IBM
  445.  3270  / ASCII protocol converters, except those (like the Series/1 or 7171 run-
  446.  ning the Yale ASCII package) that can be put in "transparant mode."
  447. 0            ___
  448. +Kermit does not require:
  449. 0
  450. 0_______________
  451. 0  1
  452.     If  they  are  translated  to another character set, like EBCDIC, the Kermit
  453.  program must  be  able  to  reconstruct  the  packet  as  it  appeared  on  the
  454.  communication line, before transformation.
  455. 1System Requirements
  456. +System Requirements
  457. +System Requirements                                                     Page 10
  458. 0
  459.     - That the connection run at any particular baud rate.
  460. 0   - That the system can do  XON/XOFF or any other kind of  flow  control.
  461.       System-  or hardware-level flow control can help, but it's not neces-
  462.       sary.  See section 5.7.
  463. 0   - That the system is capable of full duplex operation.  Any mixture  of
  464.       half and full duplex systems is supported.
  465. 0   - That  the  system  can  transmit or receive 8-bit bytes.  Kermit will
  466.       take advantage of 8-bit connections to send binary files; if an 8-bit
  467.       connection  is  not  possible, then binary files may be sent using an
  468.       optional prefix encoding.
  469. 1Printable Text versus Binary Data
  470. +Printable Text versus Binary Data
  471. +Printable Text versus Binary Data                                       Page 11
  472. 0
  473.                                     CHAPTER 4
  474. +                                   CHAPTER 4
  475. +                                   CHAPTER 4
  476.                         PRINTABLE TEXT VERSUS BINARY DATA
  477. +                       PRINTABLE TEXT VERSUS BINARY DATA
  478. +                       PRINTABLE TEXT VERSUS BINARY DATA
  479. 0For transmission between unlike systems, files must be assigned  to  either  of
  480.                  _________ ____    ______
  481. +two catagories: printable text or binary.
  482. 0A printable text file is one that can make sense on an unlike system -- a docu-
  483.  ment, program source, textual data, etc.  A binary file is one  that  will  not
  484.  (and probably can not) make sense on an unlike system -- an executable program,
  485.  numbers stored in internal format, etc.  On systems with 8-bit bytes, printable
  486.                                                                   2
  487.  ASCII files will have the high order bit of each byte set to zero  (since ASCII
  488.  is a 7-bit code) whereas binary files will use the high order bit of each  byte
  489.  for data, in which case its value can vary from byte to byte.
  490. 0Many  computers  have no way to distinguish a printable file from a binary file
  491.  -- especially one originating from an unlike system -- so the user may have  to
  492.  give  an explicit command to Kermit to tell it whether to perform these conver-
  493.  sions.
  494. 0
  495.  4.1. Printable Text Files
  496. +4.1. Printable Text Files
  497. +4.1. Printable Text Files
  498. 0A primary goal of Kermit is for printable text files to be useful on the target
  499.  system after transfer.  This requires a standard representation for text during
  500.  transmission.  Kermit's  standard  is  simple:  7-bit  ASCII  characters,  with
  501.  "logical records" (lines) delimited by CRLFs.  It is the responsibility of sys-
  502.  tems that do not store printable files in this fashion to perform the necessary
  503.  conversions  upon  input  and output.  For instance, IBM mainframes might strip
  504.  trailing blanks on output and add them back on input; UNIX would prepend  a  CR
  505.  to its normal record terminator, LF, upon output and discard it upon input.  In
  506.  addition, IBM mainframes must do EBCDIC/ASCII translation for text files.
  507. 0No other conversions (e.g. tab expansion) are performed upon text files.   This
  508.  representation  is  chosen  because  it  corresponds  to the way text files are
  509.  stored on most microcomputers and on many other systems.  In many common cases,
  510.  no transformations are necessary at all.
  511. 0
  512. 0
  513. 0
  514. 0
  515. 0_______________
  516. 0  2
  517.     There  are  some  exceptions,  such  as systems that store text files in so-
  518.  called "negative ASCII", or text files produced by word processors that use the
  519.  high order bit to indicate underline or boldface attributes.
  520. 1Printable Text versus Binary Data
  521. +Printable Text versus Binary Data
  522. +Printable Text versus Binary Data                                       Page 12
  523. 0
  524.  4.2. Binary Files
  525. +4.2. Binary Files
  526. +4.2. Binary Files
  527. 0Binary files are transmitted as though they were a sequence of characters.  The
  528.  difference from printable files is that the status of the  "8th  bit"  must  be
  529.  preserved.  When binary files are transmitted to an unlike system, the main ob-
  530.  jective is that they can be brought back to the original system  (or  one  like
  531.  it)  intact;  no special conversions should be done during transmission, except
  532.  to make the data fit the transmission medium.
  533. 0For binary files, eight bit character transmission is permissible  as  long  as
  534.  the  two  Kermit programs involved can control the value of the parity bit, and
  535.  no intervening communications equipment will change its value.  In  that  case,
  536.  the  8th  bit  of  a transmitted character will match that of the original data
  537.  byte, after any control-prefixing has been done.  When one or both sides cannot
  538.  control  the  parity  bit,  a  special  prefix  character  may  be inserted, as
  539.  described below.
  540. 0Systems that do not store binary data in 8-bit bytes, or whose word size is not
  541.  a  multiple  of 8, may make special provisions for "image mode" transfer of bi-
  542.  nary files.  This may be done within the basic protocol by having the two sides
  543.  implicitly  agree  upon  a  scheme  for packing the data into 7- or 8-bit ASCII
  544.  characters, or else the more flexible (but optional)  file  attributes  feature
  545.  may  be  used.    The  former method is used on PDP-10 36-bit word machines, in
  546.  which text is stored five 7-bit bytes per word; the value of the "odd  bit"  is
  547.  sent as the parity bit of every 5th word.
  548. 1File Transfer
  549. +File Transfer
  550. +File Transfer                                                           Page 13
  551. 0
  552.                                     CHAPTER 5
  553. +                                   CHAPTER 5
  554. +                                   CHAPTER 5
  555.                                   FILE TRANSFER
  556. +                                 FILE TRANSFER
  557. +                                 FILE TRANSFER
  558. 0                                              ___________
  559. +The file transfer protocol takes place over a transaction.  A transaction is an
  560.  exchange of packets beginning with a Send-Init (S) packet, and  ending  with  a
  561.                                            3
  562.  Break Transmission (B) or Error (E) packet , and may include  the  transfer  of
  563.  one  or more files, all in the same direction.  In order to minimize the unfor-
  564.  seen, Kermit packets do not contain any control characters except one specially
  565.  designated  to  mark  the beginning of a packet.  Except for the packet marker,
  566.  only printable characters are transmitted.    The  following  sequence  charac-
  567.                                           ______
  568. +terizes  basic  Kermit  operation;  the  sender  is the machine that is sending
  569.             ________
  570. +files; the receiver is the machine receiving the files.
  571. 0   1. The sender transmits a  Send-Initiate  (S)  packet  to  specify  its
  572.        parameters (packet length, timeout, etc; these are explained below).
  573. 0   2. The receiver sends an ACK (Y) packet, with its own parameters in the
  574.        data field.
  575. 0   3. The sender transmits a File-Header (F) packet,  which  contains  the
  576.        file's name in the data field.  The receiver ACKs the F packet, with
  577.        no data in the data field of the ACK (optionally, it may contain the
  578.        name under which the receiver will store the file).
  579. 0   4. The sender sends the contents of the file, in Data (D) packets.  Any
  580.        data not in the printable range is prefixed and replaced by a print-
  581.        able  equivalent.  Each D packet is acknowledged before the next one
  582.        is sent.
  583. 0   5. When all the file data has been sent, the sender  sends  an  End-Of-
  584.        File (Z) packet.  The receiver ACKs it.
  585. 0   6. If  there is another file to send, the process is repeated beginning
  586.        at step 3.
  587. 0   7. When no more files remain to be sent, the sender transmits  an  End-
  588.        Of-Transmission  (B)  packet.   The receiver ACKs it.  This ends the
  589.        transaction, and closes the logical connection (the physical connec-
  590.        tion remains open).
  591. 0                  ________ ______
  592. +Each packet has a sequence number, starting with 0 for the Send Init.  The ack-
  593.  nowledgment (ACK or NAK) for a packet has the same packet number as the  packet
  594.  being acknowledged.  Once an acknowledgment is successfully received the packet
  595.  number is increased by one, modulo 64.
  596. 0
  597.  _______________
  598. 0  3
  599.     A  transaction  should  also  be  considered terminated when one side or the
  600.  other has stopped without sending an Error packet.
  601. 1File Transfer
  602. +File Transfer
  603. +File Transfer                                                           Page 14
  604. 0
  605.  If the sender is remote, it waits for a certain amount of  time  (somewhere  in
  606.  the 5-30 second range) before transmitting the Send-Init, to give the user time
  607.  to escape back to the local Kermit and tell it to receive files.
  608. 0Each transaction starts fresh, as if no previous transaction had  taken  place.
  609.  For  example, the sequence number is set back to zero, and parameters are reset
  610.  to their default or user-selected values.
  611. 0
  612.  5.1. Conditioning the Terminal
  613. +5.1. Conditioning the Terminal
  614. +5.1. Conditioning the Terminal
  615. 0Kermit is most commonly run with the user sitting at a microcomputer, connected
  616.  through  a communications port to a remote timesharing system.  The remote Ker-
  617.  mit is using its job's own "controlling terminal" for file transfer.  While the
  618.  microcomputer's  port  is  an  ordinary device, a timesharing job's controlling
  619.  terminal is a special one, and often performs many services that  would  inter-
  620.  fere  with  normal operation of Kermit.  Such services include echoing (on full
  621.  duplex systems), wrapping lines by inserting carriage return linefeed sequences
  622.  at  the  terminal  width,  pausing at the end of a screen or page full of text,
  623.  displaying system messages, alphabetic case conversion, control  character  in-
  624.  tepretation,  and  so  forth.   Mainframe Kermit programs should be prepared to
  625.  disable as many of these  services  as  possible  before  packet  communication
  626.  begins,  and to restore them to their original condition at the end of a trans-
  627.  action.  Disabling these services is usually known as "putting the terminal  in
  628.  binary mode."
  629. 0Kermit's  use  of  printable  control  character  equivalents,  variable packet
  630.  lengths, redefinable markers and prefixes, and allowance for any characters  at
  631.  all  to  appear between packets with no adverse effects provide a great deal of
  632.  adaptability for those systems that do not allow certain (or any) of these fea-
  633.  tures to be disabled.
  634. 0
  635.  5.2. Timeouts, NAKs, and Retries
  636. +5.2. Timeouts, NAKs, and Retries
  637. +5.2. Timeouts, NAKs, and Retries
  638. 0If  a Kermit program is capable of setting a timer interrupt, or setting a time
  639.  limit on an input request, it should do so whenever attempting to read a packet
  640.  from the communication line, whether sending or receiving files.  Having read a
  641.  packet, it should turn off the timer.
  642. 0If the sender times out waiting for an acknowledgement, it should send the same
  643.  packet  again,  repeating  the  process a certain number of times up to a retry
  644.  limit, or until an acknowledgement is received.   If  the  receiver  times  out
  645.  waiting  for  a packet, it can send either a NAK packet for the expected packet
  646.  or another ACK for the last packet it got.  The latter is preferred.
  647. 0If a packet from the sender is garbled or lost in transmission (the  latter  is
  648.  detected  by a timeout, the former by a bad checksum), the receiver sends a NAK
  649.  for the garbled or missing packet.  If an ACK or a NAK  from  the  receiver  is
  650.  garbled  or  lost,  the  sender ignores it; in that case, one side or the other
  651.  will time out and retransmit.
  652. 1File Transfer
  653. +File Transfer
  654. +File Transfer                                                           Page 15
  655. 0
  656.  A retry count is maintained, and there  is  a  retry  threshold,  normally  set
  657.  around  5.   Whenever a packet is resent -- because of a timeout, or because it
  658.  was NAK'd -- the counter is incremented.  When it reaches  the  threshold,  the
  659.  transaction is terminated and the counter reset.
  660. 0If  neither  side  is capable of timing out, a facility for manual intervention
  661.  must be available on the local Kermit.  Typically, this will work  by  sampling
  662.  the  keyboard (console) periodically; if input, such as a CR, appears, then the
  663.  same action is taken as if a timeout had occurred.  The local  Kermit  keeps  a
  664.  running  display  of the packet number or byte count on the screen to allow the
  665.  user to detect when traffic has stopped.  At this  point,  manual  intervention
  666.  should break the deadlock.
  667. 0Shared  systems which can become sluggish when heavily used should adjust their
  668.  own timeout intervals on a per-packet basis, based on the system load, so  that
  669.  file transfers won't fail simply because the system was too slow.
  670. 0Normally,  only one side should be doing timeouts, preferably the side with the
  671.  greatest knowledge of the "environment" --  system  load,  baud  rate,  and  so
  672.  forth, so as to optimally adjust the timeout interval for each packet.  If both
  673.  sides are timing out, their intervals should differ  sufficiently  to  minimize
  674.  collisions.
  675. 0
  676.  5.3. Errors
  677. +5.3. Errors
  678. +5.3. Errors
  679. 0During file transfer, the sender may encounter an i/o error on the disk, or the
  680.  receiver may attempt to write to a full or write-protected device.    Any  con-
  681.  dition that will prevent successful transmission of the file is called a "fatal
  682.  error".  Fatal errors should be detected, and the  transfer  shut  down  grace-
  683.  fully,  with  the  pertinent  information  provided to the user.  Error packets
  684.  provide a mechanism to do this.
  685. 0If a fatal error takes place on either the sending or receiving side, the  side
  686.  which encountered the error should send an Error (E) packet.  The E packet con-
  687.  tains a brief textual error message in the data field.   Both  the  sender  and
  688.  receiver  should  be prepared to receive an Error packet at any time during the
  689.  transaction.  Both the sender and receiver of the Error packet should halt,  or
  690.  go  back  into into user command mode (a server should return to server command
  691.  wait).  The side that is local should print the error message on the screen.
  692. 0There is no provision for sending nonfatal error messages, warnings, or  infor-
  693.  mation  messages during a transaction.  It would be possible to add such a fea-
  694.  ture, but this would require both sides agree to use it through  setting  of  a
  695.  bit  in the capability mask, since older Kermits that did not know about such a
  696.  feature would encounter an unexpected packet type and would enter the fatal er-
  697.  ror  state.   In any case, the utility of such a feature is questionable, since
  698.  there is no guarantee that the user will be present to see such messages at the
  699.  time  they  are sent; even if they are saved up for later perusal in a "message
  700.  box", their significance may be long past by the time the user reads them.  See
  701.  the section on Robustness, below.
  702. 1File Transfer
  703. +File Transfer
  704. +File Transfer                                                           Page 16
  705. 0
  706.  5.4. Heuristics
  707. +5.4. Heuristics
  708. +5.4. Heuristics
  709. 0During any transaction, several heuristics are useful:
  710. 0   1. A  NAK  for  the current packet is equivalent to an ACK for the pre-
  711.        vious packet (modulo 64).  This  handles  the  common  situation  in
  712.        which a packet is successfully received, and then ACK'd, but the ACK
  713.        is lost.  The ACKing side then times out waiting for the next packet
  714.                                                                   _ _
  715. +      and  NAKs  it.    The  side that receives a NAK for packet n+1 while
  716.                                      _                     _ _
  717. +      waiting for an ACK for packet n simply sends packet n+1.
  718. 0                _
  719. +   2. If packet n arrives more than once, simply ACK it  and  discard  it.
  720.        This  can  happen when the first ACK was lost.  Resending the ACK is
  721.                  ___
  722. +      necessary and sufficient -- don't write the packet out to  the  file
  723.        again!
  724. 0   3. When  opening a connection, discard the contents of the line's input
  725.        buffer before reading or sending the first packet.   This  is  espe-
  726.        cially  important if the other side is in receive mode (or acting as
  727.        a server), in which case it may have been sending out periodic  NAKs
  728.        for  your  expected  SEND-INIT  or  command packet.  If you don't do
  729.        this, you may find that there are sufficient  NAKs  to  prevent  the
  730.        transfer -- you send a Send-Init, read the response, which is an old
  731.        NAK, so you send another Send-Init, read the next old  NAK,  and  so
  732.        forth, up to the retransmission limit, and give up before getting to
  733.        the ACKs that are waiting in line behind all the old NAKs.   If  the
  734.        number  of  NAKs is below the cutoff, then each packet may be trans-
  735.        mitted multiply.
  736. 0   4. Similarly, before sending a packet, you should clear the input buff-
  737.        er (after looking for any required handshake character).  Failure to
  738.        clear the buffer could result in propogation of the repetition of  a
  739.        packet caused by stacked-up NAKs.
  740. 0   5. If  an  ACK arrives for a packet that has already been ACK'd, simply
  741.        ignore the redundant ACK and wait for the next ACK, which should  be
  742.        on its way.
  743. 0
  744.  5.5. File Names
  745. +5.5. File Names
  746. +5.5. File Names
  747. 0The  syntax  for  file  names  can vary widely from system to system.  To avoid
  748.  problems, it is suggested that filenames be represented in the File Header  (F)
  749.  packet  in  a  "normal form", by default (that is, there should be an option to
  750.  override such conversions).
  751. 0   1. Delete all pathnames and attributes  from  the  file  specification.
  752.        The file header packet should not contain directory or device names;
  753.        if it does, it may cause the recipient to try to store the  file  in
  754.        an  inaccessible  or  nonexistent  area,  or it may result in a very
  755.        strange filename.
  756. 1File Transfer
  757. +File Transfer
  758. +File Transfer                                                           Page 17
  759. 0
  760.     2. After stripping any pathname, convert  the  remainder  of  the  file
  761.                                   ____ ____
  762. +      specification to the form "name.type", with no restriction on length
  763.        (except that it fit in the data field of the F packet), and:
  764. 0         a. Include no more than one dot.
  765.           b. Not begin or end with a dot.
  766.                  ____     ____
  767. +         c. The name and type fields contain digits and uppercase letters.
  768. 0Special characters like "$", "_", "-", "&", and so forth should be  disallowed,
  769.  since they're sure to cause problems on one system or another.
  770. 0The  recipient, of course, cannot depend upon the sender to follow this conven-
  771.  tion, and should still take precautions.  However, since most file systems  em-
  772.  body  the  notion  of  a  file name and a file type, this convention will allow
  773.  these items to be expressed in a way that an unlike system can understand.  The
  774.  particular notation is chosen simply because it is the most common.
  775. 0The  recipient  must  worry about the length of the name and type fields of the
  776.  file name.  If either is too long, they must  be  truncated.    If  the  result
  777.  (whether  truncated  or not) is the same as the name of a file that already ex-
  778.  ists in the same area, the recipient should have the ability to take some  spe-
  779.  cial action to avoid writing over the original file.
  780. 0Kermit  implementations  that  convert  file  specifications  to normal form by
  781.  default should have an option to override this feature.   This  would  be  most
  782.  useful  when  transferring files between like systems, perhaps used in conjunc-
  783.  tion with "image mode" file transfer.  This could allow, for instance, one UNIX
  784.  system to send an entire directory tree to another UNIX system.
  785. 0
  786.  5.6. Robustness
  787. +5.6. Robustness
  788. +5.6. Robustness
  789. 0A  major  feature  of  the  Kermit protocol is the ability to transfer multiple
  790.  files.  Whether a particular Kermit program can actually  send  multiple  files
  791.  depends  on  the capabilities of the program and the host operating system (any
  792.  Kermit program can receive multiple files).
  793. 0If a Kermit program can send multiple files, it should make  every  attempt  to
  794.  send  the  entire  group  specified.  If it fails to send a particular file, it
  795.  should not terminate the entire batch, but should go on the the next  one,  and
  796.  proceed until an attempt has been made to send each file in the group.
  797. 0Operating  in  this  robust  manner, however, gives rise to a problem: the user
  798.  must be notified of a failure to send any particular file.   Unfortunately,  it
  799.  is  not  sufficient  to print a message to the screen since the user may not be
  800.  physically present.  A better solution would be to have the  sender  optionally
  801.  keep  a  log of the  transaction, giving the name of each file for which an at-
  802.  tempt was made, and stating whether the attempt was successful, and if not, the
  803.  reason.    Additional aids to robustness are described in the Optional Features
  804.  section, below.
  805. 1File Transfer
  806. +File Transfer
  807. +File Transfer                                                           Page 18
  808. 0
  809.  5.7. Flow Control
  810. +5.7. Flow Control
  811. +5.7. Flow Control
  812. 0On full duplex connections, XON/XOFF flow control can generally be used in con-
  813.  junction  with Kermit file transfer with no ill effects.  This is because XOFFs
  814.  are sent in the opposite direction of packet flow, so they will  not  interfere
  815.  with  the  packets themselves.  XON/XOFF, therefore, need not be implemented by
  816.  the Kermit program, but can done by the  host  system.    If  the  host  system
  817.  provides  this  capability,  it  should  be  used  -- if both sides can respond
  818.  XON/XOFF  signals,  then  buffer  overruns  and  the  resulting  costly  packet
  819.  retransmissions can be avoided.
  820. 0Beware,  however, of the following situation: remote Kermit is sending periodic
  821.  NAKs, local system is buffering them on the operating system level (because the
  822.  user has not started the local end of the file transfer yet); local line buffer
  823.  becomes full, local systems sends XOFF, remote starts buffering them up on  its
  824.  end,  user  finally  starts  file  transfer  on local end, clears buffer, local
  825.  operating system sends XON, and then all the remotely buffered  NAKs  show  up,
  826.  causing  the  packet echoing problem described above, despite the buffer clear-
  827.  ing.
  828. 0Flow control via modem signals can also be used when available.
  829. 0Note that flow control  should  not  be  confused  with  "handshake"  or  "line
  830.  turnaround"  techniques  that  are used on simplex or half-duplex communication
  831.  lines.  In fact, the two techniques are mutually exclusive.
  832. 0
  833.  5.8. Basic Kermit Protocol State Table
  834. +5.8. Basic Kermit Protocol State Table
  835. +5.8. Basic Kermit Protocol State Table
  836. 0The Kermit protocol can be described as a set of states  and  transitions,  and
  837.  rules  for  what  to do when changing from one state to another.  State changes
  838.  occur based on the type of packets that are sent or received,  or  errors  that
  839.  may occur.  Packets always go back and forth; the sender of a file always sends
  840.  data packets of some kind (init, header, data) and the receiver always  returns
  841.  ACK or NAK packets.
  842. 0Upon  entering  a given state, a certain kind of packet is either being sent or
  843.  is expected to arrive -- this is shown on top of the description of that state.
  844.  As  a result of the action, various responses may occur; these are shown in the
  845.  EVENT column.  For each event, an appropriate ACTION is taken, and the protocol
  846.  enters a NEW STATE.
  847. 0The  following table specifies basic Kermit operation.  Timeouts and error con-
  848.  ditions have been omitted from the following table for simplicity, but the  ac-
  849.  tion is as described above.  Server operation and some of the advanced features
  850.  are also omitted.  A full-blown state table is given subsequently.
  851. 1File Transfer
  852. +File Transfer
  853. +File Transfer                                                           Page 19
  854. 0
  855.      _____   _____           ______                      ___ _____
  856. +    STATE   EVENT           ACTION                      NEW_STATE
  857. 0            ____ ______
  858. +         -- SEND STATES --
  859. 0    ____ ____ ____ ______
  860. +    Send Send-Init Packet:
  861.      S       Get NAK,bad ACK (None)                          S
  862.              Get good ACK    Set remote's params, open file  SF
  863.              (Other)         (None)                          A
  864. 0    ____ ____ ______ ______
  865. +    Send File-Header Packet
  866.      SF      Get NAK,bad ACK (None)                          SF
  867.              Get good ACK    Get bufferful of file data      SD
  868.              (Other)         (None)                          A
  869. 0    ____ ____ ____ ______
  870. +    Send File-Data Packet
  871.      SD      Get NAK,bad ACK (None)                          SD
  872.              Get good ACK    Get bufferful of file data      SD
  873.              (End of file)   (None)                          SZ
  874.              (Other)         (None)                          A
  875. 0    ____ ___ ______
  876. +    Send EOF Packet
  877.      SZ      Get NAK,bad ACK (None)                          SZ
  878.              Get good ACK    Get next file to send           SF
  879.              (No more files) (None)                          SB
  880.              (Other)         (None)                          A
  881. 0    ____ _____  ___  ______
  882. +    Send Break (EOT) Packet
  883.      SB      Get NAK,bad ACK (None)                          SB
  884.              Get good ACK    (None)                          C
  885.              (Other)         (None)                          A
  886. 0            _______ ______
  887. +         -- RECEIVE STATES --
  888. 0    ____ ___ ____ ____ ______
  889. +    Wait for Send-Init Packet
  890.      R       Get Send-Init   ACK w/local params              RF
  891.              (Other)         (None)                          A
  892. 0    ____ ___ ____ ______ ______
  893. +    Wait for File-Header Packet
  894.      RF      Get Send-Init   ACK w/local params
  895.                               (previous ACK was lost)        RF
  896.              Get Send-EOF    ACK (prev ACK lost)             RF
  897.              Get Break       ACK                             C
  898.              Get File-Header Open file, ACK                  RD
  899.              (Other)         (None)                          A
  900. 0    ____ ___ ____ ____ ______
  901. +    Wait for File-Data Packet
  902.      RD      Get previous
  903.               packet(D,F)    ACK it again                    RD
  904.              Get EOF         ACK it, close the file          RF
  905.              Get good data   Write to file, ACK              RD
  906.              (Other)         (None)                          A
  907. 1File Transfer
  908. +File Transfer
  909. +File Transfer                                                           Page 20
  910. 0
  911.              ______ ______ __ _______ ___ _________
  912. +         -- STATES COMMON TO SENDING AND RECEIVING --
  913. 0    C       (Send Complete)                                 start
  914.      A       ("Abort")                                       start
  915. 1Packet Format
  916. +Packet Format
  917. +Packet Format                                                           Page 21
  918. 0
  919.                                     CHAPTER 6
  920. +                                   CHAPTER 6
  921. +                                   CHAPTER 6
  922.                                   PACKET FORMAT
  923. +                                 PACKET FORMAT
  924. +                                 PACKET FORMAT
  925. 0
  926.  6.1. Fields
  927. +6.1. Fields
  928. +6.1. Fields
  929. 0The Kermit protocol is built around exchange of packets of the  following  for-
  930.  mat:
  931. 0    +------+-------------+-------------+------+------------+-------+
  932.      | MARK | tochar(LEN) | tochar(SEQ) | TYPE |    DATA    | CHECK |
  933.      +------+-------------+-------------+------+------------+-------+
  934. 0where all fields consist of ASCII characters.  The fields are:
  935. 0____
  936. +MARK    The  synchronization  character that marks the beginning of the packet.
  937.          This should normally be CTRL-A, but may be redefined.
  938. 0___
  939. +LEN     The number of ASCII characters  within  the  packet  that  follow  this
  940.          field,  in  other words the packet length minus two.  Since this number
  941.          is transformed to a single character via the tochar() function,  packet
  942.          character  counts  of 0 to 94 (decimal) are permitted, and 96 (decimal)
  943.          is the maximum total packet length.  The length does not  include  end-
  944.          of-line  or  padding  characters,  which are outside the packet and are
  945.          strictly for the benefit of  the  operating  system  or  communications
  946.          equipment, but it does include the block check characters.
  947. 0___
  948. +SEQ     The  packet sequence number, modulo 64, ranging from 0 to 63.  Sequence
  949.          numbers "wrap around" to 0 after each group of 64 packets.
  950. 0____
  951. +TYPE    The packet type, a single ASCII character.  The following packet  types
  952.          are required:
  953. 0        D   Data packet
  954.          Y   Acknowledge (ACK)
  955.          N   Negative acknowledge (NAK)
  956.          S   Send initiate (exchange parameters)
  957.          B   Break transmission (EOT)
  958.          F   File header
  959.          Z   End of file (EOF)
  960.          E   Error
  961.              ________ ___ ________ ___
  962. +        Q   Reserved for internal use
  963.              ________ ___ ________ ___
  964. +        T   Reserved for internal use
  965. 0        The  NAK  packet  is used only to indicate that the expected packet was
  966.          not received correctly, never to supply  other  kinds  of  information,
  967.                                                                           ______
  968. +        such  as refusal to perform a requested service.  The NAK packet always
  969.          has an empty data field.  The T "packet" is  used  internally  by  many
  970.          Kermit programs to indicate that a timeout occurred.
  971. 0____
  972. +DATA    The "contents" of the packet, if any contents are required in the given
  973.          type of packet, interpreted according to  the  packet  type.    Control
  974. 1Packet Format
  975. +Packet Format
  976. +Packet Format                                                           Page 22
  977. 0
  978.          characters (bytes whose low order 7 bits are in the ASCII control range
  979.          0-31, or 127) are preceded by a special prefix character, normally "#",
  980.          and "uncontrollified" via ctl().  A prefixed sequence may not be broken
  981.          across packets.  Logical records in printable files are delimited  with
  982.          CRLFs,  suitably prefixed (e.g. "#M#J").  Logical records need not cor-
  983.          respond to packets.  Any prefix characters are included in  the  count.
  984.          Optional  encoding  for 8-bit data and repeated characters is described
  985.          later.  The data fields of all packets are subject to prefix  encoding,
  986.          ______
  987. +        except  the  S, I, and A packets and their acknowledgements, which must
  988.          ___
  989. +        not be encoded.
  990. 0_____
  991. +CHECK   A block check on the characters in the packet between, but not  includ-
  992.          ing, the mark and the block check itself.  The check for each packet is
  993.          computed by both hosts, and must agree if a packet is to  be  accepted.
  994.          A single-character arithmetic checksum is the normal and required block
  995.          check.  Only six bits of the arithmetic sum are  included.    In  order
  996.          that  all  the bits of each data character contribute to this quantity,
  997.          bits 6 and 7 of the final value are added to  the  quantity  formed  by
  998.                                 _
  999. +        bits  0-5.    Thus  if s is the arithmetic sum of the ASCII characters,
  1000.          then 
  1001. 0            _____           _     _
  1002. +            check = tochar((s + ((s AND 192)/64)) AND 63)
  1003. 0        This is the default block check, and all Kermits  must  be  capable  of
  1004.          performing it.  Other optional block check types are described later.
  1005. 0        The  block  check is based on the ASCII values of all the characters in
  1006.          the packet, including control fields and prefix characters.   Non-ASCII
  1007.          systems  must translate to ASCII before performing the block check cal-
  1008.          culation.
  1009. 0
  1010.  6.2. Terminator
  1011. +6.2. Terminator
  1012. +6.2. Terminator
  1013. 0Any line terminator that is required by the  system  may  be  appended  to  the
  1014.  packet;  this  is  carriage return (ASCII 15) by default.  Line terminators are
  1015.  not considered part of the packet, and are not included in the count or  check-
  1016.  sum.    Terminators are not necessary to the protocol, and are invisible to it,
  1017.  as are any characters that may appear between packets.  If  a  host  cannot  do
  1018.  single character input from a TTY line, then a terminator will be required when
  1019.  sending to that host.  The terminator can be specified in the  initial  connec-
  1020.  tion exchange.
  1021. 0Some  Kermit  implementations  also  use  the  terminator for another reason --
  1022.  speed.  Some systems are not fast enough to take in  a  packet  and  decode  it
  1023.  character  by  character at high baud rates; by blindly reading and storing all
  1024.  characters between the MARK and the EOL, they are able to absorb  the  incoming
  1025.  characters at full speed and then process them at their own rate.
  1026. 1Packet Format
  1027. +Packet Format
  1028. +Packet Format                                                           Page 23
  1029. 0
  1030.  6.3. Other Interpacket Data
  1031. +6.3. Other Interpacket Data
  1032. +6.3. Other Interpacket Data
  1033. 0The  space  between  packets  may be used for any desired purpose.  Handshaking
  1034.  characters may be necessary on certain connections, others may  require  screen
  1035.  control or other sequences to keep the packets flowing.
  1036. 0
  1037.  6.4. Encoding, Prefixing, Block Check
  1038. +6.4. Encoding, Prefixing, Block Check
  1039. +6.4. Encoding, Prefixing, Block Check
  1040. 0                                     _______ ______
  1041. +MARK,  LEN, SEQ, TYPE, and CHECK are control fields.  Control fields are always
  1042.  literal single-character fields, except that the CHECK field may be extended by
  1043.  one  or  two  additional  check  characters.   Each control field is encoded by
  1044.  tochar() or taken literally, but never prefixed.  The control fields never con-
  1045.  tain 8-bit data.
  1046. 0The  DATA  field  contains  a  string  of  data characters in which any control
  1047.  characters are encoded printably and preceded with the  control  prefix.    The
  1048.  decision to prefix a character in this way depends upon whether its low order 7
  1049.  bits are in the ASCII control range, i.e. 0-31 or 127.  Prefix characters  that
  1050.  appear  in  the data must themselves be prefixed by the control prefix, but un-
  1051.  like control characters, these retain their literal value in the packet.    The
  1052.  character  to  be  prefixed is considered a prefix character if its low-order 7
  1053.  bits corresponds  to  an  active  prefix  character,  such  as  #  (ASCII  35),
  1054.  __________ __ ___ _______ __ ___ ____ _____ ___
  1055. +regardless of the setting of its high-order bit.
  1056. 0During  decoding,  any character that follows the control prefix, but is not in
  1057.  the control range, is taken literally.  Thus, it  does  no  harm  to  prefix  a
  1058.  printable  character,  even  if  that character does not happen to be an active
  1059.  prefix.
  1060. 0The treatment of the high order ("8th") bit of a data byte is as follows:
  1061. 0   - If the communication channel allows 8 data bits per  character,  then
  1062.       the original value of the 8th bit is retained in the prefixed charac-
  1063.       ter.  For instance, a data byte corresponding to a Control-A with the
  1064.       8th  bit set would be send as a control prefix, normally "#", without
  1065.                                            ____
  1066. +     the 8th bit set, followed by ctl(^A) with the 8th bit set.  In binary
  1067.       notation, this would be 
  1068. 0         00100011 11000001
  1069. 0     In  this  case,  the 8th bit is figured into all block check calcula-
  1070.       tions.
  1071. 0   - If the communication channel or one of the hosts requires  parity  on
  1072.       each character, and both sides are capable of 8th-bit prefixing, then
  1073.                                                     ___
  1074. +     the 8th bit will be used for parity, and must not be included in  the
  1075.       block  check.    8th  bit prefixing is an option feature described in
  1076.       greater detail in Section 8, below.
  1077. 0                                                      ___
  1078. +   - If parity is being used but 8th-bit prefixing is not being done, then
  1079.       the  value  of  the 8th bit of each data byte will be lost and binary
  1080. 1Packet Format
  1081. +Packet Format
  1082. +Packet Format                                                           Page 24
  1083. 0
  1084.       files will not be transmitted correctly.  Again, the 8th bit does not
  1085.       figure into the block check.
  1086. 0                                                               ______
  1087. +The data fields of all packets are subject to prefix encoding, except S, I, and
  1088.  A packets, and the ACKs to those packets (see below).
  1089. 1Initial Connection
  1090. +Initial Connection
  1091. +Initial Connection                                                      Page 25
  1092. 0
  1093.                                     CHAPTER 7
  1094. +                                   CHAPTER 7
  1095. +                                   CHAPTER 7
  1096.                                INITIAL CONNECTION
  1097. +                              INITIAL CONNECTION
  1098. +                              INITIAL CONNECTION
  1099. 0Initial connection occurs when the user has started up a Kermit program on both
  1100.  ends  of  the physical connection.  One Kermit has been directed (in one way or
  1101.  another) to send a file, and the other to receive it.
  1102. 0The receiving Kermit waits for a "Send-Init" packet from  the  sending  Kermit.
  1103.  It  doesn't  matter  whether  the sending Kermit is started before or after the
  1104.  receiving Kermit (if before,  the  Send-Init  packet  should  be  retransmitted
  1105.  periodically  until  the  receiving Kermit acknowledges it).  The data field of
  1106.  the Send-Init packet is optional; trailing  fields  can  be  omitted  (or  left
  1107.  blank, i.e. contain a space) to accept or specify default values.
  1108. 0The Send-Init packet contains a string of configuration information in its data
  1109.  field.  The receiver sends an ACK for the Send-Init, whose data field  contains
  1110.  its  own configuration parameters.  The data field of the Send-Init and the ACK
  1111.                       _______
  1112. +to the Send-Init are literal, that is, there is no prefix encoding.    This  is
  1113.                                        ___                             _____
  1114. +because the two parties will not know how to do prefix encoding until after the
  1115.  configuration data is exchanged.
  1116. 0It is important to note that newly invented fields are added at the  right,  so
  1117.  that  old  Kermit  programs that do not have code to handle the new fields will
  1118.  act as if they were not there.  For this reason,  the  default  value  for  any
  1119.  field,  indicated  by blank, should result in the behavior that occurred before
  1120.  the new field was defined or added.
  1121. 0   1      2      3      4      5      6      7      8      9      10...
  1122.    +------+------+------+------+------+------+------+------+------+-------
  1123.    | MAXL | TIME | NPAD | PADC | EOL  | QCTL | QBIN | CHKT | REPT | CAPAS
  1124.    +------+------+------+------+------+------+------+------+------+-------
  1125. 0The fields are as follows (the first and second person "I" and "you"  are  used
  1126.  to distinguish the two sides).  Fields are encoded printably using the tochar()
  1127.  function unless indicated otherwise.
  1128. 0   ____
  1129. +1. MAXL   The maximum length packet I want  to  receive,  a  number  up  to  94
  1130.            (decimal).    (This really means the biggest value I want to see in a
  1131.            LEN field.)  You respond with the maximum you want me to send.   This
  1132.            allows systems to adjust to each other's buffer sizes, or to the con-
  1133.            dition of the transmission medium.
  1134. 0   ____
  1135. +2. TIME   The number of seconds after which I want you to  time  me  out  while
  1136.            waiting  for a packet from me.  You respond with the amount of time I
  1137.            should wait for packets from you.  This allows the two sides  to  ac-
  1138.            commodate  to different line speeds or other factors that could cause
  1139.            timing problems.  Only one side needs to time out.    If  both  sides
  1140.            time out, then the timeout intervals should not be close together.
  1141. 0   ____
  1142. +3. NPAD   The  number  of  padding  characters  I want to precede each incoming
  1143.            packet; you respond in kind.  Padding may be necessary  when  sending
  1144.            to  a half duplex system that requires some time to change the direc-
  1145. 1Initial Connection
  1146. +Initial Connection
  1147. +Initial Connection                                                      Page 26
  1148. 0
  1149.            tion of transmission, although in practice  this  situation  is  more
  1150.            commonly handled by a "handshake" mechanism.
  1151. 0   ____
  1152. +4. PADC   The  control  character  I  need  for padding, if any, transformed by
  1153.                   ___
  1154. +          ctl() (not tochar()) to make it printable.    You  respond  in  kind.
  1155.            Normally NUL (ASCII 0), some systems use DEL (ASCII 127).  This field
  1156.            is to be ignored if the value NPAD is zero.
  1157. 0   ___
  1158. +5. EOL    The character I need to terminate an incoming packet, if  any.    You
  1159.            respond  in  kind.    Most systems that require a line terminator for
  1160.            terminal input accept carriage return for this purpose (note, because
  1161.            there  is no way to specify that no EOL should be sent, it would have
  1162.            been better to use ctl() for this field  rather  than  tochar(),  but
  1163.            it's too late now).
  1164. 0   ____
  1165. +6. QCTL   (verbatim)  The printable ASCII character I will use to quote control
  1166.            characters, normally and by default "#".  You respond  with  the  one
  1167.            you will use.
  1168. 0___  _________  ______  ______  __  ___  ___ __ ________ ________ __ ___ ______
  1169. +The  following  fields  relate  to  the  use of OPTIONAL features of the Kermit
  1170.  ________  _________ __ _______ _
  1171. +protocol, described in section 8.
  1172. 0   ____
  1173. +7. QBIN   (verbatim) The printable ASCII character  I  want  to  use  to  quote
  1174.            characters  which have the 8th bit set, for transmitting binary files
  1175.            when the parity bit cannot be used for data.    Since  this  kind  of
  1176.            quoting  increases  both  processor  and transmission overhead, it is
  1177.            normally to be avoided.  If used, the quote character must be in  the
  1178.            range  ASCII 33-62 ("!" through ">") or 96-126 ("`" through "~"), but
  1179.            different from the control-quoting character.  This field  is  inter-
  1180.            preted as follows:
  1181. 0          Y   I agree to 8-bit quoting if you request it (I don't need it).
  1182.            N   I will not do 8-bit quoting (I don't know how).
  1183.            &   (or  any  other character in the range 33-62 or 96-126) I need to
  1184.                do 8-bit quoting using this character (it will  be  done  if  the
  1185.                other  Kermit  puts  a Y in this field, or responds with the same
  1186.                prefix character, such as &).  The  recommended  8th-bit  quoting
  1187.                prefix character is "&".
  1188.            ________ ____
  1189. +          Anything Else : 8-bit quoting will not be done.
  1190. 0          Note that this scheme allows either side to initiate the request, and
  1191.            the order does not matter.  For instance, a micro  capable  of  8-bit
  1192.            communication  will  normally  put  a  "Y"  in  this  field whereas a
  1193.            mainframe that uses parity will always put an "&".    No  matter  who
  1194.            sends  first,  this  combination  will  result in election of 8th-bit
  1195.            quoting.
  1196. 0   ____
  1197. +8. CHKT   (Verbatim) Check Type, the method for  detecting  errors.    "1"  for
  1198.            single-character  checksum  (the normal and required method), "2" for
  1199.            two-character checksum (optional), "3" for three-character  CRC-CCITT
  1200.            (optional).    If your response agrees, the designated method will be
  1201.            used; otherwise the single-character checksum will be used.
  1202. 1Initial Connection
  1203. +Initial Connection
  1204. +Initial Connection                                                      Page 27
  1205. 0
  1206.     ____
  1207. +9. REPT   The prefix character I will use to  indicate  a  repeated  character.
  1208.            This  can  be  any  printable  character  in the range ASCII 33-62 or
  1209.            96-126, but different from the control and 8th-bit prefixes.  SP (32)
  1210.            denotes no repeat count processing is to be done.  Tilde ("~") is the
  1211.            recommended and normal repeat prefix.  If  you  don't  respond  iden-
  1212.            tically,  repeat  counts will not be done.  Groups of at least 3 or 4
  1213.            identical characters may be  transmitted  more  efficiently  using  a
  1214.            repeat  count,  though an individual implementation may wish to set a
  1215.            different threshhold.
  1216. 0      _____
  1217. +10-?. CAPAS
  1218.            A bit mask, in which each bit position corresponds to a capability of
  1219.            Kermit, and is set to 1 if that capability is present, or 0 if it  is
  1220.            not.     Each  character  contains  a  6-bit  field  (transformed  by
  1221.            tochar()), whose low order bit is set to 1 if another capability byte
  1222.            follows,  and  to  0  in  the last capability byte.  The capabilities
  1223.            defined so far are:
  1224. 0                ________
  1225. +            #1  Reserved
  1226.                  ________
  1227. +            #2  Reserved
  1228.              #3  Ability to accept "A" packets (file attributes)
  1229.              #4  Ability to do full duplex sliding window protocol
  1230.              #5  Ability to transmit and receive extended-length packets
  1231. 0          The capability byte as defined so far would then look like:
  1232. 0           bit5 bit4 bit3 bit2 bit1 bit0
  1233.            +----+----+----+----+----+----+
  1234.            | #1 | #2 | #3 | #4 | #5 |  0 |
  1235.            +----+----+----+----+----+----+
  1236. 0          If all these capabilities were "on", the value of the byte  would  be
  1237.            76  (octal).    When  capability 6 is added, the capability mask will
  1238.            look like this:
  1239. 0           bit5 bit4 bit3 bit2 bit1 bit0    bit5 bit4 bit3 bit2 bit1 bit0
  1240.            +----+----+----+----+----+----+   +----+----+----+----+----+----+
  1241.            | #1 | #2 | #3 | #4 | #5 |  1 |   | #6 | -- | -- | -- | -- |  0 |
  1242.            +----+----+----+----+----+----+   +----+----+----+----+----+----+
  1243. 0         _____
  1244. +CAPAS+1. WINDO
  1245.            Window size (see section 9.2).
  1246. 0         ______
  1247. +CAPAS+2. MAXLX1
  1248.            Extended packet length (see section 9.1).
  1249. 0         ______
  1250. +CAPAS+3. MAXLX2
  1251.            Extended packet length (see section 9.1).
  1252. 0The  receiving  Kermit  responds with an ACK ("Y") packet in the same format to
  1253.  indicate its own preferences, options, and parameters.  The ACK need  not  con-
  1254.  tain  the same number of fields as the the Send-Init.  From that point, the two
  1255. 1Initial Connection
  1256. +Initial Connection
  1257. +Initial Connection                                                      Page 28
  1258. 0
  1259.  Kermit programs are  "configured"  to  communicate  with  each  other  for  the
  1260.  remainder  of  the  transaction.  In the case of 8th-bit quoting, one side must
  1261.  specify the character to be used, and the other must agree with a  "Y"  in  the
  1262.  same  field, but the order in which this occurs does not matter.  Similarly for
  1263.  checksums -- if one side requests 2 character  checksums  and  the  other  side
  1264.  responds  with  a  "1"  or with nothing at all, then single-character checksums
  1265.  will be done, since not all implementations can be expected to  do  2-character
  1266.  checksums or CRCs.  And for repeat counts; if the repeat field of the send-init
  1267.  and the ACK do not agree, repeat processing will not be done.
  1268. 0All Send-Init fields are optional.  The data field may be left  totally  empty.
  1269.  Similarly,  intervening fields may be defaulted by setting them to blank.  Ker-
  1270.  mit implementations should know what to do in these  cases,  namely  apply  ap-
  1271.  propriate defaults.  The defaults should be:
  1272. 0    MAXL:   80
  1273.      TIME:   5 seconds
  1274.      NPAD:   0, no padding
  1275.      PADC:   0 (NUL)
  1276.      EOL:    CR (carriage return)
  1277.      QCTL:   the character "#"
  1278.      QBIN:   space, can't do 8-bit quoting
  1279.      CHKT:   "1", single-character checksum
  1280.      REPT:   No repeat count processing
  1281.      CAPAS:  All zeros (no special capabilities)
  1282.      WINDO:  Blank (zero) - no sliding windows
  1283.      MAXLX1: Blank (zero) - no extended length packets
  1284.      MAXLX2: Blank (zero) - no extended length packets
  1285. 0There are no prolonged negotiations in the initial connection sequence -- there
  1286.  is one Send-Init and one ACK in reply.  Everything must be settled in this  ex-
  1287.  change.
  1288. 0The  very first Send-Init may not get through if the sending Kermit makes wrong
  1289.  assumptions about the receiving host.  For instance, the receiving host may re-
  1290.  quire  certain  parity,  some  padding,  handshaking,  or a special end of line
  1291.  character in order to read the Send-Init packet.  For this reason, there should
  1292.  be  a way for the user the user to specify whatever may be necessary to get the
  1293.  first packet through.
  1294. 0A parity field is not provided in the Send-Init packet because it could not  be
  1295.  of use.  If the sender requires a certain kind of parity, it will also be send-
  1296.                                                               ______
  1297. +ing it.  If the receiver does not know this in advance, i.e. before getting the
  1298.  Send-Init, it will not be able to read the Send-Init packet.
  1299. 1Optional Features
  1300. +Optional Features
  1301. +Optional Features                                                       Page 29
  1302. 0
  1303.                                     CHAPTER 8
  1304. +                                   CHAPTER 8
  1305. +                                   CHAPTER 8
  1306.                                 OPTIONAL FEATURES
  1307. +                               OPTIONAL FEATURES
  1308. +                               OPTIONAL FEATURES
  1309. 0The foregoing sections have discussed basic, required operations for any Kermit
  1310.  implementation.  The following sections discuss optional and advanced features.
  1311. 0
  1312.  8.1. 8th-Bit and Repeat Count Prefixing
  1313. +8.1. 8th-Bit and Repeat Count Prefixing
  1314. +8.1. 8th-Bit and Repeat Count Prefixing
  1315. 0Prefix quoting of control characters is mandatory.  In addition, prefixing  may
  1316.  also  be  used for 8-bit quantities or repeat counts, when both Kermit programs
  1317.  agree to do so.  8th-bit prefixing can allow 8-bit  binary  data  pass  through
  1318.  7-bit  physical  links.    Repeat count prefixing can improve the throughput of
  1319.  certain kinds of files  dramatically;  binary  files  (particularly  executable
  1320.  programs) and structured text (highly indented or columnar text) tend to be the
  1321.  major beneficiaries.
  1322. 0When more than one type of prefixing is in effect, a single data character  can
  1323.  be  preceded  by  more  than one prefix character.  Repeat count processing can
  1324.  only be requested by the sender, and will only be used by  the  sender  if  the
  1325.  receiver  agrees.   8th-bit prefixing is a special case because its use is nor-
  1326.  mally not desirable, since it increases both processing and transmission  over-
  1327.  head.   However, since it is the only straightforward mechanism for binary file
  1328.  transfer available to those systems that usurp the parity bit, a receiver  must
  1329.  be  able  to  request the sender to do 8th-bit quoting, since most senders will
  1330.  not normally do it by default.
  1331. 0The repeat prefix is followed immediately by a single-character  repeat  count,
  1332.  encoded  printably  via  tochar(),  followed  by  the character itself (perhaps
  1333.  prefixed by control or 8th bit prefixes, as explained below).  The repeat count
  1334.  may  express values from 0 to 94.  If a character appears more than 94 times in
  1335.  a row, it must be "cut off" at 94, emitted with all appropriate  prefixes,  and
  1336.  "restarted".    The following table should clarify Kermit's prefixing mechanism
  1337.  (the final line shows how a sequence of 120 consecutive NULs would be encoded):
  1338. 0                 Prefixed           With
  1339.      _________    ______________     ______ _____ ___ _
  1340. +    Character    Representation     Repeat_Count_for_8
  1341.         A            A                ~(A   ["(" is ASCII 40 - 32 = 8]
  1342.         ^A           #A               ~(#A
  1343.         'A           &A               ~(&A
  1344.         '^A          &#A              ~(&#A
  1345.         #            ##               ~(##
  1346.         '#           &##              ~(&##
  1347.         &            #&               ~(#&
  1348.         '&           &#&              ~(&#&
  1349.         ~            #~               ~(#~
  1350.         '~           &#~              ~(&#~
  1351.         NUL          #@               ~~#@~:#@ [120 NULs]
  1352. 0A represents any printable character, ^A represents any control  character,  'x
  1353.  represents  any  character  with  the 8th bit set.  The # character is used for
  1354.  control-character prefixing, and the & character  for  8-bit  prefixing.    The
  1355. 1Optional Features
  1356. +Optional Features
  1357. +Optional Features                                                       Page 30
  1358. 0
  1359.  repeat  count must always precede any other prefix character.  The repeat count
  1360.  is taken literally (after transformation by unchar(); for instance "#" and  "&"
  1361.  immediately  following  a  "~"  denote repeat counts, not control characters or
  1362.  8-bit characters.  The control prefix character "#" is most  closely  bound  to
  1363.  the  data  character,  then  the  8-bit prefix, then the repeat count; in other
  1364.  words, the order is: repeat prefix and count, 8-bit prefix, control prefix, and
  1365.                                                                ___
  1366. +the  data  character itself.  To illustrate, note that &#A is not equivalent to
  1367.  #&A.
  1368. 0When the parity bit is available for data, then 8th-bit prefixing should not be
  1369.  done, and the 8th bit of the prefixed character will have the same value as the
  1370.  8th bit of the original data byte.  In that case, the table looks like this:
  1371. 0                 Prefixed           With
  1372.      _________    ______________     ______ _____ ___ _
  1373. +    Character    Representation     Repeat_Count_for_8
  1374.         'A           'A               ~('A
  1375.         '^A          #'A              ~(#'A
  1376.         '#           #'#              ~(#'#
  1377.         '&           '&               ~('&
  1378.         '~           #'~              ~(#'~
  1379. 0Note that since 8th bit prefixing is not being done, "&" is not being  used  as
  1380.  an  8th  bit  prefix  character,  so  it does not need to be prefixed with "#".
  1381.  Also, note that the 8th bit is set on the final  argument  of  the  repeat  se-
  1382.  quence, no matter how long, and not on any of the prefix characters.
  1383. 0Finally, remember the following rules:
  1384. 0     ________ _________ ____ ___ __ ______ ______ _______
  1385. +   - Prefixed sequences must not be broken across packets.
  1386. 0     _______  ___ ___  ___ ______ _____ ________ ____ __ ________
  1387. +   - Control, 8th-bit, and repeat count prefixes must be distinct.
  1388. 0     ____  ______  __  ___  _______  ____ ____ _______ ___ ______ ________
  1389. +   - Data  fields  of  all  packets  must pass through the prefix encoding
  1390.       _________  ______ ___ _  _  ___ _ _______  ___ ____ __ _____ _______
  1391. +     mechanism, except for S, I, and A packets, and ACKs to those packets,
  1392.       _____ ____ ______ ____ ___ __ _______
  1393. +     whose data fields must not be encoded.
  1394. 0In the first rule above, note that a prefixed sequence means a single character
  1395.                                    ___                                       ___
  1396. +and all its prefixes, like ~%&#X, not  a  sequence  like  #M#J,  which  is  two
  1397.  prefixed sequences.
  1398. 0
  1399.  8.2. Server Operation
  1400. +8.2. Server Operation
  1401. +8.2. Server Operation
  1402. 0A  Kermit server is a Kermit program running remotely with no "user interface".
  1403.  All commands to the server arrive in packets from the  local  Kermit.    SERVER
  1404.  operation  is  much  more  convenient than basic operation, since the user need
  1405.  never again interact directly with the remote Kermit program after once  start-
  1406.  ing  it  up in server mode, and therefore need not issue complementary SEND and
  1407.  RECEIVE commands on the two sides to get a file  transfer  started;  rather,  a
  1408.  single command (such as SEND or GET) to the local Kermit suffices.  Kermit ser-
  1409.  vers can also provide services beyond file transfer.
  1410. 1Optional Features
  1411. +Optional Features
  1412. +Optional Features                                                       Page 31
  1413. 0
  1414.  Between transactions, a Kermit server waits for packets containing server  com-
  1415.  mands.  The packet sequence number is always set back to 0 after a transaction.
  1416.  A Kermit server in command wait should be looking for  packet  0,  and  command
  1417.  packets  sent to servers should also be packet 0.  Certain server commands will
  1418.  result in the exchange of multiple packets.  Those operations  proceed  exactly
  1419.  like file transfer.
  1420. 0A  Kermit  server program waiting for a command packet is said to be in "server
  1421.  command wait".  Once put into server command  wait,  the  server  should  never
  1422.  leave  it  until it gets a command packet telling it to do so.  This means that
  1423.  after any transaction is terminated, either normally or by any kind  of  error,
  1424.  the server must go back into command wait.  While in command wait, a server may
  1425.  elect to send out periodic NAKs for packet  0,  the  expected  command  packet.
  1426.  Since  the  user  may  be disconnected from the server for long periods of time
  1427.  (hours), the interval between these NAKs should be  significantly  longer  than
  1428.  the  normal timeout interval (say, 30-60 seconds, rather than 5-10).  The peri-
  1429.  odic NAKs are useful for breaking the deadlock that  would  occur  if  a  local
  1430.  program was unable to time out, and sent a command that was lost.  On the other
  1431.  hand, they can cause problems for local Kermit programs that cannot clear their
  1432.  input  buffers,  or  for  systems that do XON/XOFF blindly, causing the NAKs to
  1433.  buffered in the server's host system output buffer, to be suddenly released  en
  1434.  masse  when  an XON appears.  For this reason, servers should have an option to
  1435.  set the command-wait wakeup interval, or to disable it altogher.
  1436. 0Server operation must be implemented in two places: in the server  itself,  and
  1437.  in  any  Kermit  program  that will be communicating with a server.  The server
  1438.  must have code to read the server commands from packets and  respond  to  them.
  1439.  The  user Kermit must have code to parse the user's server-related commands, to
  1440.  form the server command packets, and to handle the responses  to  those  server
  1441.  commands.
  1442. 0
  1443.  8.2.1. Server Commands
  1444. +8.2.1. Server Commands
  1445. +8.2.1. Server Commands
  1446. 0Server  commands  are listed below.  Not all of them have been implemented, and
  1447.  some may never be, but their use should  be  reserved.    Although  server-mode
  1448.  operation  is optional, certain commands should be implemented in every server.
  1449.  These include Send-Init (S), Receive-Init (R),  and  the  Generic  Logout  (GL)
  1450.  and/or  Finish (GF) commands.  If the server receives a command it does not un-
  1451.  derstand, or cannot execute, it should respond with an Error  (E)  packet  con-
  1452.  taining a message like "Unimplemented Server Command" and both sides should set
  1453.  the packet sequence number back to 0, and the server should  remain  in  server
  1454.  command wait.  Only a GL or GF command should terminate server operation.
  1455. 0Server commands are as follows:
  1456. 0S   Send Initiate (exchange parameters, server waits for a file).
  1457.  R   Receive Initiate (ask the server to send the specified files).
  1458.  I   Initialize (exchange parameters).
  1459.  X   Text header.  Allows transfer of text to the user's screen in response to a
  1460.      generic or host command.  This works just like file  transfer  except  that
  1461.      the  destination "device" is the screen rather than a file.  Data field may
  1462. 1Optional Features
  1463. +Optional Features
  1464. +Optional Features                                                       Page 32
  1465. 0
  1466.      contain a filename, title, or other heading.
  1467.  C   Host Command.  The data field contains a string to be executed as a command
  1468.      by the host system command processor.
  1469.  K   Kermit  Command.   The data field contains a string in the interactive com-
  1470.      mand language of the Kermit server (normally a SET command) to be  executed
  1471.      as if it were typed in at command level.
  1472.  G   Generic  Kermit Command.  Single character in data field (possibly followed
  1473.      by operands, shown in {braces}, optional fields  in  [brackets])  specifies
  1474.      the command:
  1475. 0    I   Login [{*user[*password[*account]]}]
  1476.      C   CWD, Change Working Directory [{*directory[*password]}]
  1477.      L   Logout, Bye
  1478.      F   Finish (Shut down the server, but don't logout).
  1479.      D   Directory [{*filespec}]
  1480.      U   Disk Usage Query [{*area}]
  1481.      E   Erase (delete) {*filespec}
  1482.      T   Type {*filespec}
  1483.      R   Rename {*oldname*newname}
  1484.      K   Copy {*source*destination}
  1485.      W   Who's logged in? (Finger) [{*user ID or network host[*options]}]
  1486.      M   Send a short Message {*destination*text}
  1487.      H   Help [{*topic}]
  1488.      Q   Server Status Query
  1489.      P   Program {*[program-filespec][*program-commands]}
  1490.      J   Journal {*command[*argument]}
  1491.      V   Variable {*command[*argument[*argument]]}
  1492. 0    Asterisk  as  used  above ("*") represents a single-character length field,
  1493.      encoded using tochar(), for the operand that follows it; thus lengths  from
  1494.      0  to  94  may  be  specified.  This allows multiple operands to be clearly
  1495.      delimited regardless of their contents.
  1496. 0Note that field length encoding is used within the data field  of  all  Generic
  1497.  command  packets,  but not within the data fields of the other packets, such as
  1498.  S, I, R, X, K, and C.
  1499. 0All server commands that send  arguments  in  their  data  fields  should  pass
  1500.  through  the  prefix  encoding  mechanism.   Thus if a data character or length
  1501.  field happens to correspond to an active prefix character, it  must  itself  be
  1502.                                                                ______
  1503. +prefixed.    The field length denotes the length of the field before prefix en-
  1504.                         _____
  1505. +coding and (hopefully) after prefix decoding.  For example, to send  a  generic
  1506.  command  with  two  fields,  "ABC"  and  "ZZZZZZZZ",  first each field would be
  1507.  prefixed by tochar() of its length,  in  this  case  tochar(3)  and  tochar(8),
  1508.  giving  "#ABC(ZZZZZZZZ".   But "#" is the normal control prefix character so it
  1509.  must be prefixed itself, and the eight Z's can be  condensed  to  3  characters
  1510.  using a repeat prefix (if repeat counts are in effect), so the result after en-
  1511.  coding would be "##ABC(~(Z" (assuming the repeat prefix is tilde  ("~").    The
  1512.  recipient  would  decode this back into the original "#ABC(ZZZZZZZZ" before at-
  1513.  tempting to extract the two fields.
  1514. 0Since a generic command must fit into a single packet, the program sending  the
  1515. 1Optional Features
  1516. +Optional Features
  1517. +Optional Features                                                       Page 33
  1518. 0
  1519.  command  should  ensure  that the command actually fits, and should not include
  1520.  length fields that point beyond the end  of  the  packet.    Servers,  however,
  1521.  should be defensive and not attempt to process any characters beyond the end of
  1522.  the data field, even if the argument length field would lead them to do so.
  1523. 0
  1524.  8.2.2. Timing
  1525. +8.2.2. Timing
  1526. +8.2.2. Timing
  1527. 0Kermit does not provide a mechanism for  suspending  and  continuing  a  trans-
  1528.  action.    This  means that text sent to the user's screen should not be frozen
  1529.  for long periods (i.e. not longer than  the  timeout  period  times  the  retry
  1530.  threshold).
  1531. 0Between  transactions,  when  the  server has no tasks pending, it may send out
  1532.  periodic NAKs (always with type 1 checksums) to prevent a deadlock  in  case  a
  1533.  command  was  sent  to  it  but  was lost.  These NAKs can pile up in the local
  1534.  "user" Kermit's input buffer (if it has one), so  the  user  Kermit  should  be
  1535.  prepared  to  clear  its  input  buffer  before  sending a command to a server.
  1536.  Meanwhile, servers should recognize that some systems provide no function to do
  1537.  this  (or  even  when they do, the process can be foiled by system flow control
  1538.  firmware) and should therefore provide a way turn off or slow down the command-
  1539.  wait NAKs.
  1540. 0
  1541.  8.2.3. The R Command
  1542. +8.2.3. The R Command
  1543. +8.2.3. The R Command
  1544. 0The  R  packet, generally sent by a local Kermit program whose user typed a GET
  1545.  command, tells the server to send the files specified by the name in  the  data
  1546.  field  of the R packet.  Since we can't assume that the two Kermits are running
  1547.  on like systems, the local (user) Kermit must parse the file specification as a
  1548.  character string, send it as-is (but encoded) to the server, and let the server
  1549.  take care of validating its syntax and looking up the file.  If the server  can
  1550.                                                                           ___ __
  1551. +open  and  read  the  specified file, it sends a Send-Init (S) packet -- not an
  1552.  _______________
  1553. +acknowledgement! -- to the user, and then  completes  the  file-sending  trans-
  1554.  action, as described above.
  1555. 0If  the server cannot send the file, it should respond with an error (E) packet
  1556.  containing a reason, like "File not found" or "Read access required".
  1557. 0Thus, the only two valid responses to a successfully received R packet are an S
  1558.  packet or an E packet.  The R packet is not ACK'd.
  1559. 0
  1560.  8.2.4. The K Command
  1561. +8.2.4. The K Command
  1562. +8.2.4. The K Command
  1563. 0The  K  packet  can contain a character string which the server interprets as a
  1564.  command in its own interactive command language.  This facility is  useful  for
  1565.  achieving  the  same effect as a direct command without having to shut down the
  1566.  server, connect back to the remote system, continue it (or start  a  new  one),
  1567.  and issue the desired commands.  The server responds with an ACK if the command
  1568.  was executed successfully, or an error packet otherwise.  The most  likely  use
  1569.  for the K packet might be for transmitting SET commands, e.g. for switching be-
  1570. 1Optional Features
  1571. +Optional Features
  1572. +Optional Features                                                       Page 34
  1573. 0
  1574.  tween text and binary file modes.
  1575. 0
  1576.  8.2.5. Short and Long Replies
  1577. +8.2.5. Short and Long Replies
  1578. +8.2.5. Short and Long Replies
  1579. 0Any request made of a server may be answered in either of  two  ways,  and  any
  1580.  User  Kermit  that  makes  such a request should be prepared for either kind of
  1581.  reply:
  1582. 0     _ _____ _____
  1583. +   - A short reply.  This consists of a single ACK packet, which may  con-
  1584.       tain  text  in  its  data field.  For instance, the user might send a
  1585.       disk space query to the server, and the server might ACK the  request
  1586.       with  a  short character string in the data field, such as "12K bytes
  1587.       free".  The user Kermit should display this text on the screen.
  1588. 0     _ ____ _____
  1589. +   - A long reply.  This proceeds exactly like a  file  transfer  (and  in
  1590.       some  cases  it  may  be a file transfer).  It begins with one of the
  1591.       following:
  1592. 0        * A File-Header (F) packet (optionally followed by one or more At-
  1593.            tributes packets; these are discussed later);
  1594. 0        * A Text-Header (X) packet.
  1595. 0        * A Send-Init (S) Packet, followed by an X or F packet.
  1596. 0     After  the  X or F packet comes an arbitrary number of Data (D) pack-
  1597.       ets, then an End-Of-File (Z) packet, and finally a Break-Transmission
  1598.       (B) packet, as for ordinary file transfer.
  1599. 0A  long reply should begin with an S packet unless an I-packet exchange has al-
  1600.                     ___
  1601. +ready taken place, and the type 1 (single-character) block check is being used.
  1602. 0
  1603.  8.2.6. Additional Server Commands
  1604. +8.2.6. Additional Server Commands
  1605. +8.2.6. Additional Server Commands
  1606. 0The following server commands request the server to perform  tasks  other  than
  1607.  sending  or receiving files.  Almost any of these can have either short or long
  1608.  replies.  For instance, the Generic Erase (GE) command may elicit a simple ACK,
  1609.  or  a  stream  of  packets  containing the names of all the files it erased (or
  1610.  didn't erase).  These commands are now described in more detail; arguments  are
  1611.  as  provided in commands typed to the user Kermit (subject to prefix encoding);
  1612.  no transformations to any kind of normal or canonic form are done --  filenames
  1613.  and other operands are in the syntax of the server's host system.
  1614. 0I   Login.  For use when a Kermit server is kept perpetually running on a dedi-
  1615.      cated line.  This lets a new user obtain an identity on the  server's  host
  1616.      system.    If the data field is empty, this removes the user's identity, so
  1617.      that the next user does not get access to it.
  1618. 0L   Logout, Bye.  This shuts down the server entirely, causing the  server  it-
  1619.      self  to  log  out  its  own job.  This is for use when the server has been
  1620. 1Optional Features
  1621. +Optional Features
  1622. +Optional Features                                                       Page 35
  1623. 0
  1624.      started up manually by the user, who then wishes to shut it down  remotely.
  1625.      For a perpetual, dedicated server, this command simply removes the server's
  1626.      access rights to the current user's files, and leaves  the  server  waiting
  1627.      for a new login command.
  1628. 0F   Finish.    This  is  to allow the user to shut down the server, putting its
  1629.      terminal back into normal (as opposed to binary or raw) mode,  and  putting
  1630.      the server's job back at system command level, still logged in, so that the
  1631.      user can connect back to the job.  For a perpetual, dedicated server,  this
  1632.      command behaves as the L (BYE) command.
  1633. 0C   CWD.    Change  Working Directory.  This sets the default directory or area
  1634.      for file transfer on the server's host.  With  no  operands,  this  command
  1635.      sets the default area to be the user's own default area.
  1636. 0D   Directory.    Send  a  directory listing to the user.  The user program can
  1637.      display it on the terminal or store it in a  file,  as  it  chooses.    The
  1638.      directory  listing  should contain file sizes and creation dates as well as
  1639.      file names, if possible.  A wildcard or other file-group designator may  be
  1640.      specified  to  ask  the  server  list  only  those files that match.  If no
  1641.      operand is given, all files in the current area should be shown.
  1642. 0U   Disk Usage Query.  The server responds with the amount of  space  used  and
  1643.      the  amount  left  free to use, in K bytes (or other units, which should be
  1644.      specified).
  1645. 0E   Erase (delete).  Delete the specified file or file group.
  1646. 0T   Type.  Send the specified file or file group, indicating (by starting  with
  1647.      an  X  packet rather than an F packet, or else by using the Type attribute)
  1648.      that the file is to be displayed on the screen, rather than stored.
  1649. 0R   Rename.  Change the name of the file or files as indicated.  The string in-
  1650.      dicating  the  new  name  may  contain other attributes, such as protection
  1651.      code, permitted in file specifications by the host.
  1652. 0K   Copy.  Produce a new copy of the file or file group, as indicated,  leaving
  1653.      the source file(s) unmodified.
  1654. 0W   Who's  logged  in? (Finger).  With no arguments, list all the users who are
  1655.      logged in on the server's host  system.    If  an  argument  is  specified,
  1656.      provide more detailed information on the specified user or network host.
  1657. 0M   Short  Message.    Send  the given short (single-packet) message to the in-
  1658.      dicated user's screen.
  1659. 0P   Program.  This command has two  arguments,  program  name  (filespec),  and
  1660.      command(s)  for  the program.  The first field is required, but may be left
  1661.      null (i.e. zero length).  If it is null, the currently  loaded  program  is
  1662.      "fed"  the specified command.  If not null, the specified program is loaded
  1663.      and started; if a program command is given it is fed to the program  as  an
  1664.      initial  command  (for instance, as a command line argument on systems that
  1665. 1Optional Features
  1666. +Optional Features
  1667. +Optional Features                                                       Page 36
  1668. 0
  1669.      support that concept).  In any case, the output of the program is sent back
  1670.      in packets as either a long or short reply, as described above.
  1671. 0J   Journal.  This command controls server transaction logging.  The data field
  1672.      contains one of the following:
  1673. 0    +   Begin/resume logging transactions.  If a filename is given,  close  any
  1674.          currently  open transaction and then open the specified file as the new
  1675.          transaction log.  If no name given, but a log file  was  already  open,
  1676.          resume  logging  to that file.  If no filename was given and no log was
  1677.          open,  the  server  should  open  a  log  with  a  default  name,  like
  1678.          TRANSACTION.LOG.
  1679. 0    -   Stop  logging transactions, but don't close the current transaction log
  1680.          file.
  1681. 0    C   Stop logging and close the current log.
  1682. 0    S   Send the transaction log as a file.  If it was open, close it first.
  1683. 0    Transaction logging is the recording of the progress of file transfers.  It
  1684.      should  contain entries showing the name of each file transferred, when the
  1685.      transfer began and ended, whether it completed successfully,  and  if  not,
  1686.      why.
  1687. 0                                   _______
  1688. +V   Set  or Query a variable.  The command can be S or Q. The first argument is
  1689.      the variable name.  The second argument, if any, is the value.
  1690. 0    S   Set the specified variable to the specified value.   If  the  value  is
  1691.          null,  then  undefine  the  variable.   If the variable is null then do
  1692.          nothing.  If the variable did not exist before, create it.  The  server
  1693.          should respond with an ACK if successful, and Error packet otherwise.
  1694. 0    Q   Query  the  value  of  the named variable.  If no variable is supplied,
  1695.          display the value of all active variables.  The  server  responds  with
  1696.          either  a  short or long reply, as described above.  If a queried vari-
  1697.          able does not exist, a null value is returned.
  1698. 0    Variables are named by character strings, and have character string values,
  1699.      which may be static or dynamic.  For instance, a server might have built-in
  1700.      variables like "system name" which never  changes,  or  others  like  "mail
  1701.      status"  which,  when queried, cause the server to check to see if the user
  1702.      has any new mail.
  1703. 1Optional Features
  1704. +Optional Features
  1705. +Optional Features                                                       Page 37
  1706. 0
  1707.  8.2.7. Host Commands
  1708. +8.2.7. Host Commands
  1709. +8.2.7. Host Commands
  1710. 0Host commands are conceptually simple, but may be hard  to  implement  on  some
  1711.  systems.  The C packet contains a text string in its data field which is simply
  1712.  fed to the server's host system command processor; any output from the  proces-
  1713.  sor  is  sent  back  to  the  user in Kermit packets, as either a short or long
  1714.  reply.
  1715. 0Implementation of this facility under UNIX, with its forking process  structure
  1716.  and i/o redirection via pipes, is quite natural.  On other systems, it could be
  1717.  virtually impossible.
  1718. 0
  1719.  8.2.8. Exchanging Parameters Before Server Commands
  1720. +8.2.8. Exchanging Parameters Before Server Commands
  1721. +8.2.8. Exchanging Parameters Before Server Commands
  1722. 0In basic Kermit, the Send-Init exchange is always sufficient to  configure  the
  1723.  two  sides  to  each  other.   During server operation, on the other hand, some
  1724.  transactions may not begin with a Send-Init packet.   For  instance,  when  the
  1725.  user  sends  an  R  packet to ask the server to send a file, the server chooses
  1726.  what block check option to use.  Or if the user requests a  directory  listing,
  1727.  the server does not know what packet length to use.
  1728. 0The solution to this problem is the "I" (Init-Info) packet.  It is exactly like
  1729.  a Send-Init packet, and the ACK works the same way too.  However, receipt of an
  1730.  I  packet  does not cause transition to file-send state.  The I-packet exchange
  1731.  simply allows the two sides to set their parameters,  in  preparation  for  the
  1732.  next transaction.
  1733. 0Servers  should  be  able to receive and ACK "I" packets when in server command
  1734.  wait.  User Kermits need not send "I" packets, however; in that case, the serv-
  1735.  er  will  assume  all  the defaults for the user listed on page 28, or whatever
  1736.  parameters have been set by other means (e.g. SET commands typed to the  server
  1737.  before it was put in server mode).
  1738. 0User  Kermits  which send I packets should be prepared to receive and ignore an
  1739.  Error packet in response.  This could happen if the server has not  implemented
  1740.  I packets.
  1741. 0The  I  packet,  together  with  its  ACK,  constitute  a complete transaction,
  1742.  separate from the S-packet or other exchange that follows it.  The packet  num-
  1743.  ber remains at zero after the I-packet exchange.
  1744. 0
  1745.  8.3. Alternate Block Check Types
  1746. +8.3. Alternate Block Check Types
  1747. +8.3. Alternate Block Check Types
  1748. 0There are two optional kinds of block checks:
  1749. 0____ _
  1750. +Type_2
  1751.      A two-character checksum based on the low order 12 bits of  the  arithmetic
  1752.      sum  of  the  characters in the packet (from the LEN field through the last
  1753.      data character, inclusive) as follows:
  1754. 1Optional Features
  1755. +Optional Features
  1756. +Optional Features                                                       Page 38
  1757. 0
  1758.                   1              2
  1759.          --------+----------------+---------------+
  1760.          ...data | tochar(b6-b11) | tochar(b0-b5) |
  1761.          --------+----------------+---------------+
  1762. 0    For instance, if the 16-bit result is 154321 (octal), then the 2  character
  1763.      block check would be "C1".
  1764. 0____ _
  1765. +Type_3
  1766.      Three-character 16-bit CRC-CCITT. The CRC calculation treats  the  data  it
  1767.      operates  upon  as  a  string  of  bits with the low order bit of the first
  1768.      character first and the high order bit of the last character last.  The in-
  1769.      itial value of the CRC is taken as 0; the 16-bit CRC is the remainder after
  1770.                                                      16  12  5
  1771.                                                     _   _   _
  1772. +    dividing the data bit string by the polynomial X  +X  +X +1 (this  calcula-
  1773.      tion  can  actually  be  done  a  character at a time, using a simple table
  1774.      lookup algorithm).  The result is represented as three printable characters
  1775.      at the end of the packet, as follows:
  1776. 0                 1               2              3
  1777.          --------+-----------------+----------------+---------------+
  1778.          ...data | tochar(b12-b15) | tochar(b6-b11) | tochar(b0-b5) |
  1779.          --------+-----------------+----------------+---------------+
  1780. 0    For  instance, if the 16-bit result is 154321 (octal), then the 3 character
  1781.      block check would be "-C1".  The CRC technique chosen here agrees with many
  1782.      hardware implementations (e.g. the VAX CRC instruction).
  1783. 0Here is an algorithm for Kermit's CRC-CCITT calculation:
  1784. 0                                                _____ ___ ___ __ _
  1785. +      crc = 0                                   Start CRC off at 0
  1786.                                                  _____ ____ __ _______
  1787. +      i = <position of LEN field>               First byte to include
  1788. 0                                                ___ _______ ____
  1789. +  A:  c = <byte at position i>                  Get current byte
  1790.                                                  ____ ___ ___ ______ ___
  1791. +      if (parity not NONE) then c = c AND 127;  Mask off any parity bit
  1792.                                                  __ ___ _____ _ ____
  1793. +      q = (crc XOR c) AND 15;                   Do low-order 4 bits
  1794.        crc = (crc / 16) XOR (q * 4225);
  1795.                                                  ___ ____ _ ____
  1796. +      q = (crc XOR (c / 16)) AND 015;           And high 4 bits
  1797.        crc = (crc / 16) XOR (q * 4225);
  1798.                                                  ________ __ ____ ____
  1799. +      i = i + 1                                 Position of next byte
  1800.                                                  _________ ______ ______
  1801. +      LEN = LEN - 1                             Decrement packet length
  1802.                                                  ____ ____ ____
  1803. +      if (LEN > 0) goto A                       Loop till done
  1804. 0  __ ____ _____  ___ ___ ________ ________ ___ _______ ________
  1805. +  At this point, the crc variable contains the desired quantity.
  1806. 0Thanks to Andy Lowry of Columbia's CS department for this "tableless" CRC algo-
  1807.  rithm (actually, it uses a table with one entry -- 4225).  AND is  the  bitwise
  1808.  AND  operation,  XOR  the  bitwise exclusive OR, "*" is multiplication, and "/"
  1809.  signifies integer division ("crc / 16" is equivalent to shifting the crc  quan-
  1810.  tity 4 bits to the right).
  1811. 0The single-character checksum has proven quite adequate in practice.  The other
  1812. 1Optional Features
  1813. +Optional Features
  1814. +Optional Features                                                       Page 39
  1815. 0
  1816.  options can be used only if both sides agree to do so via Init packet (S or  I)
  1817.  exchange.    The  2 and 3 character block checks should only be used under con-
  1818.  ditions of severe line noise and packet corruption.
  1819. 0Since type 2 and 3 block checks are optional, not all Kermits can  be  expected
  1820.  to  understand  them.  Therefore, during initial connection, communication must
  1821.  begin using the type 1 block check.  If type 2 or 3 block checks are agreed  to
  1822.                                                                   ____ _____
  1823. +during  the  "I"  or  "S" packet exchange, the switch will occur only after the
  1824.  Send-Init has been sent and ACK'd with a type 1 block check.  This  means  that
  1825.  the  first  packet  with a type 2 or 3 block check must always be an "F" or "X"
  1826.  packet.  Upon completion of a transaction, both sides must switch back to  type
  1827.  1  (to  allow  for  the  fact that neither side has any way of knowing when the
  1828.                                                                         _____
  1829. +other side has been stopped and restarted).  The transaction is  over  after  a
  1830.  "B"  or  "E" packet has been sent and ACK'd, or after any error that terminates
  1831.  the transaction prematurely or abnormally.
  1832. 0A consequence of the foregoing rule is that if a type 2 or 3 block check is  to
  1833.                                                  ____
  1834. +be  used,  a  long  reply  sent  by  the server must begin with a Send-Init (S)
  1835.  packet, even if an I packet exchange had already occurred.   If  type  1  block
  1836.  checks  are  being used, the S packet can be skipped and the transfer can start
  1837.  with an X or F packet.
  1838. 0A server that has completed a transaction and is awaiting  a  new  command  may
  1839.  send  out periodic NAKs for that command (packet 0).  Those NAKs must have type
  1840.  1 block checks.
  1841. 0The use of alternate block check types can cause certain  complications.    For
  1842.  instance, if the server gets a horrible error (so bad that it doesn't even send
  1843.  an error packet) and reverts to command wait, sending NAKs for packet 0 using a
  1844.  type  1  block  check,  while  a transfer using type 2 or 3 block checks was in
  1845.  progress, neither side will be able to read the other's packets.  Communication
  1846.  can  also  grind to a halt if A sends a Send-Init requesting, say, type 3 block
  1847.  checks, B ACKs the request, switches to type 3 and waits for the X or F  packet
  1848.  with a type 3 block check, but the ACK was lost, so A resends the S packet with
  1849.  a type 1 block check.  Situations like this will ultimately resolve  themselves
  1850.  after  the  two  sides retransmit up to their retry threshhold, but can be rec-
  1851.  tified earlier by the use of two heuristics:
  1852. 0   - The packet reader can assume that if the  packet  type  is  "S",  the
  1853.       block check type is 1.
  1854. 0   - A  NAK  packet  never has anything in its data field.  Therefore, the
  1855.       block check type can always be deduced by the packet reader from  the
  1856.       length  field of a NAK.  In fact, it is the value of the length field
  1857.       minus 2.  A NAK can therefore be thought of as a kind  of  "universal
  1858.       synchronizer".
  1859. 0These  heuristics tend to violate the layered nature of the protocol, since the
  1860.  packet reader should normally be  totally  unconcerned  with  the  packet  type
  1861.  (which  is  of  interest  to  the  application  level  which invokes the packet
  1862.  reader).  A better design would have had each packet include  an  indicator  of
  1863.  the  type  of its own block check; this would have allowed the block check type
  1864. 1Optional Features
  1865. +Optional Features
  1866. +Optional Features                                                       Page 40
  1867. 0
  1868.  to be changed dynamically during a transaction to adapt to changing conditions.
  1869.  But it's too late for that now...
  1870. 0
  1871.  8.4. Interrupting a File Transfer
  1872. +8.4. Interrupting a File Transfer
  1873. +8.4. Interrupting a File Transfer
  1874. 0This  section  describes  an  optional  feature of the Kermit protocol to allow
  1875.  graceful interruption of file transfer.  This feature is  unrelated  to  server
  1876.  operation.
  1877. 0To interrupt sending a file, send an EOF ("Z") packet in place of the next data
  1878.  packet, including a "D" (for Discard) in the data field.   The  recipient  ACKs
  1879.  the  Z  packet normally, but does not retain the file.  This does not interfere
  1880.  with older Kermits on the receiving end; they will not inspect the  data  field
  1881.  and  will close the file normally.  The mechanism can be triggered by typing an
  1882.  interrupt character at the console  of  the  sending  Kermit  program.    If  a
  1883.  (wildcard) file group is being sent, it is possible to skip to the next file or
  1884.  to terminate the entire batch; the protocol is the same in either case, but the
  1885.  desired action could be selected by different interrupt characters, e.g. CTRL-X
  1886.  to skip the current file, CTRL-Z to skip the rest of the batch.
  1887. 0To interrupt receiving a file, put an "X" in the data field of  an  ACK  for  a
  1888.  Data packet.  To interrupt receiving an entire file group, use a "Z".  The user
  1889.  could trigger this mechanism by typing an interrupt character, say, CTRL-X  and
  1890.  CTRL-Z,  respectively,  at  the  receiving Kermit's console.  A sender that was
  1891.  aware of the new feature, upon  finding  one  of  these  codes,  would  act  as
  1892.  described  above, i.e. send a "Z" packet with a "D" code; a sender that did not
  1893.  implement this feature would simply ignore the codes and continue sending.   In
  1894.  this  case, and if the user wanted the whole batch to be cancelled (or only one
  1895.  file was being sent), the receiving Kermit program, after determining that  the
  1896.  sender  had ignored the "X" or "Z" code, could send an Error (E) packet to stop
  1897.  the transfer.
  1898. 0The sender may also choose to send a Z packet containing the  D  code  when  it
  1899.  detects  that the file it is sending cannot be sent correctly and completely --
  1900.  for instance, after sending some packets correctly, it gets an i/o error  read-
  1901.  ing the file.  Or, it notices that the "8th bit" of a file byte is set when the
  1902.  file is being sent as a text file and no provision has been made for  transmit-
  1903.  ting the 8th bit.
  1904. 0
  1905.  8.5. Transmitting File Attributes
  1906. +8.5. Transmitting File Attributes
  1907. +8.5. Transmitting File Attributes
  1908. 0The  optional  Attributes  (A)  packet provides a mechanism for the sender of a
  1909.  file to provide additional information about it.  This packet can  be  sent  if
  1910.  the  receiver has indicated its ability to process it by setting the Attributes
  1911.  bit in the capability mask.    If  both  sides  set  this  bit  in  the  Kermit
  1912.  capability  mask, then the sender, after sending the filename in the "F" packet
  1913.  and receiving an acknowledgement, may (but does not have to) send an "A" packet
  1914.  to provide file attribute information.
  1915. 0                                                       ___
  1916. +Setting the Attributes bit in the capability mask does not indicate support for
  1917. 1Optional Features
  1918. +Optional Features
  1919. +Optional Features                                                       Page 41
  1920. 0
  1921.  any particular attributes, only that the receiver is prepared to accept the "A"
  1922.  packet.
  1923. 0The  attributes  are given in the data field of the "A" packet.  The data field
  1924.  consists of 0 or more subfields, which may occur in any order.   Each  subfield
  1925.  is of the following form:
  1926. 0    +-----------+----------------+------+
  1927.      | ATTRIBUTE | tochar(LENGTH) | DATA |
  1928.      +-----------+----------------+------+
  1929. 0where
  1930. 0ATTRIBUTE is a single printable character other than space,
  1931. 0LENGTH    is  the  length  of  the  data characters (0 to 94), with 32 added to
  1932.            produce a single printable character, and
  1933. 0             ______
  1934. +DATA      is length characters worth of data, all printable characters.
  1935. 0No quoting or prefixing is done on any of this data.
  1936. 0More than one attribute packet may be sent.  The only requirement is  that  all
  1937.  the A packets for a file must immediately follow its File header (or X) packet,
  1938.  and precede the first Data packet.
  1939. 0There may be 93 different attributes, one for each of the  93  printable  ASCII
  1940.  characters other than space.  These are assigned in ASCII order.
  1941. 0! (ASCII 33)
  1942.            Length.  The data field gives the length in  K  (1024)  bytes,  as  a
  1943.            printable decimal number, e.g. "!#109".  This will allow the receiver
  1944.            to determine in advance whether there  is  sufficient  room  for  the
  1945.            file, and/or how long the transfer will take.
  1946. 0" (ASCII 34)
  1947.            Type.  The data field can contain some indicator of the nature of the
  1948.            file.     Operands  are  enclosed  in  {braces},  optional  items  in
  1949.            [brackets].  The braces and brackets do not actually  appear  in  the
  1950.            packet.
  1951. 0          A[{xx}] ASCII  text,  containing no 8-bit quantities, logical records
  1952.                    (lines) delimited by the (quoted) control character  sequence
  1953.                    {xx},  represented  here  by  its printable counterpart (MJ =
  1954.                    CRLF, J = LF, etc).  For instance  AMJ  means  that  the  ap-
  1955.                    pearance  of  #M#J  (the  normal prefixed CRLF sequence) in a
  1956.                    file data packet indicates the end of a record, assuming  the
  1957.                    current  control  prefix is "#".  If {xx} is omitted, MJ will
  1958.                    be assumed.
  1959. 0          B[{xx}] Binary.  {xx} indicates in what manner the file is binary:
  1960. 1Optional Features
  1961. +Optional Features
  1962. +Optional Features                                                       Page 42
  1963. 0
  1964.                    8   (default) The file is a sequence of  8-bit  bytes,  which
  1965.                        must  be saved as is.  The 8th bit may be sent "bare", or
  1966.                        prefixed according to  the  Send-Init  negotiation  about
  1967.                        8th-bit prefixing.
  1968. 0                  36  The  file  is  a PDP-10 format binary file, in which five
  1969.                        7-bit bytes are fit into one 36-bit word, with the  final
  1970.                        bit of each word being represented as the "parity bit" of
  1971.                        every 5th character (perhaps prefixed).
  1972. 0                  _____ ____ ____ __ ______ _________
  1973. +          D{x}    Moved from here to FORMAT attribute
  1974. 0                  _____ ____ ____ __ ______ _________
  1975. +          F{x}    Moved from here to FORMAT attribute
  1976. 0          I[{x}]  Image.  The file is being sent exactly as it  is  represented
  1977.                    on  the  system  of  origin.    For use between like systems.
  1978.                    There are {x} usable bits per  character,  before  prefixing.
  1979.                    For  instance,  to  send binary data from a system with 9-bit
  1980.                    bytes, it might be convenient to send three 6-bit  characters
  1981.                    for every two 9-bit bytes.  Default {x} is 8.
  1982. 0# (ASCII 35)
  1983.            Creation Date, expressed as "[yy]yymmdd[ hh:mm[:ss]]"  (ISO  standard
  1984.            date  format), e.g. 831009 23:59.  The time is optional; if given, it
  1985.            should be in 24-hour format, and the seconds may be  omitted,  and  a
  1986.            single space should separate the time from the date.
  1987. 0$ (ASCII 36)
  1988.            Creator's ID, expressed as a character string of the given length.
  1989. 0% (ASCII 37)
  1990.            Account to charge the file to, character string.
  1991. 0& (ASCII 38)
  1992.            Area in which to store the file, character string.
  1993. 0' (ASCII 39)
  1994.            Password for above, character string.
  1995. 0( (ASCII 40)
  1996.            Block Size.  The file has, or is to be stored with, the  given  block
  1997.            size.
  1998. 0) (ASCII 41)
  1999.            Access:
  2000. 0          N   New, the normal case -- create a new file of the given name.
  2001.            S   Supersede (overwrite) any file of the same name.
  2002.            A   Append to file of the given name.
  2003. 0* (ASCII 42)
  2004.            Encoding:
  2005. 1Optional Features
  2006. +Optional Features
  2007. +Optional Features                                                       Page 43
  2008. 0
  2009.            A   ASCII, normal ASCII encoding with any necessary prefixing, etc.
  2010.            H   Hexadecimal "nibble" encoding.
  2011.            E   EBCDIC (sent as if it were a binary file).
  2012.            X   Encrypted.
  2013.            Q{x}
  2014.                                                        _
  2015. +              Huffman Encoded for compression.  First x bytes of the  file  are
  2016.                the key.
  2017. 0# (ASCII 43)
  2018.            Disposition (operands are specified in the syntax of  the  receiver's
  2019.            host system):
  2020. 0          M{user(s)}      Send the file as Mail to the specified user(s).
  2021. 0          O{destination}  Send  the  file  as  a  lOng  terminal message to the
  2022.                            specified destination (terminal, job, or user).
  2023. 0          S[{options}]    Submit the file as a batch job,  with  any  specified
  2024.                            options.
  2025. 0          P[{options}]    Print   the  file  on  a  system  printer,  with  any
  2026.                            specified options, which  may  specify  a  particular
  2027.                            printer, forms, etc.
  2028. 0          T               Type the file on the screen.
  2029. 0          L[{aaa}]        Load  the  file  into memory at the given address, if
  2030.                            any.
  2031. 0          X[{aaa}]        Load the file into memory at the  given  address  and
  2032.                            eXecute it.
  2033. 0          A               Archive the file; save the file together with the at-
  2034.                            tribute packets that preceded it, so that it  can  be
  2035.                            sent  back  to  the system of origin with all its at-
  2036.                            tributes intact.  A file stored in this way should be
  2037.                            specially  marked  so  that  the Kermit that sends it
  2038.                            back will recognize the attribute information as dis-
  2039.                            tinct from the file data.
  2040. 0, (ASCII 44)
  2041.            Protection.  Protection code for the  file,  in  the  syntax  of  the
  2042.            receiver's host file system.  With no operand, store according to the
  2043.            system's default protection for the destination area.
  2044. 0- (ASCII 45)
  2045.            Protection.    Protection  code  for  the  file  with  respect to the
  2046.            "public" or "world", expressed generically in a 6-bit quantity  (made
  2047.            printable by tochar()), in which the bits have the following meaning:
  2048. 0          b0: Read Access
  2049.            b1: Write Access
  2050. 1Optional Features
  2051. +Optional Features
  2052. +Optional Features                                                       Page 44
  2053. 0
  2054.            b2: Execute Access
  2055.            b3: Append Access
  2056.            b4: Delete Access
  2057.            b5: Directory Listing
  2058. 0          A  one  in the bit position means allow the corresponding type of ac-
  2059.            cess, a zero means prohibit it.  For example, the letter "E" in  this
  2060.            field  would  allow  read,  execute,  and  directory  listing  access
  2061.            (unchar("E") = 69-32 = 37 = 100101 binary).
  2062. 0. (ASCII 46)
  2063.            Machine  and  operating system of origin.  This is useful in conjunc-
  2064.            tion with the archive disposition attribute.  It allows a file,  once
  2065.            archived, to be transferred among different types of systems, retain-
  2066.            ing its archive status, until it finds its way to a machine with  the
  2067.            right  characteristics  to de-archive it.  The systems are denoted by
  2068.            codes; the first character is the major system designator, the second
  2069.            designates the specific model or operating system.  A third character
  2070.            may be added to make further  distinctions,  for  instance  operating
  2071.            system version.  The systems below do not form a complete collection;
  2072.            many more can and probably will be added.
  2073. 0          A   Apple microcomputers
  2074. 0              1   Apple II, DOS
  2075.                2   Apple III
  2076.                3   Macintosh
  2077.                4   Lisa
  2078. 0          B   Sperry (Univac) mainframes
  2079. 0              1   1100 series, EXEC
  2080.                2   9080, VS9
  2081. 0          C   CDC mainframes
  2082. 0              1   Cyber series, NOS
  2083.                2   Cyber series, NOS-BE
  2084.                3   Cyber series, NOS-VE
  2085.                4   Cyber series, SCOPE
  2086. 0          D   DEC Systems
  2087. 0              1   DECsystem-10/20, TOPS-10
  2088.                2   DECsystem-10/20, TOPS-20
  2089.                3   DECsystem-10/20, TENEX
  2090.                4   DECsystem-10/20, ITS
  2091.                5   DECsystem-10/20, WAITS
  2092.                6   DECsystem-10/20, MAXC
  2093.                7   VAX-11, VMS
  2094.                8   PDP-11, RSX-11
  2095.                9   PDP-11, IAS
  2096. 1Optional Features
  2097. +Optional Features
  2098. +Optional Features                                                       Page 45
  2099. 0
  2100.                A   PDP-11, RSTS/E
  2101.                B   PDP-11, RT-11
  2102.                C   Professional-300, P/OS
  2103.                D   Word Processor (WPS or DECmate), WPS
  2104. 0          E   Honeywell mainframes
  2105. 0              1   MULTICS systems
  2106.                2   DPS series, running CP-6
  2107.                3   DPS series, GCOS
  2108.                4   DTSS
  2109. 0          F   Data General machines
  2110. 0              1   RDOS
  2111.                2   AOS
  2112.                3   AOS/VS
  2113. 0          G   PR1ME machines, PRIMOS
  2114. 0          H   Hewlett-Packard machines
  2115. 0              1   HP-1000, RTE
  2116.                2   HP-3000, MPE
  2117. 0          I   IBM 370-series and compatible mainframes
  2118. 0              1   VM/CMS
  2119.                2   MVS/TSO
  2120.                3   DOS
  2121.                4   MUSIC
  2122.                5   GUTS
  2123.                6   MTS
  2124. 0          J   Tandy microcomputers, TRSDOS
  2125. 0          K   Atari computers
  2126. 0              1   Home computers, DOS
  2127.                2   ST series
  2128. 0          L   Commodore micros
  2129. 0              1   Pet
  2130.                2   64
  2131.                3   Amiga
  2132. 0          M   Miscellaneous mainframes and  minis  with  proprietary  operation
  2133.                systems:
  2134. 0              1   Gould/SEL minis, MPX
  2135.                2   Harris, VOS
  2136. 1Optional Features
  2137. +Optional Features
  2138. +Optional Features                                                       Page 46
  2139. 0
  2140.                3   Perkin-Elmer minis, OS/32
  2141.                4   Prime, Primos
  2142.                5   Tandem, Nonstop
  2143.                6   Cray, CTSS
  2144.                7   Burroughs (subtypes may be necessary here)
  2145.                8   GEC 4000, OS4000
  2146.                9   ICL machines
  2147.                A   Norsk Data, Sintran III
  2148.                B   Nixdorf machines
  2149. 0          N   Miscellaneous micros and workstations:
  2150. 0              1   Acorn BBC Micro
  2151.                2   Alpha Micro
  2152.                3   Apollo Aegis
  2153.                4   Convergent, Burroughs, and similar systems with CTOS, BTOS
  2154.                5   Corvus, CCOS
  2155.                6   Cromemco, CDOS
  2156.                7   Intel x86/3x0, iRMX-x86
  2157.                8   Intel MDS, ISIS
  2158.                9   Luxor ABC-800, ABCDOS
  2159.                A   Perq
  2160.                B   Motorola, Versados
  2161. 0              ________
  2162. +          O-T Reserved
  2163. 0          U   Portable Operating or File Systems
  2164. 0              1   UNIX
  2165.                2   Software Tools
  2166.                3   CP/M-80
  2167.                4   CP/M-86
  2168.                5   CP/M-68K
  2169.                6   MP/M
  2170.                7   Concurrent CP/M
  2171.                8   MS-DOS
  2172.                9   UCSD p-System
  2173.                A   MUMPS
  2174.                B   LISP
  2175.                C   FORTH
  2176.                D   OS-9
  2177. 0/ (ASCII 47)
  2178.            Format of the data within the packets.
  2179. 0          A{xx}           Variable length delimited records, terminated by  the
  2180.                            character  sequence {xx}, where xx is a string of one
  2181.                            or more control characters, represented here by their
  2182.                            unprefixed  printable  equivalents,  e.g. MJ for ^M^J
  2183.                            (CRLF).
  2184. 0          D{x}            Variable length undelimited records.    Each  logical
  2185. 1Optional Features
  2186. +Optional Features
  2187. +Optional Features                                                       Page 47
  2188. 0
  2189.                            record  begins  with  an  {x}-character ASCII decimal
  2190.                            length field (similar to ANSI tape format "D").   For
  2191.                            example,  "D$"  would indicate 4-digit length fields,
  2192.                            like "0132".
  2193. 0          F{xxxx}         Fixed-length  undelimited  records.    Each   logical
  2194.                            record is {xxxx} bytes long.
  2195. 0          R{x}            For record-oriented transfers, to be used in combina-
  2196.                            tion with one of  the  formats  given  above.    Each
  2197.                            record  begins  (in  the  case of D format, after the
  2198.                            length field) with an x-character long position field
  2199.                            indicating the byte position within the file at which
  2200.                            this record is to be stored.
  2201. 0          M{x}            For record-oriented transfers, to be used in combina-
  2202.                            tion  with  one  of the formats given above.  Maximum
  2203.                            record length for a variable-length record.
  2204. 00 (ASCII 48)
  2205.            Special  system-dependent parameters for storing the file on the sys-
  2206.            tem of origin, for specification of exotic attributes not covered ex-
  2207.            plicitly by any of the Kermit attribute descriptors.  These are given
  2208.            as a character string in the system's own  language,  for  example  a
  2209.            list of DCB parameters in IBM Job Control Language.
  2210. 01-@ (ASCII 49)
  2211.            Exact byte count of the file as it is stored on the sender's  system,
  2212.            before any conversions (e.g. to canonic form).  Of limited usefulness
  2213.            when transferring text files  between  systems  that  represent  text
  2214.            boundaries differently.
  2215. 02-@ (ASCII 50-64)
  2216.            ________
  2217. +          Reserved
  2218. 0Other attributes can be imagined, and can be added later if needed.    However,
  2219.  two important points should be noted:
  2220. 0   - The  receiver may have absolutely no way of honoring, or even record-
  2221.       ing, a given attribute.  For instance, CP/M-80 has no slot for  crea-
  2222.       tion  date  or  creator's ID in its FCB; the DEC-20 has no concept of
  2223.       block size, etc.
  2224. 0   - The sender may have no way of determining the correct values  of  any
  2225.       of  the  attributes.  This is particularly true when sending files of
  2226.       foreign origin.
  2227. 0The "A" packet mechanism only provides a way to send certain information  about
  2228.  a  file to the receiver, with no provision or guarantee about what the receiver
  2229.  may do with it.  That information may be  obtained  directly  from  the  file's
  2230.  directory entry (FCB, FDB, ...), or specified via user command.
  2231. 1Optional Features
  2232. +Optional Features
  2233. +Optional Features                                                       Page 48
  2234. 0
  2235.  The  ACK  to  the  "A"  packet  may in turn have information in its data field.
  2236.  However, no complicated negotiations about file attributes may take  place,  so
  2237.  the  net  result  is that the receiver may either refuse the file or accept it.
  2238.  The receiver may reply to the "A" packet with any of the following codes in the
  2239.  data field of the ACK packet:
  2240. 0<null>  (empty data field) I accept the file, go ahead and send it.
  2241. 0N[{xxx}]
  2242.          I refuse the file as specified, don't send it; {xxx}  is  a  string  of
  2243.          zero  or more of the attribute characters listed above, to specify what
  2244.          attributes I object to (e.g. "!" means it's too long, "&" means I don't
  2245.          have write access to the specified area, etc).
  2246. 0Y[{xxx}]
  2247.          I agree to receive the file, but I cannot honor attributes {xxx}, so  I
  2248.          will store the file according to my own defaults.
  2249. 0Y       (degenerate case of Y{xxx}, equivalent to <null>, above)
  2250. 0How  the  receiver  actually  replies  is an implementation decision.  A NAK in
  2251.  response to the "A" packet means, of course, that the receiver did not  receive
  2252.  the "A" correctly, not that it refuses to receive the file.
  2253. 0
  2254.  8.6. Advanced Kermit Protocol State Table
  2255. +8.6. Advanced Kermit Protocol State Table
  2256. +8.6. Advanced Kermit Protocol State Table
  2257. 0The  simple  table  presented  previously  is sufficient for a basic Kermit im-
  2258.  plementation.  The following is a state table for the full Kermit protocol, in-
  2259.  cluding  both server mode and sending commands to a server Kermit.  It does not
  2260.  include handling of the file attributes packet (A).   Note  that  states  whose
  2261.  names  start  with "Send" always send a packet each time they are entered (even
  2262.  when the previous state was the same).  States whose name  starts  with  "Rec",
  2263.  always  wait for a packet to be received (up to the timeout value), and process
  2264.  the received packet.  States whose names do not include either send or  receive
  2265.  do  not  process  packets  directly.  These are states which perform some local
  2266.  operation and then change to another state.
  2267. 0The initial state is determined by the user's  command.    A  "server"  command
  2268.  enters  at Rec_Server_Idle.  A "send" command enters at Send_Init.  A "receive"
  2269.  command (the old non-server version, not a "get" command) enters  at  Rec_Init.
  2270.  Any  generic command, the "get" command, and the "host" command enter at either
  2271.  Send_Server_Init or Send_Gen_Cmd, depending upon the expected response.
  2272. 0Under "Rec'd Msg", the packet type of the incoming message is  shown,  followed
  2273.  by the packet number in parentheses; (n) means the current packet number, (n-1)
  2274.  and (n+1) mean the previous and next packet  numbers  (modulo  64),  (0)  means
  2275.  packet  number zero. Following the packet number may be slash and a letter, in-
  2276.  dicating some special signal in the data field.  For instance Z(n)/D  indicates
  2277.                                    _
  2278. +a Z (EOF) packet, sequence number n, with a "D" in the data field.
  2279. 0Under  "Action",  "r+"  means  that the retry count is incremented and compared
  2280. 1Optional Features
  2281. +Optional Features
  2282. +Optional Features                                                       Page 49
  2283. 0
  2284.  with a threshhold; if the threshhold is exceeded, an Error packet is  sent  and
  2285.  the  state  changes  to  "Abort".   "n+" means that the packet number is incre-
  2286.                                          _
  2287. +mented, modulo 64, and the retry count, r, is set back to zero.
  2288. 0_____   _____ ___       ______                  ____ _____
  2289. +State   Rec'd_Msg       Action                  Next_state
  2290. 0                   ______ ____  _______ ___ _ _______
  2291. +Rec_Server_Idle -- Server idle, waiting for a message
  2292. 0    Set n and r to 0
  2293. 0        I(0)            Send ACK                Rec_Server_Idle
  2294.          S(0)            Process params,
  2295.                           ACK with params, n+    Rec_File
  2296.          R(0)            Save file name          Send_Init
  2297. 0        K, C or G(0)    Short reply:
  2298.                           ACK(0)/reply           Rec_Server_Idle
  2299.                          Long reply:
  2300.                           init needed            Send_Init
  2301.                           init not needed, n+    Open_File
  2302. 0        Timeout         Send NAK(0)             Rec_Server_Idle
  2303.          Other           Send E                  Rec_Server_Idle
  2304.              _____ _____ ___ ___ ______ _______ _______
  2305. +Rec_Init -- Entry point for non-server RECEIVE command
  2306. 0    Set n and r to 0
  2307. 0        S(0)            Process params, send
  2308.                           ACK with params, n+    Rec_File
  2309.          Timeout         Send NAK(0), r+         Rec_Init
  2310.          Other           Send E                  Abort
  2311.              ____ ___ _ ____ ______ __ ___ _______
  2312. +Rec_File -- Look for a file header or EOT message
  2313. 0        F(n)            Open file, ACK, n+      Rec_Data
  2314.          X(n)            Prepare to type on
  2315.                           screen, ACK, n+        Rec_Data
  2316.          B(n)            ACK                     Complete
  2317.          S(n-1)          ACK with params, r+     Rec_File
  2318.          Z(n-1)          ACK, r+                 Rec_File
  2319.          Timeout         Resend ACK(n), r+       Rec_File
  2320.          Other           Send E                  Abort
  2321.              _______ ____ __ __ ___ __ ____
  2322. +Rec_Data -- Receive data up to end of file
  2323. 0        D(n)            Store data, ACK, n+;
  2324.                           If interruption wanted
  2325.                           include X or Z in ACK  Rec_Data
  2326.          D(n-1)          Send ACK, r+            Rec-Data
  2327.          Z(n)            Close file, ACK, n+     Rec_File
  2328.          Z(n)/D          Discard file, ACK, n+   Rec_File
  2329.          F(n-1)          Send ACK, r+            Rec_Data
  2330.          X(n-1)          Send ACK, r+            Rec_Data
  2331.          Timeout         Send ACK(n-1), r+       Rec_Data
  2332. 1Optional Features
  2333. +Optional Features
  2334. +Optional Features                                                       Page 50
  2335. 0
  2336.          Other           Send E                  Abort
  2337.               ____ _____ ___ ____ _______
  2338. +Send_Init -- Also entry for SEND command
  2339. 0    Set n and r to 0, send S(0) with parameters
  2340. 0        Y(0)            Process params, n+      Open_File
  2341.          N, Timeout      r+                      Send_Init
  2342.          Other           r+                      Send_Init
  2343.               ____ ____ __ ___ __ ____ __ ____
  2344. +Open_File -- Open file or set up text to send
  2345. 0                                                Send_File
  2346.               ____ ____ __ ____ ______
  2347. +Send_File -- Send file or text header
  2348. 0    Send F or X(n)
  2349. 0        Y(n), N(n+1)    Get first buffer of     Send_Data or Send_Eof if
  2350.                           data, n+                empty file or text
  2351.          N, Timeout      r+                      Send_File
  2352.          Other                                   Abort
  2353.               ____ ________ __ ____ __ _______ ___________
  2354. +Send_Data -- Send contents of file or textual information
  2355. 0    Send D(n) with current buffer
  2356. 0        Y(n), N(n+1)    n+, Get next buffer     Send_Data or Send_Eof if
  2357.                                                   at end of file or text
  2358.          Y(n)/X or Z     n+                      Send_Eof
  2359.          N, Timeout      r+                      Send_Data
  2360.          Other                                   Abort
  2361.              ____ ___ __ ____ _________
  2362. +Send_Eof -- Send end of file indicator
  2363. 0    Send Z(n); if interrupting send Z(n)/D
  2364. 0        Y(n), N(n+1)    Open next file, n+      Send_File if more, or
  2365.                                                  Send_Break if no more
  2366.                                                   or if interrupt "Z".
  2367.          N, Timeout      r+                      Send_Eof
  2368.          Other                                   Abort
  2369.                ___ __ ___________
  2370. +Send_Break -- End of Transaction
  2371. 0    Send B(n)
  2372. 0        Y(n), N(0)                              Complete
  2373.          N(n), Timeout                           Send_Break
  2374.          Other                                   Abort
  2375.                     _____ ___ ______ ________ _____ ______ _____ ________
  2376. +Send_Server_Init - Entry for Server commands which expect large response.
  2377. 0    Send I(0) with parameters
  2378. 0        Y(0)            Process params          Send_Gen_Cmd
  2379.          N, Timeout      r+                      Send_Server_Init
  2380.          E               Use default params      Send_Gen_Cmd
  2381.          Other                                   Abort
  2382. 1Optional Features
  2383. +Optional Features
  2384. +Optional Features                                                       Page 51
  2385. 0
  2386.                 _____ ___ ______ ________ _____ ______ _____ ________  ___
  2387. +Send_Gen_Cmd - Entry for Server commands which expect short response (ACK)
  2388. 0    Send G, R or C(0)
  2389. 0        S(0)            Process params,
  2390.                           ACK with params, n+    Rec_File
  2391.          X(1)            Setup to type on
  2392.                           terminal, n+           Rec_Data
  2393.          Y(0)            Type data on TTY        Complete
  2394.          N, Timeout      r+                      Send_Gen_Cmd
  2395.          Other                                   Abort
  2396.              __________ __________ __ ___________
  2397. +Complete -- Successful Completion of Transaction
  2398. 0        Set n and r to 0;
  2399.          If server, reset params, enter Rec_Server_Idle
  2400.          otherwise exit
  2401.           _________ ___________ __ ___________
  2402. +Abort -- Premature Termination of Transaction
  2403. 0    Reset any open file, set n and r to 0
  2404. 0        If server, reset params, enter Rec_Server_Idle
  2405.          otherwise exit
  2406.  Exit, Logout states
  2407.          Exit or Logout
  2408. 0Note that the generic commands determine the next state as follows:
  2409. 0   1. If the command is not supported, an error packet  is  sent  and  the
  2410.        next state is "Abort".
  2411. 0   2. If  the  command generates a response which can be fit into the data
  2412.        portion of an  ACK,  an  ACK  is  sent  with  the  text  (quoted  as
  2413.        necessary) in the data portion.
  2414. 0   3. If the command generates a large response or must send a file, noth-
  2415.        ing is sent from the Rec_Server_Idle state, and the  next  state  is
  2416.        either  Send_Init  (if either no I message was received or if alter-
  2417.        nate block check types are to be used), or Open_File (if an  I  mes-
  2418.        sage  was  received  and  the  single character block check is to be
  2419.        used).
  2420. 0   4. If the command is Logout, an ACK  is  sent  and  the  new  state  is
  2421.        Logout.
  2422. 0   5. If the command is Exit, an ACK is sent and the new state is Exit.
  2423. 1Performance Extensions
  2424. +Performance Extensions
  2425. +Performance Extensions                                                  Page 52
  2426. 0
  2427.                                     CHAPTER 9
  2428. +                                   CHAPTER 9
  2429. +                                   CHAPTER 9
  2430.                              PERFORMANCE EXTENSIONS
  2431. +                            PERFORMANCE EXTENSIONS
  2432. +                            PERFORMANCE EXTENSIONS
  2433. 0The  material in this chapter was added in 1985-86 to address the inherent per-
  2434.  formance problems of a stop-and-wait protocol like Kermit.
  2435. 0
  2436.  9.1. Long Packets
  2437. +9.1. Long Packets
  2438. +9.1. Long Packets
  2439. 0A method is provided to allow the formation of long Kermit packets.   Questions
  2440.  as  to  the  desirability  or  appropriateness  of this extension to the Kermit
  2441.  protocol are not addressed.  All numbers are in decimal (base 10) notation, all
  2442.  arithmetic is integer arithmetic.
  2443. 0In  order  for  long  packets  to be exchanged, the sender must set the bit for
  2444.  Capability #5 (the LONGP bit) in the CAPAS field of  the  Send-Init  (S  or  I)
  2445.  packet,
  2446. 0     bit5 bit4 bit3 bit2 bit1 bit0
  2447.      +----+----+----+----+----+----+
  2448.      | #1 | #2 | #3 | #4 | #5 |  0 |
  2449.      +----+----+----+----+----+----+
  2450.                             ^
  2451.                             |
  2452.                           LONGP
  2453. 0and  also  furnish  the  MAXLX1 and MAXLX2 (extended length 1 and 2) fields, as
  2454.  follows:
  2455. 0        10              CAPAS+1  CAPAS+2  CAPAS+3
  2456.      ---+-------+-     -+--------+--------+--------+
  2457.         | CAPAS |  ...  | WINDO  | MAXLX1 | MAXLX2 |
  2458.      ---+-------+-     -+--------+--------+--------+
  2459.                          ^
  2460.                          |
  2461.                        (currently field 11, because CAPAS is still 1 byte)
  2462. 0where WINDO is the window size (a  separate  Kermit  protocol  extension),  and
  2463.  MAXLX1  and MAXLX2 are each a printable ASCII character in the range SP (space,
  2464.  ASCII 32) to ~ (tilde, ASCII 126), formed as follows:
  2465. 0    MAXLX1 = tochar(m / 95)
  2466.      MAXLX2 = tochar(m MOD 95)
  2467. 0(where m is the intended maximum length, / signifies integer division, and  MOD
  2468.  is  the  modulus  operator),  to indicate the longest extended-length packet it
  2469.  will accept as input.  The receiver responds with an ACK packet having the same
  2470.  bit  also  set in the CAPAS field, and with the MAXLX1 and MAXLX2 fields set to
  2471.  indicate the maximum length packet it will accept.
  2472. 0The maximum length expressible by this construct is 95 x 94 + 94, or 9024.
  2473. 1Performance Extensions
  2474. +Performance Extensions
  2475. +Performance Extensions                                                  Page 53
  2476. 0
  2477.  Since the sender can not know in advance whether the receiver is capable of ex-
  2478.  tended  headers, the Send-Init MAXL field must also be set in the normal manner
  2479.  for compatibility.
  2480. 0If the receiver responds favorably to an extended-length packet bid  (that  is,
  2481.  if  its  ACK has the LONGP bit set in the CAPAS field), then the combined value
  2482.  of its MAXLX1,MAXLX2 fields is  used.    If  the  LONGP  bit  is  set  but  the
  2483.  MAXLX1,MAXLX2 pair is missing, then the value 500 will be used by default.
  2484. 0If  the  response  is  unfavorable  (the LONGP bit is not set in the receiver's
  2485.  CAPAS field), then extended headers will not be used and the  MAXL  field  will
  2486.  supply the maximum packet length.
  2487. 0After  the Send-Init has been sent and acknowledged with agreement to allow ex-
  2488.  tended headers, all packets up to and including the B or E  packet  which  ter-
  2489.  minates  the  transaction  (and its acknowledgement) are allowed -- but not re-
  2490.  quired -- to have extended headers; extended and normal packets may  be  freely
  2491.  mixed by both Kermits.
  2492. 0The  normal  Kermit  packet length field (LEN) specifies the number of bytes to
  2493.  follow, up to and including the block check.  Since at least 3 bytes must  fol-
  2494.  low  (SEQ,  TYPE, and CHECK), a value of 0, 1, or 2 is never encountered in the
  2495.  LEN field of a valid unextended Kermit packet.  When extended packets have been
  2496.  negotiated,  the LEN field is treated as follows for the duration of the trans-
  2497.  action:
  2498. 0   - If unchar(LEN) > 2 then the packet is a normal, unextended packet.
  2499.     - If unchar(LEN) = 0 then the packet has a "Type 0" extended header.
  2500.     - If unchar(LEN) = 1 or 2, the packet is invalid and  should  cause  an
  2501.       Error.
  2502. 0"Lengths"  of  1  and  2  are  reserved for future use in Type 1 and 2 extended
  2503.  headers, yet to be specified.
  2504. 0A Type 0 extended packet has the following layout:
  2505. 0+------+-----+-----+------+-------+-------+--------+----       ----+-------+
  2506.  | MARK |     | SEQ | TYPE | LENX1 | LENX2 | HCHECK |  DATA ....    | CHECK |
  2507.  +------+-----+-----+------+-------+-------+--------+----       ----+-------+
  2508.                            | Extended Header        |
  2509. 0The blank length field (SP = tochar(0)) indicates that the  first  3  bytes  of
  2510.  what  is  normally the data field is now an extended header of Type 0, in which
  2511.  the number of bytes remaining in the packet, up  to  and  including  the  block
  2512.  check, is
  2513. 0    ________ ______
  2514. +    extended-length = (95 x unchar(LENX2)) + unchar(LENX2)
  2515. 0and  HCHECK  is  a  header  checksum, formed exactly like a Type-1 Kermit block
  2516.  check, but from the sum of the ASCII values of the SEQ, TYPE, LENX1, and  LENX2
  2517.  fields:
  2518. 1Performance Extensions
  2519. +Performance Extensions
  2520. +Performance Extensions                                                  Page 54
  2521. 0
  2522.       _
  2523. +     s = LEN + SEQ + TYPE + LENX1 + LENX2
  2524. 0                      _     _
  2525. +     HCHECK = tochar((s + ((s & 192)/64)) & 63)
  2526. 0where & is the bitwise AND operator.
  2527. 0Since  the value of the extended length field must be known accurately in order
  2528.  to locate the end of the packet and the packet block check, it  is  vital  that
  2529.  this  information  not  be  corrupted  before  it is used.  The header checksum
  2530.  prevents this.
  2531. 0                                                           ___
  2532. +The extended header, like the normal  header  itself,  is  not  prefix-encoded.
  2533.  This  is  because  it  is  used at datalink level, before decoding takes place.
  2534.  Therefore the entity responsible for building packets must leave  3  spaces  at
  2535.  the  beginning  of  the  data field, and the datalink function (spack) fills in
  2536.  LENX1, LENX2, and HCHECK based upon the data actually entered into the  packet,
  2537.  after encoding.  The packet receiving datalink function (rpack) behaves accord-
  2538.  ingly.
  2539. 0The packet block check is formed in the usual manner, based on all packet bytes
  2540.  beginning  with  LEN and ending with the last character in the data field.  The
  2541.  block check may be Type 1, 2, or 3, depending upon  what  was  negotiated,  but
  2542.  longer  packets  are  more  likely to be corrupted than shorter ones and should
  2543.  therefore have higher-order block checks if possible.  This proposal  does  not
  2544.  change the way block check type is negotiated, and does not require that Type 2
  2545.  or 3 block check be implemented.
  2546. 0With long packets, the possibility  exists  that  the  arithmetic  sum  of  the
  2547.                                      15
  2548.  characters in a packet will exceed 2  , and will overflow a 16-bit word, or be-
  2549.  come negative.  The checksum function  would  have  to  be  modified  to  guard
  2550.  against  this,  for instance by always setting the high four bits of the sum to
  2551.  zero before adding in the next byte.
  2552. 0Implementation can be a bit tricky.  The Kermit program should be set up to use
  2553.  normal,  untextended  packets  by  default -- that is, to mimic the behavior of
  2554.  original, "classic" Kermit.  Even  when  the  program  believes  itself  to  be
  2555.  capable  of  sending  and  receiving  long packets, it has no knowledge of what
  2556.  devices may lie along the communication path, whose buffers might not  be  long
  2557.  enough  to  accommodate  bursts  of  data  of the desired length.  Long packets
  2558.  should be elected when the user has explicitly elected them with a SET command.
  2559.  The current SET SEND PACKET-LENGTH <n> command will do; if the number is larger
  2560.  than 94, then the program will -- transparently to the user -- try to negotiate
  2561.  long  packets.    A finer degree of control can be accomplished by included SET
  2562.  commands to explicitly enable or disable the use of long packets.
  2563. 0Once long packets are successfully negotiated, the program should  be  prepared
  2564.  to  back  off  when errors occur, since the very size of the packets may be the
  2565.  cause of the errors.  Upon timeout or receipt of a NAK (or extra copies of  the
  2566.  previous  packet),  the  sender  should  be prepared to reconstruct the current
  2567.  packet at, say,  half  its  size,  down  to  some  reasonable  minimum,  before
  2568.  retransmission.    Even  when  the  size  itself is not the problem, this makes
  2569. 1Performance Extensions
  2570. +Performance Extensions
  2571. +Performance Extensions                                                  Page 55
  2572. 0
  2573.  retransmission less painful under noisy conditions.
  2574. 0Long packets and sliding windows may be used  at  the  same  time,  though  the
  2575.  benefits from doing so may not be worth the trouble of coding the dynamic buff-
  2576.  er allocation required (for n buffers of size m, negotiated at Send-Init time).
  2577.  It's  also  worth  noting  that the benefit/cost ratio of long packets declines
  2578.  after a length of about 1000, at which point the benefit of  additional  length
  2579.  is less than 1%, and the cost of retransmission is very high.
  2580. 0
  2581.  9.2. Sliding Windows
  2582. +9.2. Sliding Windows
  2583. +9.2. Sliding Windows
  2584. 0The sliding window extension to Kermit was proposed and developed by a group at
  2585.  The Source Telecomputing in McLean, Virginia, led by Leslie Spira and including
  2586.  Hugh  Matlock  and John Mulligan, who wrote the following material.  Like other
  2587.  extensions, this one is designed for "upward compatibility" with  Kermits  that
  2588.  do not support this extension.
  2589. 0The  windowing  protocol  as  defined  for the Kermit file transfer protocol is
  2590.  based on the main premise of continuously sending data packets up to the number
  2591.  defined by a set window size.  These data packets are continuously acknowledged
  2592.  by the receive side and the ideal transfer occurs as long as  they  are  trans-
  2593.  mitted  with good checksums, they are transmitted in sequential order and there
  2594.  are no lost data packets or acknowledgements.   The  various  error  conditions
  2595.  define  the  details  of the windowing protocol and are best examined on a case
  2596.  basis.
  2597. 0There are five stages that describe the overall sequence of events in the  Ker-
  2598.  mit  protocol.  Three of these stages deviate from the original protocol in or-
  2599.  der to add the windowing feature.  Stages 1 through 5 are briefly described  on
  2600.  the  following  page.    The  three  stages (1, 3 and 4) which deviate from the
  2601.  original protocol are then described in greater detail in the pages  that  fol-
  2602.  low.
  2603. 0
  2604.  9.2.1. Overall Sequence of Events
  2605. +9.2.1. Overall Sequence of Events
  2606. +9.2.1. Overall Sequence of Events
  2607. 0_____ _ _ _______ ___ ______ _________
  2608. +STAGE_1_-_Propose_and_Accept_Windowing
  2609.      The send side requests windowing in the transmission of  the  Send-Initiate
  2610.      (S)  packet.  The receive side accepts windowing by sending an acknowledge-
  2611.      ment (ACK packet) for the Send-Initiate packet.
  2612. 0_____ _ _ ____ ___ ______ ___________ ______
  2613. +STAGE_2_-_Send_and_Accept_File-Header_Packet
  2614.      The  send  side  transmits  the  File-Header  (F)  packet and waits for the
  2615.      receive side to acknowledge it prior to transmitting any data.
  2616. 0_____ _ _ ________ ____
  2617. +STAGE_3_-_Transfer_Data
  2618.      The  sending  routine  transmits Data (D) packets one after the other until
  2619.      the protocol window is closed.  The receiving side ACKs good  data,  stores
  2620.      data to disk as necessary and NAKs bad data.
  2621. 0    When  the  sender  receives  an ACK, the window may be rotated and the next
  2622. 1Performance Extensions
  2623. +Performance Extensions
  2624. +Performance Extensions                                                  Page 56
  2625. 0
  2626.      packet sent.  If the sender receives a NAK, the data  packet  concerned  is
  2627.      retransmitted.
  2628. 0_____ _ _ ____ ___ ______ ___________ ______
  2629. +STAGE_4_-_Send_and_Accept_End_of_File_Packet
  2630.      As the sender is reading the file for data  to  send,  it  will  eventually
  2631.      reach  the end of the file.  It then waits until all outstanding data pack-
  2632.      ets have been acknowledged, and then sends an End-of_File (Z) packet.
  2633. 0    When the receive side gets the End-of-File packet it stores the rest of the
  2634.      data to disk, closes the file, and ACKs the End-of_File packet.
  2635. 0    The protocol then returns to Stage 2, sending and acknowledging any further
  2636.      File-Header (F) packets.
  2637. 0_____ _ _ ___ __ ____________
  2638. +STAGE_5_-_End_of_Transmission
  2639.      Once the End-of-File packet has been sent and acknowledged and there are no
  2640.      more files to send, the sender transmits the End-of-Transmission (B) packet
  2641.      in  order  to  end  the  ongoing  transaction.  Once the receiver ACKs this
  2642.      packet, the transaction is ended and the logical connection closed.
  2643. 0
  2644.  _____ _ _ _______ ___ ______ _________
  2645. +Stage_1_-_Propose_and_Accept_Windowing
  2646. 0
  2647.  The initial connection as currently defined for the Kermit protocol  will  need
  2648.  to  change  only  in  terms  of  the contents of the Send-Initiate packet.  The
  2649.  receiving Kermit waits for the sending Kermit to transmit the Send-Initiate (S)
  2650.  packet and the sending packet does not proceed with any additional transmission
  2651.  until the ACK has been returned by the receiver.
  2652. 0The contents of the Send-Init packet, however, will be slightly revised.    The
  2653.  data  field of the Send-Init packet currently contains all of the configuration
  2654.  parameters.  The first six fields of the Send-Init packet are fixed as follows:
  2655. 0   1        2        3        4        5        6
  2656.    +--------+--------+--------+--------+--------+--------+
  2657.    | MAXL   | TIME   | NPAD   | PADC   | EOL    | QCTL   |
  2658.    +--------+--------+--------+--------+--------+--------+
  2659. 0Fields 7 through 10 are optional features of Kermit and fields 7 through 9 will
  2660.  also remain unchanged as defined for the existing protocol:
  2661. 0   7        8        9        10
  2662.    +--------+--------+--------+--------+
  2663.    | QBIN   | CHKT   | REPT   | CAPAS  |
  2664.    +--------+--------+--------+--------+
  2665. 0The  windowing capability constitutes a fourth capability and the fourth bit of
  2666.  the capability field will be set to 1 if the Kermit implementation  can  handle
  2667.  windowing:
  2668. 0     bit5 bit4 bit3 bit2 bit1 bit0
  2669. 1Performance Extensions
  2670. +Performance Extensions
  2671. +Performance Extensions                                                  Page 57
  2672. 0
  2673.      +----+----+----+----+----+----+
  2674.      | #1 | #2 | #3 | #4 | #5 |  0 |
  2675.      +----+----+----+----+----+----+
  2676.                        ^
  2677.                        |
  2678.                       SWC (sliding window capability)
  2679. 0The remaining fields of the Send-Init packet are either reserved for future use
  2680.  by the standard Kermit protocol or reserved  for  local  site  implementations.
  2681.  The  four  fields  following the capability field are reserved for the standard
  2682.  Kermit protocol.  The field following the capability mask is  used  to  specify
  2683.  the "Window Size":
  2684. 0        10              CAPAS+1  CAPAS+2  CAPAS+3
  2685.      ---+-------+-     -+--------+--------+--------+
  2686.         | CAPAS |  ...  | WINDO  | MAXLX1 | MAXLX2 |
  2687.      ---+-------+-     -+--------+--------+--------+
  2688.                          ^
  2689.                          |
  2690.                        (currently field 11, because CAPAS is still 1 byte)
  2691. 0WINDO is the window size to be used, encoded printably using the tochar() func-
  2692.  tion.  The window size may range from 1 to 31 inclusive.
  2693. 0The sender will specify the window size it wishes to use and the receiver  will
  2694.  reply  (in  the  ACK packet) with the window size it wishes to use.  The window
  2695.  size actually used will be the minimum of the two.   If  the  receiver  replies
  2696.  with a window size of 0 then no windowing will be done.
  2697. 0
  2698.  _____ _ _ ________ ____
  2699. +Stage_3_-_Transfer_Data
  2700. 0
  2701.  The  sequence  of events required for the transmission of data packets and con-
  2702.  firmation of receipts constitute the main functions of the windowing  protocol.
  2703.  There are four main functions which can be identified within this stage.  These
  2704.  are:
  2705. 0   - the sender's processing of the data packets,
  2706.     - the receiver's handling of incoming packets,
  2707.     - the sender's handling of the confirmations,
  2708.     - the error handling on both sides.
  2709. 0The following discussion details the specific  actions  required  for  each  of
  2710.  these  functions.  Refer to the state table at the end of this document for the
  2711.  specific action taken on a "received message" basis for the full protocol.
  2712. 0___ ________ __________ __ ____ _______
  2713. +The_Sender's_Processing_of_Data_Packets
  2714. 0The sender instigates the transmission by sending the  first  data  packet  and
  2715.  then  operating  in a cyclical mode of sending data until the defined window is
  2716.  closed.
  2717. 1Performance Extensions
  2718. +Performance Extensions
  2719. +Performance Extensions                                                  Page 58
  2720. 0
  2721.  Data to be sent must be read from  the  file,  encoded  into  the  Kermit  Data
  2722.  packet,  and  saved  in  a Send-Table.  A Send-Table entry consists of the data
  2723.  packet itself (which makes convenient the re-send of a  NAK'd  packet),  a  bit
  2724.  which  keeps  track of whether the packet has been ACK'd (the ACK'd bit), and a
  2725.  retry counter.  The table is large enough to  hold  all  the  packets  for  the
  2726.  protocol window.
  2727. 0Before  each  transmission, the input buffer is checked and input is processed,
  2728.  as described below.  Transmission is stopped if the protocol  window  "closes",
  2729.  that is, if the Send-Table is full.
  2730. 0___ __________ ________ __ ________ _______
  2731. +The_Receiver's_Handling_of_Incoming_Packets
  2732. 0The  receiver  keeps  its own table as it receives incoming data packets.  This
  2733.  allows the receiver to receive subsequent packets while it  is  waiting  for  a
  2734.  re-send  of  an erroneous or lost packet.  In other words, the incoming packets
  2735.  do not have to be received in sequential order and can still be written to disk
  2736.  in order.
  2737. 0A  Receive-Table  entry consists of the data packet, a bit which keeps track of
  2738.  whether a good version of the packet has been received (the ACK'd bit),  and  a
  2739.  retry  counter  for  the NAKs we send to request retransmissions of the packet.
  2740.  The table is large enough to hold all the packets for the protocol window.
  2741. 0The different possibilities for a received packet are:
  2742. 0   1. A new packet, the next sequential one (the usual case)
  2743.     2. A new packet, not the next sequential one (some were lost)
  2744.     3. An old packet, retransmitted
  2745.     4. An unexpected data packet
  2746.     5. Any packet with a bad checksum
  2747. 0These are now discussed separately:
  2748. 0   1. The next new packet has sequence number <one past the  latest  table
  2749.        entry>.    The packet is ACK'd, and the Receive-Table is checked for
  2750.        space.  If it is full (already contains  window_size  entries)  then
  2751.        the  oldest  entry  is written to disk.  (This entry should have the
  2752.        ACK'd bit set.  If not, the receiver aborts the file transfer.)  The
  2753.        received  packet is then stored in the Receive-Table, with the ACK'd
  2754.        bit set.
  2755. 0   2. If the packet received has sequence number in the  range  <two  past
  2756.        the latest table entry> to <window_size past the latest table entry>
  2757.        then it is a new packet, but some have been lost.  (The upper  limit
  2758.        here  represents the highest packet the sender could send within its
  2759.        protocol window.  Note that the requirement to test for this case is
  2760.        what limits the maximum window_size to half of the range of possible
  2761.        sequence numbers) We ACK the packet, and NAK all packets  that  were
  2762.        skipped.    (The skipped packets are those from <one past the latest
  2763.        table entry> to <one before the received packet>) The  Receive-Table
  2764.        is then checked.  The table may have to be rotated to accomodate the
  2765. 1Performance Extensions
  2766. +Performance Extensions
  2767. +Performance Extensions                                                  Page 59
  2768. 0
  2769.        packet, as with case 1.  (This time, several table entries may  have
  2770.        to  be written to disk.  As before, if any do not have the ACK'd bit
  2771.        set, they will trigger an abort.)  The packet is then stored in  the
  2772.        table, and the ACK'd bit set.
  2773. 0   3. A  retransmitted  packet will have sequence number in the range <the
  2774.        oldest table entry> to <the latest table  entry>.    The  packet  is
  2775.        ACK'd, then placed in the table, setting the ACK'd bit.
  2776. 0   4. A  packet with sequence number outside of the range from <the oldest
  2777.        table entry> to <window_size past the latest  table  entry>  is  ig-
  2778.        nored.
  2779. 0   5. If the packet received has a bad checksum, we must decide whether to
  2780.        generate a NAK, and if so, with what sequence number.  The best  ac-
  2781.        tion  may  depend  on the configuration and channel error rate.  For
  2782.        now, we adopt the following heuristic:  If there are unACK'd entries
  2783.        in  our  Receive-Table, we send a NAK for the oldest one.  Otherwise
  2784.        we ignore the packet.  (Notice that this  will  occur  in  a  common
  2785.        case:    when  things  have  been going smoothly and one packet gets
  2786.        garbled.  In this case, when we later receive  the  next  packet  we
  2787.        will NAK for this one as described under Case 2 above.)
  2788. 0___ ________ ________ __ _____________
  2789. +The_Sender's_Handling_of_Confirmations
  2790. 0The  sender's  receipt of confirmations controls the rotation of the Send-Table
  2791.  and normally returns the sender to  a  sending  state.    The  sender's  action
  2792.  depends  on  the  packet  checksum,  the type of confirmation (ACK or NAK), and
  2793.  whether the  confirmation  is  within  the  high  and  low  boundaries  of  the
  2794.  Send-Table.
  2795. 0If the checksum is bad the packet is ignored.
  2796. 0When  the  sender receives an ACK, the sequence number is examined.  If the se-
  2797.  quence number is outside of the current table boundaries, then the ACK is  also
  2798.  ignored.  If the sequence number is inside of the current table boundaries then
  2799.  the ACK'd bit for that packet is marked.  If the entry is at the low  boundary,
  2800.  this  enables  a  "rotation"  of the table.  The low boundary is changed to the
  2801.  next sequential entry for which the ACK'd bit is not set.  This frees space  in
  2802.  the table to allow further transmissions.
  2803. 0When  the  sender receives a NAK, the table boundaries are checked.  A NAK out-
  2804.  side of the table boundary is ignored and a NAK inside the table  boundary  in-
  2805.  dicates  that  the  sender must re-send the packet.  The sender first tests the
  2806.  packet's retry counter against the retry threshold.  If the threshold has  been
  2807.  reached,  then  the  transfer is stopped (by going to the Abort state).  Other-
  2808.  wise, the retry counter is incremented and the packet re-sent.
  2809. 1Performance Extensions
  2810. +Performance Extensions
  2811. +Performance Extensions                                                  Page 60
  2812. 0
  2813.  _____ ________ ___ ____ _____
  2814. +Error_Handling_for_Both_Sides
  2815. 0Three situations are discussed here:  Sender timeout, Receiver timeout, and in-
  2816.  valid packets.
  2817. 0If  certain  packets are lost, each side may "hang", waiting for the other.  To
  2818.  get things moving when this happens  each  may  have  a  "timeout  limit",  the
  2819.  longest they will wait for something from the other side.
  2820. 0If  the  sender's  timeout condition is triggered, then it will send the oldest
  2821.  unACK'd packet.  This will be the first one in the Send-Table.
  2822. 0If the receiver's timeout condition is triggered, then it will send a  NAK  for
  2823.  the  "most  desired  packet".    This  is  defined as either the oldest unACK'd
  2824.  packet, or if none are unACK'd, then the next packet to be  received  (sequence
  2825.  number  <latest  table  entry plus one>).  The packet retry count is not incre-
  2826.  mented by this NAK; instead we depend on the  timeout  retry  count,  discussed
  2827.  next.
  2828. 0For  either the sender or receiver, the timeout retry count is incremented each
  2829.  time a timeout occurs.  If the timeout retry limit is exceeded  then  the  side
  2830.  aborts  the  file  transfer.  Each side resets the retry count to zero whenever
  2831.  they receive a packet.
  2832. 0In addition, as with the existing Kermit, any invalid packet types received  by
  2833.  either side will cause an Error packet and stop the file transfer.
  2834. 0
  2835.  _____ _ _ ____ ___ ______ ___ __ ____ ______
  2836. +Stage_4_-_Send_and_Accept_End_of_File_Packet
  2837. 0
  2838.  There  are several ways to end the file transfer.  The first is the normal way,
  2839.  when the sender encounters an end-of-file condition when reading  the  file  to
  2840.  get a packet for transmission.  The second is because of a sender side user in-
  2841.  terrupt.  The third is because of a receiver side  user  interrupt.    Both  of
  2842.  these  cause  the  received  file to be discarded.  In addition either side may
  2843.  stop the transfer with an Error packet if an  unrecoverable  error  is  encoun-
  2844.  tered.
  2845. 0______ ___ __ ____ ________
  2846. +Normal_End_of_File_Handling
  2847. 0When  the  sender  reaches the end of file, it must wait until all data packets
  2848.  have been acknowledged before sending the End-of-File (Z) packet.  To  do  this
  2849.  it must be able to check the end-of-file status when it processes ACKs.  If the
  2850.  ACK causes the Send-Table to be emptied and the end-of-file has  been  reached,
  2851.  then  a  transition  is  made to the Send_Eof state which sends the End_of_File
  2852.  packet.
  2853. 0When the receiver gets the End_of_File packet, it writes the  contents  of  the
  2854.  Receive-Table  to  the  file  (suitably  decoded) and closes the file.  (If any
  2855.  entries do not have the ACK'd bit set, or if errors occur in writing the  file,
  2856.  the  receiver  aborts  the file transfer.)  If the operation is successful, the
  2857. 1Performance Extensions
  2858. +Performance Extensions
  2859. +Performance Extensions                                                  Page 61
  2860. 0
  2861.  receiver sends an ACK.  It then sets its sequence  number  to  the  End_of_File
  2862.  packet sequence number and goes to Rcv_File state.
  2863. 0
  2864.  ____ ________ _____________
  2865. +File_Transfer_Interruptions
  2866. 0
  2867.  ______ ____ _________
  2868. +Sender_User_Interrupt
  2869.      Whenever the sender checks for input from the data communications line,  it
  2870.      should also check for user input.  If that indicates that the file transfer
  2871.      should be stopped, the sender goes directly to the Send_Eof state and sends
  2872.      an  End_of_File  packet  with  the Discard indication.  It will not have to
  2873.      wait for outstanding packets to be ACK'd.
  2874. 0    When the receiver gets the End_of_File packet with the  Discard  indication
  2875.      it  discards  the  file, sets its sequence number to the End_of_File packet
  2876.      sequence number, and goes to RcvFile state.
  2877. 0________ ____ _________
  2878. +Receiver_User_Interrupt
  2879.      Whenever  the  receiver checks for input from the data communications line,
  2880.      it also should check for user input.   If  that  indicates  that  the  file
  2881.      transfer  should be stopped, the receiver sets an "interrupt indication" of
  2882.      X (for "stop this file transfer") or of Z (for  "stop  the  batch  of  file
  2883.      transfers").   When the receiver later sends an ACK, it places an X or Z in
  2884.      the data field.
  2885. 0    When the sender gets this ACK, it goes to the Send_Eof state and sends  the
  2886.      End_of_File packet with the Discard indication, as above.
  2887. 0    When  the receiver gets the End_of_File packet with the Discard indication,
  2888.      it discards the file, sets its sequence number to  the  End_of_File  packet
  2889.      sequence number, and goes to RcvFile state.
  2890. 0
  2891.  ___ _____ ________ ____________
  2892. +Low_Level_Protocol_Requirements
  2893. 0
  2894.  The windowing protocol makes certain assumptions about the underlying transmis-
  2895.  sion and reception mechanism.
  2896. 0First, it must provide a full-duplex channel so that messages may be  sent  and
  2897.  received simultaneously.
  2898. 0Second,  it  will prove advantageous to be able to buffer several received mes-
  2899.  sages at the low level before processing them at the Kermit level.  This is for
  2900.  two  reasons.  The first is that the Kermit windowing level of the protocol may
  2901.  take a while to process one input, and meanwhile  several  others  may  arrive.
  2902.  The  second  reason is to support XON/XOFF flow control.  If Kermit receives an
  2903.  XOFF from the data communications line, it must wait for an XON before  sending
  2904.  its  packet.  While it is waiting, the low level receive must be able to accept
  2905.  input.  Otherwise a deadlock situation could arise with  each  side  flow  con-
  2906.  trolled, waiting for the other.
  2907. 1Performance Extensions
  2908. +Performance Extensions
  2909. +Performance Extensions                                                  Page 62
  2910. 0
  2911.  ______ _________ ________ _____ _____
  2912. +Kermit_Windowing_Protocol_State_Table
  2913. 0
  2914.  The  following  table shows the inputs expected, the actions performed, and the
  2915.  succeeding states for the Send_Data_Windowing and Rcv_Data_Windowing states.
  2916. 0If both sides agree on windowing in the Send Init  exchange,  then  instead  of
  2917.  entering  the  old  Send_Data or Rcv_Data states from Send_File or Rcv_File, we
  2918.  enter the new Send_Data_Windowing or Rcv_Data_Windowing.
  2919. 0SEND_DATA_WINDOWING (SDW)
  2920. 0_____ ___                ______                          ____ _____
  2921. +Rec'd_Msg                Action                          Next_State
  2922. 0No input/Window closed  (1) Wait for input                   SDW
  2923.  No input/Window open    (2) Read file, encode packet,        SDW
  2924.                              Place in table, mark unACK'd,
  2925.                              Send packet
  2926. 0ACK/ X or Z             (3) set interrupt indicator (X/Z)  Send_Eof
  2927.  ACK/outside table        -ignore-                            SDW
  2928.  ACK/inside table        (4) mark pkt ACK'd,         SDW or Send_Eof
  2929.                              if low rotate table,
  2930.                              if file eof & table empty
  2931.                                 then goto Send_Eof
  2932. 0NAK/outside table        -ignore-                            SDW
  2933.  NAK/inside table        (5) test retry limit,                SDW
  2934.                              re-send DATA packet
  2935. 0Bad checksum            -ignore-                             SDW
  2936. 0Timeout                 (6) re-send oldest unACK'd pkt       SDW
  2937. 0User interrupt          (7) set interrupt indicator (X/Z)  Send_Eof
  2938. 0Other                   (8) send Error                      Quit
  2939. 0RCV_DATA_WINDOWING (RDW)
  2940. 0_____ ___                ______                          ____ _____
  2941. +Rec'd_Msg                Action                          Next_State
  2942. 0DATA/new                (1) send ACK                         RDW
  2943.                              if table full: file & rotate
  2944.                              store new pkt in table
  2945.  DATA/old                (2) send ACK, store in table         RDW
  2946.  DATA/unexpected         -ignore-                             RDW
  2947. 0Z/discard               (3) discard file                   Rcv_File
  2948.  Z/                      (4) write table to file & close    Rcv_File
  2949.                              if OK send ACK, else Error     or Quit
  2950. 1Performance Extensions
  2951. +Performance Extensions
  2952. +Performance Extensions                                                  Page 63
  2953. 0
  2954.  Bad checksum            (5) send NAK for oldest unACK'd      RDW
  2955. 0Timeout                 (6) send NAK for most desired pkt    RDW
  2956. 0User Interrupt          (7) Set interrupt indicator X or Z   RDW
  2957. 0Other                   (8) send Error pkt                  Quit
  2958. 0
  2959.  9.2.2. Questions and Answers about Sliding Windows
  2960. +9.2.2. Questions and Answers about Sliding Windows
  2961. +9.2.2. Questions and Answers about Sliding Windows
  2962. 0Q.
  2963. +Q.
  2964. +Q.  What is the purpose of the "windowing" extension?
  2965. 0A.
  2966. +A.
  2967. +A.  The object is to speed up file transfers using Kermit.  The  increase  will
  2968.      be  especially  noticeable  over  the  data  networks  (such as Telenet and
  2969.      Tymnet) and over connections using satellite links.  This is because  there
  2970.      are long communications delays over these connections.
  2971. 0Q.
  2972. +Q.
  2973. +Q.  How does it work?
  2974. 0A.
  2975. +A.
  2976. +A.  Basically,  it  allows you to send several packets out in a row before get-
  2977.      ting the first acknowledgment back.  The number of packets that can be sent
  2978.      out is set by the "window size", hence the name windowing.
  2979. 0Q.
  2980. +Q.
  2981. +Q.  Could you explain in more detail?
  2982. 0A.
  2983. +A.
  2984. +A.  Right  now, a system sending a file transmits one packet of data, then does
  2985.      nothing more until it gets back an acknowledgment that the packet has  been
  2986.      received.    Once  it  gets  an acknowledgment, it sends the next packet of
  2987.      data.  Over standard direct-dial land-based phone lines,  the  transmission
  2988.      delays  are  relatively small.  However, the public data networks or satel-
  2989.      lite links can introduce delays of up to several seconds round trip.  As  a
  2990.      result, the sending system ends up spending much more time waiting than ac-
  2991.      tually sending data.
  2992. 0    With the new windowing enhancement, the sending system will be able to keep
  2993.      sending data continuously, getting the acknowledgments back later.  It only
  2994.      has to stop sending data if it reaches the  end  of  the  current  "window"
  2995.      without  getting  an  acknowledgment  for  the  first packet in the current
  2996.      "window".
  2997. 0Q.
  2998. +Q.
  2999. +Q.  What size is the "window"?
  3000. 0A.
  3001. +A.
  3002. +A.  The window size can vary depending on what the two ends of  the  connection
  3003.      agree  on.  The suggested standard window size will be 8 packets.  The max-
  3004.      imum is 31 packets.
  3005. 0    The Kermit sequence numbering is modulo 64 (it "wraps" back to the 1st  se-
  3006.      quence  number after the 64th sequence number).  It is helpful to limit the
  3007.      maximum window size to 31 to avoid problems  (ambiguous  sequence  numbers)
  3008.      under certain error conditions.
  3009. 1Performance Extensions
  3010. +Performance Extensions
  3011. +Performance Extensions                                                  Page 64
  3012. 0
  3013.  Q.
  3014. +Q.
  3015. +Q.  Is windowing in effect throughout a Kermit session?
  3016. 0A.
  3017. +A.
  3018. +A.  No,  it  is  only  in effect during the actual data transfer (data packets)
  3019.      portion of a file transfer.  Windowing begins with the first data packet (D
  3020.      packet type), and stops when you get an End-of-File packet (Z packet type).
  3021. 0Q.
  3022. +Q.
  3023. +Q.  Why does it stop when you get to the End-of-File packet?
  3024. 0A.
  3025. +A.
  3026. +A.  This is done primarily to avoid having more than one file open at once.
  3027. 0Q.
  3028. +Q.
  3029. +Q.  Why  will  windowing  be  especially helpful at higher baud rates over com-
  3030.      munications paths that have delays?
  3031. 0A.
  3032. +A.
  3033. +A.  As you increase the baud rate, the  transmission  speed  of  the  data  in-
  3034.      creases, but you do not change the delay caused by the communications path.
  3035.      As a result, the delay becomes more and more significant.
  3036. 0    Assume, for example, that your communications path introduces a delay of  1
  3037.      second  each  way  for  packets, for a total delay of 2 seconds round trip.
  3038.      Assume also that your packets have 900 bits in  them  so  it  takes  you  3
  3039.      seconds to send a packet at 300 baud (this is roughly equivalent to a typi-
  3040.      cal Kermit packet).
  3041. 0    WITHOUT windowing, here is what happens:
  3042. 0    If at 300 baud you transmitted data for 3 seconds (sending 900 bits),  then
  3043.      waited  2 seconds for each acknowledgment, your throughput would be roughly
  3044.      180 baud.  (Total time for each transmission = 5 seconds.  900/5 = 180).
  3045. 0    However, if you went to 2400 baud, you would transmit data for 3/8  second,
  3046.      then  wait 2 seconds for an acknowledgment.  (Total time for each transmis-
  3047.      sion = 2 and 3/8 seconds).  The throughput would increase only to about 378
  3048.      baud. (900 / 2.375 = 378).
  3049. 0    The delay becomes the limiting factor; in this case, with this packet size,
  3050.      the delay sets an outside limit of 450 baud (900 / 2 second delay  =  450),
  3051.      no matter how fast the modem speed.
  3052. 0    WITH  windowing,  the throughput should be close to the actual transmission
  3053.      speed.  It should be possible to send data nearly continuously.  The  exact
  3054.      speed  will  depend  on the window size, length of transmission delays, and
  3055.      error rate.
  3056. 0Q.
  3057. +Q.
  3058. +Q.  Are there any new packet types introduced by this extension?
  3059. 0A.
  3060. +A.
  3061. +A.  No, the only change is to the contents of the Send-Init packet, to  arrange
  3062.      for  windowing if both sides can do it.  If either side cannot, Kermit will
  3063.      work as it does now.  Adding an extension such as this was provided for  in
  3064.      the  original Kermit definition.  See section 3 of the windowing definition
  3065.      for details.
  3066. 0Q.
  3067. +Q.
  3068. +Q.  On the receive side, in section 4.2, why does the definition say that writ-
  3069. 1Performance Extensions
  3070. +Performance Extensions
  3071. +Performance Extensions                                                  Page 65
  3072. 0
  3073.      ing to disk is done when the Receive-Table becomes full rather than as soon
  3074.      as you get a good packet?
  3075. 0A.
  3076. +A.
  3077. +A.  The definition was phrased this way because  it  makes  the  logic  of  the
  3078.      receive side clearer and simpler to implement.
  3079. 0    Actually,  you  could  also write a packet to disk when it is a good packet
  3080.      and it is the earliest entry in the receive table.  This approach  has  the
  3081.      disadvantage that you don't know at this point that the sender has received
  3082.      your ACK, so you have to be prepared to handle the same packet later on  if
  3083.      the  sender never gets the ACK, times out, and sends the same packet again.
  3084.      Thus you have to be prepared to deal with packets previous to  the  current
  3085.      window; you will have to ACK such a packet if it has been received properly
  3086.      before.
  3087. 0    By writing packets to disk only when the receive table becomes  full,  (the
  3088.      oldest  packet)  you  know that the sender has received your ACK (otherwise
  3089.      the sender could not have rotated the window to the n+1  position  to  send
  3090.      the  current  packet, where n is the window size).  This makes it very easy
  3091.      to stay in synch with the sender.  The disadvantage  of  this  approach  is
  3092.      that  when you receive the End-of-File packet, you have to take the time to
  3093.      write all the remaining packets in the Receive-Table to disk.
  3094. 0Q.
  3095. +Q.
  3096. +Q.  Could you briefly explain what happens if a single packet gets corrupted?
  3097. 0A.
  3098. +A.
  3099. +A.  In essence, the receiver will ignore the bad packet.  When it gets the next
  3100.      good  packet,  it  will  realize (because packets are numbered) that one or
  3101.      more packets were lost, and NAK those packets.  The receiver  continues  to
  3102.      accept good data.
  3103. 0    As  long as the sender's window does not become "blocked", the only loss of
  3104.      throughput will be the time it takes to transmit the NAK'd packets.
  3105. 0Q.
  3106. +Q.
  3107. +Q.  There are currently two proposals for Kermit extensions: the Windowing  ex-
  3108.      tension  and a proposal for extended packet lengths.  What are the relative
  3109.      advantages  and  disadvantages  of  sliding  windows  and  extended  packet
  3110.      lengths?
  3111. 0A.
  3112. +A.
  3113. +A.  What is best depends on the exact conditions and systems involved in a par-
  3114.      ticular file transfer.  There are some general rules however.
  3115. 0    Windowing helps more and more as the communications path delays get longer.
  3116. 0    Windowing is also more and more helpful as the baud rate goes up.
  3117. 0    Increased packet length is most helpful on circuits with low  error  rates.
  3118.      If the error rate is high, it is difficult for a long packet to get through
  3119.      uncorrupted.  Also, it then  takes  longer  to  re-transmit  the  corrupted
  3120.      packet.
  3121. 0    On  some  machines, the CPU time to process a packet is relatively constant
  3122.      no matter what the packet length, so longer packets can reduce CPU time.
  3123. 1Performance Extensions
  3124. +Performance Extensions
  3125. +Performance Extensions                                                  Page 66
  3126. 0
  3127.  Q.
  3128. +Q.
  3129. +Q.  Are extended packet lengths and sliding windows mutually exlusive?
  3130. 0A.
  3131. +A.
  3132. +A.  No, there is no real reason that they would have to be.    As  a  practical
  3133.      matter,  it  is slightly easier to implement windowing if you know the max-
  3134.      imum packet size ahead of time, since you can then just  use  an  array  to
  3135.      store  your  data.    In standard Kermit, you know automactically that your
  3136.      maximum packet length is 94, so you can just go ahead and dimension an  ar-
  3137.      ray at 94 by Window-size.
  3138. 0    If you are going to use both extended packet length and windowing, you need
  3139.      to select the maximum packet length and window-size so that the combination
  3140.      does not exceed the available memory for each side of the transfer.
  3141. 0    In  addition, it is possible to see the desired relationship between packet
  3142.      size and windowing for various baud rates and communications delays.    For
  3143.      the  common  case  of  an error corrected by one retransmission of the cor-
  3144.      rupted packet, the minimum window size  needed  for  continuous  throughput
  3145.      (the window never gets "blocked") can be calculated by:
  3146. 0                    4 x delay x baud rate
  3147.        WS  >   1 +  ------------------------
  3148.                         packet-size x 10          (this is the # of bits)
  3149. 0    Windowing  always  helps  (the minimal continuous throughput window size is
  3150.      always greater than 1).
  3151. 0    In the above equation, the "4" derives  from  the  fact  that  a  corrupted
  3152.      packet has 4 transit times involved:
  3153. 0       - Original (bad checksum) packet
  3154.         - NAK for the packet
  3155.         - Retransmission of packet
  3156.         - ACK for retransmission.
  3157. 0    All of this must happen before the window becomes blocked.
  3158. 0    The  "delay"  is  the  effective maximum one-way communications path delay,
  3159.      which includes any CPU delays.
  3160. 0    Strictly speaking, the "packet-size" should have  the  length  of  the  ACK
  3161.      packets added to it.
  3162. 0    As an example, if you assume a 2-second (one-way) delay, at 1200 baud, with
  3163.      a packet size of 94, the minimum  window  size  for  continuous  throughput
  3164.      would be:
  3165. 0              4 x 2 x 1200
  3166.         WS  >  ------------    =   10.2
  3167.                  94 x 10
  3168. 0    Under  these  circumstances, a window size of at least 11 should be chosen,
  3169.      if possible.
  3170. 1Performance Extensions
  3171. +Performance Extensions
  3172. +Performance Extensions                                                  Page 67
  3173. 0
  3174.  9.2.3. More Q-and-A About Windows
  3175. +9.2.3. More Q-and-A About Windows
  3176. +9.2.3. More Q-and-A About Windows
  3177. 0While reading the following questions and answers, keep in mind that the Kermit
  3178.  windowing  definiton was developed to handle a common situation of long circuit
  3179.  delays with possible moderate error rates.  Kermit does not need this  type  of
  3180.  extension  for  clean  lines  with  insignificant delays - Kermit could be left
  3181.  alone, or use Extended Packet Lengths, in such environments.
  3182. 0Long delays with significant error rates will occur under two obvious and  com-
  3183.  mon conditions:
  3184. 0   1. Local  phone  line  (of  uncertain  quality) to Public Data Networks
  3185.        (such as Telenet).
  3186. 0   2. Satellite phone links.  These  often  occur  with  the  lower-priced
  3187.        phone  services,  which often also have noisier lines.  In addition,
  3188.        satellite links will increase as more people need to  transfer  data
  3189.        overseas.
  3190. 0The  above  conditions  will  become more common, as well increased baud rates,
  3191.  which make the delays more significant.
  3192. 0As an aside, note that the benefit of Extended Packet Lengths over  the  Public
  3193.  Data  Networks  is  limited  by the number of outstanding bytes the PDN allows.
  3194.  (Internally, the PDNs require end-to-end acknowledgement.  They use  their  own
  3195.  windowing  system within the network.)  I don't currently know the exact impact
  3196.  of this.
  3197. 0Now on to the questions...
  3198. 0Q.
  3199. +Q.
  3200. +Q.  Can sliding windows be done on half-duplex channels?  Are any modifications
  3201.      to the proposal required?
  3202. 0A.
  3203. +A.
  3204. +A.  An underlying assumption in the development of windowing was that there was
  3205.      a full-duplex channel.
  3206. 0    The intent of windowing is to try to keep the sender  continuously  sending
  3207.      data.   Obviously, this is not possible on a half-duplex channel.  A better
  3208.      solution for half-duplex channels  would  be  to  use  an  extended  packet
  3209.      length.
  3210. 0    An  attempt  to  use windowing on half-duplex really is just a way of doing
  3211.      extended packet lengths.  The sender would send out  a  group  of  packets,
  3212.      then wait and get a group of ACKS.  It would be better to simply send out a
  3213.      large packet, which would have less overhead.
  3214. 0Q.
  3215. +Q.
  3216. +Q.  Is the cost in complexity for sliding windows worth the increase in perfor-
  3217.      mance?
  3218. 0A.
  3219. +A.
  3220. +A.  Under  the conditions described above (long delays and possibly significant
  3221.      error rates) windowing can increase performance by a factor  of  2,  3,  or
  3222.      more,  especially at higher baud rates.  This increase is necessary to make
  3223. 1Performance Extensions
  3224. +Performance Extensions
  3225. +Performance Extensions                                                  Page 68
  3226. 0
  3227.      Kermit viable under some conditions.  With classic Kermit over  the  Public
  3228.      Data  Networks,  I  have  had througput as low as 250 baud over a 1200 baud
  3229.      circuit (with a negligible error rate).  Windowing should allow  throughput
  3230.      close to the maximum baud rate.
  3231. 0    Windowing is most helpful when the delay is significant in relation to data
  3232.      sending time.  Any delay becomes more significant as users move  to  higher
  3233.      baud rates (2400 baud and beyond).
  3234. 0    The  complexity  of  implementing  windowing has yet to be fully evaluated.
  3235.      The first implementation (for the IBM  PC  using  C-Kermit)  proved  to  be
  3236.      fairly  manageable.  It appears that the windowing logic can be implemented
  3237.      so that Kermit Classic uses the same code, but with a  window  size  of  1,
  3238.      which should avoid having to keep separate sections of code.
  3239. 0    The  windowing  definiton was developed with the idea of keeping changes to
  3240.      Kermit to a minimum.  No new packet types were  developed,  ACKs  and  NAKS
  3241.      were  kept  the  same,  and  windowing is in effect only during actual data
  3242.      transfer (D packets).  We tried to define the protocol  so  that  a  window
  3243.      size of 1 was the same as the current classic Kermit.
  3244. 0    These  factors should help reduce the complexity of implementing windowing.
  3245.      We currently have a working implementation of Kermit for the IBM  PC  going
  3246.      through testing.
  3247. 0    It's fun to see the modem "Send" light stay on constantly!
  3248. 0Q.
  3249. +Q.
  3250. +Q.  Why doesn't the Windowing proposal use a "bulk ACK"?
  3251. 0A.
  3252. +A.
  3253. +A.  There  are a couple of possibilities for ways to use some sort of "bulk" or
  3254.      combined ACK.  We looked at them when developing the Windowing  definition.
  3255.      We did not see any advantages that outweighed the disadvantages.
  3256. 0    Here are two possible ways of changing how ACKs would work:
  3257. 0       1. An  ACK for any packet would also ACK all previous packets.  The
  3258.            concept that an ACK would also ACK all  previous  packets  seems
  3259.            attractive  at  first, since it would appear to reduce overhead.
  3260.            However, it has a major drawback in that you then must  re-synch
  3261.            when  you  get errors.  This is because, once you have an error,
  3262.            you have to send a NAK, then stop and wait for a re-transmission
  3263.            of the NAK'd packet, before you send out any more ACKs.  (If you
  3264.            sent out an ACK for a later packet, it would imply that you  had
  3265.            received  the  NAK'd  packet.    Not  until  you  safely get the
  3266.            re-transmission can you go ahead.)  This would negate one of the
  3267.            nicest  parts  of  windowing as it is defined now, which is that
  3268.            the sender can transmit  continuously,  including  during  error
  3269.            recovery,  as  long  as  the window does not become blocked.  It
  3270.            does not appear to us that the reduction in the number  of  ACKs
  3271.            sent  is  worth  this penalty.  In addition, this is a departure
  3272.            from the way ACKs in Kermit work now.  It seemed best to make as
  3273.            few  changes  to Kermit as possible.  If this facility turns out
  3274. 1Performance Extensions
  3275. +Performance Extensions
  3276. +Performance Extensions                                                  Page 69
  3277. 0
  3278.            to be useful, it would be better to introduce a new packet  type
  3279.            (or  other  means  of  distinguishing  regular  ACKs  from "Bulk
  3280.            ACKS").
  3281. 0       2. A new "Bulk ACK" packet type could be developed.  This  did  not
  3282.            seem  to  us to be a good idea, since it required defining a new
  3283.            packet type.  We were trying to fit windowing  in  with  as  few
  3284.            changes  to  Kermit  as  possible.    A "Bulk ACK", in which one
  3285.            packet could contain a whole string of ACKs and NAKs, also seems
  3286.            like  a  good  idea at first.  The penalty here is a little more
  3287.            subtle.  First, if you lose a "Bulk ACK" packet, you  lose  more
  3288.            information  and  it takes longer to get things flowing smoothly
  3289.            again.  Second, and probably more importantly, efficient window-
  3290.            ing  depends  on  the window never becoming "blocked" (i.e., the
  3291.            sender can always keep sending).  A "Bulk ACK"  interferes  with
  3292.            this to some extent, because if you have a long delay, the "Bulk
  3293.            ACK" with its multiple individual ACKs may not get back  to  the
  3294.            sender  in  time  to  prevent  the window from becoming blocked.
  3295.            With the current definition of windowing, returning an  ACK  for
  3296.            each  packet  gets  the  ACKs (or NAKs) to the sender as soon as
  3297.            possible.  This provides the best chance for keeping the  window
  3298.            open  so  that the sender can transmit continually.  Once again,
  3299.            remember the conditions under which windowing  is  most  useful:
  3300.            long  delays  with  significant  error  rates.  Under these con-
  3301.            ditions, individual ACKs have advantages.  If  these  conditions
  3302.            don't apply, it may not be necessary to use windowing, or it may
  3303.            be better to use extended packet lengths.
  3304. 1Kermit Commands
  3305. +Kermit Commands
  3306. +Kermit Commands                                                         Page 70
  3307. 0
  3308.                                    CHAPTER 10
  3309. +                                  CHAPTER 10
  3310. +                                  CHAPTER 10
  3311.                                  KERMIT COMMANDS
  3312. +                                KERMIT COMMANDS
  3313. +                                KERMIT COMMANDS
  3314. 0The following list of Kermit commands and terms is suggested.  It  is  not  in-
  3315.  tended  to  recommend  a particular style of command parsing, only to promote a
  3316.  consistent vocabulary, both in documentation and in choosing the names for com-
  3317.  mands.
  3318. 0
  3319.  10.1. Basic Commands
  3320. +10.1. Basic Commands
  3321. +10.1. Basic Commands
  3322. 0SEND    This verb tells a Kermit program to send one or more files from its own
  3323.          file structure.
  3324. 0RECEIVE This verb should tell a Kermit program to expect one or more  files  to
  3325.          arrive.
  3326. 0GET     This  verb  should  tell a user Kermit to send one or more files.  Some
  3327.          Kermit implementations have separate RECEIVE and GET  commands;  others
  3328.          use RECEIVE for both purposes, which creates confusion.
  3329. 0Since  it  can be useful, even necessary, to specify different names for source
  3330.  and destination files, these commands should take operands as follows (optional
  3331.  operands in [brackets]):
  3332. 0SEND local-source-filespec [remote-destination-filespec]
  3333.          If the destination file specification is included, this will go in  the
  3334.          file header packet, instead of the file's local name.
  3335. 0RECEIVE [local-destination-filespec]
  3336.          If the destination filespec is given, the incoming file will be  stored
  3337.          under that name, rather than the one in the file header pakcet.
  3338. 0GET remote-source-filespec [local-destination-filespec]
  3339.          If the destination filespec is given, the incoming file will be  stored
  3340.          under that name, rather than the one in the file header packet.
  3341. 0                                                                   ___
  3342. +If  a file group is being sent or received, alternate names should not be used.
  3343.  It may be necessary to adopt  a  multi-line  syntax  for  these  commands  when
  3344.  filespecs may contain characters that are also valid command field delimiters.
  3345. 0
  3346.  10.2. Program Management Commands
  3347. +10.2. Program Management Commands
  3348. +10.2. Program Management Commands
  3349. 0EXIT    Leave  the  Kermit  program, doing whatever cleaning up must be done --
  3350.          deassigning of devices, closing of files, etc.
  3351. 0QUIT    Leave the Kermit program without cleaning up, in such a  manner  as  to
  3352.          allow further manipulation of the files and devices.
  3353. 0PUSH    Preserve  the  current  Kermit environment and enter the system command
  3354.          processor.
  3355. 1Kermit Commands
  3356. +Kermit Commands
  3357. +Kermit Commands                                                         Page 71
  3358. 0
  3359.  TAKE    Read and execute Kermit program commands from a local file.
  3360. 0LOG     Specify a log for file transfer transactions, or for  terminal  session
  3361.          logging.
  3362. 0
  3363.  10.3. Terminal Emulation Commands
  3364. +10.3. Terminal Emulation Commands
  3365. +10.3. Terminal Emulation Commands
  3366. 0CONNECT This  verb,  valid  only  for a local Kermit, means to go into terminal
  3367.          emulation mode; present the illusion of being directly connected  as  a
  3368.          terminal  to the remote system.  Provide an "escape character" to allow
  3369.          the user to "get back" to the local system.  The escape character, when
  3370.          typed,  should take a single-character argument; the following are sug-
  3371.          gested:
  3372. 0            0   (zero) Transmit a NUL
  3373.              B   Transmit a BREAK
  3374.              C   Close the connection, return to local Kermit command level
  3375.              P   Push to system command processor
  3376.              Q   Quit logging (if logging is being done)
  3377.              R   Resume logging
  3378.              S   Show status of connection
  3379.              ?   Show the available arguments to the escape character
  3380.               _ ______ ____  __  ___  ______  _________
  3381. +            (a second copy  of  the  escape  character):  Transmit  the  escape
  3382.                  character itself
  3383. 0        Lower  case equivalents should be accepted.  If any invalid argument is
  3384.          typed, issue a beep.
  3385. 0Also see the SET command.
  3386. 0
  3387.  10.4. Special User-Mode Commands
  3388. +10.4. Special User-Mode Commands
  3389. +10.4. Special User-Mode Commands
  3390. 0These commands are used only by Users of Servers.
  3391. 0BYE     This command sends a message to the remote server to  log  itself  out,
  3392.          and upon successful completion, terminate the local Kermit program.
  3393. 0FINISH  This  command  causes  the remote server to shut itself down gracefully
  3394.          without logging out its job, leaving the local Kermit at Kermit command
  3395.          level, allowing the user to re-CONNECT to the remote job.
  3396. 0
  3397.  10.5. Commands Whose Object Should Be Specified
  3398. +10.5. Commands Whose Object Should Be Specified
  3399. +10.5. Commands Whose Object Should Be Specified
  3400. 0Some  Kermit implementations include various local file management services and
  3401.  commands to invoke them.  For instance, an implementation might  have  commands
  3402.  to  let  you  get  directory  listings, delete files, switch disks, and inquire
  3403.  about free disk space without having to exit and restart the program.   In  ad-
  3404.  dition,  remote  servers may also provide such services.  A user Kermit must be
  3405.  able to distinguish between commands aimed at its own system and those aimed at
  3406. 1Kermit Commands
  3407. +Kermit Commands
  3408. +Kermit Commands                                                         Page 72
  3409. 0
  3410.  the remote one.  When any confusion is possible, such a command may be prefixed
  3411.  by one of the following "object prefixes":
  3412. 0REMOTE  Ask the remote Kermit server to provide this service.
  3413. 0LOCAL   Perform the service locally.
  3414. 0If the "object prefix" is omitted, the command should be executed locally.  The
  3415.  services include:
  3416. 0LOGIN   This  should  be  used  in its timesharing sense, to create an identity
  3417.          ("job", "session", "access", "account") on the system.
  3418. 0LOGOUT  To terminate a session that was initiated by LOGIN.
  3419. 0COPY    Make a new copy of the specified file with the specified name.
  3420. 0CWD     Change Working Directory.  This is ugly, but more  natural  verbs  like
  3421.          CONNECT and ATTACH are too imprecise.  CWD is the ARPAnet file transfer
  3422.          standard command to invoke this function.
  3423. 0DIRECTORY
  3424.          Provide  a  list  of  the  names, and possibly other attributes, of the
  3425.          files in the current working directory (or the specified directory).
  3426. 0DELETE  Delete the specified files.
  3427. 0ERASE   This could be a synomym for DELETE, since its meaning is clear.
  3428. 0            (It doesn't seem wise to include UNDELETE  or  UNERASE  in  the
  3429.              standard  list; most systems don't support such a function, and
  3430.              users' expectations should not be toyed with...)
  3431. 0KERMIT  Send a command to the remote Kermit server in its own interactive  com-
  3432.          mand syntax.
  3433. 0RENAME  Change the name of the specified file.
  3434. 0TYPE    Display the contents of the specified file(s) at the terminal.
  3435. 0SPACE   Tell how much space is used and available for storing files in the cur-
  3436.          rent working directory (or the specified directory).
  3437. 0SUBMIT  Submit the specified file(s) for background (batch) processing.
  3438. 0PRINT   Print the specified file(s) on a printer.
  3439. 0MOUNT   Request a mount of the specified tape, disk, or other removable storage
  3440.          medium.
  3441. 0WHO     Show  who  is  logged in (e.g. to a timesharing system), or give infor-
  3442.          mation about a specified user or network host.
  3443. 1Kermit Commands
  3444. +Kermit Commands
  3445. +Kermit Commands                                                         Page 73
  3446. 0
  3447.  MAIL    Send electronic mail to the specified user(s).
  3448. 0MESSAGE Send a terminal message (on a network or timesharing system).
  3449. 0HELP    Give brief information about how to use Kermit.
  3450. 0SET     Set various parameters relating to debugging, transmission, file  mode,
  3451.          and so forth.
  3452. 0SHOW    Display settings of SET parameters, capabilities in force, etc.
  3453. 0STATISTICS
  3454.          Give information about the performance of the most recent file transfer
  3455.          -- elapsed time, effective baud rate, various counts, etc.
  3456. 0HOST    Pass  the  given command string to the specified (i.e. remote or local)
  3457.          host for execution in its own command language.
  3458. 0LOGGING Open or close a transaction or debugging log.
  3459. 0
  3460.  10.6. The SET Command
  3461. +10.6. The SET Command
  3462. +10.6. The SET Command
  3463. 0A SET command should be provided to allow the user to tailor  a  connection  to
  3464.  the  peculiarities  of the communication path, the local or remote file system,
  3465.  etc.  Here are some parameters that should be SET-able:
  3466. 0BLOCK-CHECK
  3467.          Specify  the type of block check to be used: single character checksum,
  3468.          two-character checksum, 3-character CRC.
  3469. 0DEBUGGING
  3470.          Display  or  log  the  packet  traffic,  packet numbers, and/or program
  3471.          states.  Useful for debugging new versions of  Kermit,  novel  combina-
  3472.          tions of Kermit programs, etc.
  3473. 0DELAY   How  many seconds a remote (non-server) Kermit should wait before send-
  3474.          ing the Send-Init packet, to give the user time to escape back  to  the
  3475.          local Kermit and type a RECEIVE command.
  3476. 0DISPLAY Style of file transfer display (NONE, SERIAL, SCREEN, etc).
  3477. 0DUPLEX  For terminal emulation, specify FULL or HALF duplex echoing.
  3478. 0END-OF-LINE
  3479.          Specify any line terminator that must be used after a packet.
  3480. 0ESCAPE  Specify the escape character for terminal emulation.
  3481. 0FILE attributes
  3482.          Almost  any  of  the  attributes listed above in the Attributes section
  3483.          (8.5).  The most common need is to tell the Kermit program  whether  an
  3484. 1Kermit Commands
  3485. +Kermit Commands
  3486. +Kermit Commands                                                         Page 74
  3487. 0
  3488.          incoming or outbound file is text or binary.
  3489. 0FLOW-CONTROL
  3490.          Specify the flow control mechanism for  the  line,  such  as  XON/XOFF,
  3491.          ENQ/ACK,  DTR/CTS,  etc.  Allow flow control to be turned off (NONE) as
  3492.          well as on.  Flow control is done only on full-duplex connections.
  3493. 0HANDSHAKE
  3494.          Specify  any  line-access  negotiation  that  must be used or simulated
  3495.          during file transfer.  For instance, a half duplex  system  will  often
  3496.          need to "turn the line around" after sending a packet, in order to give
  3497.          you permission to reply.  A common handshake is XON (^Q);  the  current
  3498.          user of the line transmits an XON when done transmitting data.
  3499. 0LINE    Specify  the line or device designator for the connection.  This is for
  3500.          use in a Kermit program that can run in either remote  or  local  mode;
  3501.          the  default  line  is the controlling terminal (for remote operation).
  3502.          If an external device is used, local operation is presumed.
  3503. 0LOG     Specify a local file in which to keep a log of the transaction.   There
  3504.          may  be logs for debugging purposes (packet traffic, state transitions,
  3505.          etc) and for auditing purposes (to record the name and  disposition  of
  3506.          each file transferred).
  3507. 0MARKER  Change  the  start-of-packet marker from the default of SOH (CTRL-A) to
  3508.          some other control character, in case one or both systems has  problems
  3509.          using CTRL-A for this purpose.
  3510. 0PACKET-LENGTH
  3511.          The maximum length for a packet.  This should normally be no less  than
  3512.          30  or  40, and can be greater than 94 only if the long-packet protocol
  3513.          extension is available, in which case it can be a much  larger  number,
  3514.          up  to  the maximum size allowed for the particular Kermit program (but
  3515.          never greater than 9024).  Short packets can be an advantage  on  noisy
  3516.          lines;  they  reduce  the  probabily  of a particular packet being cor-
  3517.          rupted, as well as the retransmission overhead when corruption does oc-
  3518.          cur.  Long packets boost performance on clean lines.
  3519. 0PADDING The  number  of  padding  characters  that  should  be sent before each
  3520.          packet, and what the padding character should be.  Rarely necessary.
  3521. 0PARITY  Specify the parity (ODD, EVEN, MARK, SPACE, NONE) of the physical  con-
  3522.          nection.   If other than none, the "8th bit" cannot be used to transmit
  3523.          data and must not be used by either side in block check computation.
  3524. 0PAUSE   How many seconds to pause after receiving a packet before  sending  the
  3525.          next  packet.  Normally 0, but when a system communication processor or
  3526.          front end has trouble keeping up with the traffic, a  short  pause  be-
  3527.          tween  packets  may  allow it to recover its wits; hopefully, something
  3528.          under a second will suffice.
  3529. 0PREFIX  Change the default prefix for control characters, 8-bit characters,  or
  3530. 1Kermit Commands
  3531. +Kermit Commands
  3532. +Kermit Commands                                                         Page 75
  3533. 0
  3534.          repeated quantities.
  3535. 0PROMPT  Change  the  program's  prompt.  This is useful when running Kermit be-
  3536.          tween two systems whose prompt is  the  same,  to  eliminate  confusion
  3537.          about which Kermit you are talking to.
  3538. 0REPEAT-COUNT-PROCESSING
  3539.          Change the default for repeat count processing.  Normally, it  will  be
  3540.          done if both Kermit programs agree to do it.
  3541. 0RETRY   The  maximum number of times to attempt to send or receive a packet be-
  3542.          fore giving up.  The normal number is about 5, but the user  should  be
  3543.          able  to  adjust it according to the condition of the line, the load on
  3544.          the systems, etc.
  3545. 0TIMEOUT Specify the length of the timer to set when waiting for a packet to ar-
  3546.          rive.
  3547. 0WINDOW-SIZE
  3548.          Maximum number of unacknowledged packets outstanding, when the  sliding
  3549.          window option is available, usually between 4 and 31.
  3550. 0
  3551.  10.7. Macros, the DEFINE Command
  3552. +10.7. Macros, the DEFINE Command
  3553. +10.7. Macros, the DEFINE Command
  3554. 0In  addition  to the individual set commands, a "macro" facility is recommended
  3555.  to allow users to combine the characteristics of specific systems into a single
  3556.  SET option.  For example:
  3557. 0    DEFINE IBM = PARITY ODD, DUPLEX HALF, HANDSHAKE XON
  3558.      DEFINE UNIX = PARITY NONE, DUPLEX FULL
  3559.      DEFINE TELENET = PARITY MARK
  3560. 0This  could  be done by providing a fancy runtime parser for commands like this
  3561.  (which could be automatically TAKEn from the user's Kermit initialization  file
  3562.  upon program startup), or simply hardwired into the SET command table.
  3563. 0With  these  definitions  in  place, the user would simply type "SET IBM", "SET
  3564.  UNIX", and so forth, to set up the program to communication to the remote  sys-
  3565.  tem.
  3566. 1Terminal Emulation
  3567. +Terminal Emulation
  3568. +Terminal Emulation                                                      Page 76
  3569. 0
  3570.                                    CHAPTER 11
  3571. +                                  CHAPTER 11
  3572. +                                  CHAPTER 11
  3573.                                TERMINAL EMULATION
  3574. +                              TERMINAL EMULATION
  3575. +                              TERMINAL EMULATION
  3576. 0The local system must be able to act as a terminal so that the user can connect
  3577.  to the remote system, log in, and start up the remote Kermit.
  3578. 0Terminal emulation should be provided by any Kermit program that runs  locally,
  3579.  so that the user need not exit and restart the local Kermit program in order to
  3580.  switch between terminal and protocol operation.  On smaller  systems,  this  is
  3581.  particularly important for various reasons -- restarting the program and typing
  3582.  in all the necessary SET commands is too inconvenient  and  time-consuming;  in
  3583.  some  micros,  switching  in and out of terminal emulation may cause carrier to
  3584.  drop, etc.
  3585. 0Only bare-bones terminal emulation need be supplied by Kermit; there is no need
  3586.  to  emulate  any  particular  kind of "smart" terminal.  Simple "dumb" terminal
  3587.  emulation is sufficient to do the job.  Emulation of fancier terminals is  nice
  3588.  to  have, however, to take advantage of the remote system's editing and display
  3589.  capabilities.  In some cases, microcomputer firmware will take  care  of  this.
  3590.  To build emulation for a particular type of terminal into the program, you must
  3591.  interpret and act upon escape sequences as they arrive at the port.
  3592. 0No error checking is done during  terminal  emulation.    It  is  "outside  the
  3593.  protocol"; characters go back and forth "bare".  In this sense, terminal emula-
  3594.  tion through Kermit is no better than actually using a real terminal.
  3595. 0Some Kermit implementations may allow logging of the terminal emulation session
  3596.  to  a  local  file.  Such a facility allows "capture" of remote typescripts and
  3597.  files, again with no error checking or  correction.    When  this  facility  is
  3598.  provided,  it is also desirable to have a convenient way of "toggling" the log-
  3599.  ging on and off.
  3600. 0If the local system does not provide system- or  firmware-level  flow  control,
  3601.  like  XON/XOFF,  the  terminal emulation program should attempt to simulate it,
  3602.  especially if logging is being done.
  3603. 0The terminal emulation facility should be able to handle either remote or local
  3604.  echoing (full or half duplex), any required handshake, and it should be able to
  3605.  transmit any parity required by the remote side or the communication medium.
  3606. 0A terminal emulator works by continuously sampling both console input from  the
  3607.  local  terminal and input from the communication line.  Simple input and output
  3608.  functions will not suffice, however, since if you ask for input from a  certain
  3609.                                                                             ____
  3610. +device  and  there is none available, you will generally block until input does
  3611.  become available, during which time you will be missing input  from  the  other
  3612.  device.    Thus  you  must  have  a  way to bounce back and forth regardless of
  3613.  whether input is available.  Several mechanisms are commonly used:
  3614. 0   - Continuously jump back and forth between the port status register and
  3615.       the  console  status  register,  checking  the  status bits for input
  3616.       available.  This is only  practical  on  single-user,  single-process
  3617.       systems, where the CPU has nothing else to do.
  3618. 1Terminal Emulation
  3619. +Terminal Emulation
  3620. +Terminal Emulation                                                      Page 77
  3621. 0
  3622.     - Issue an ordinary blocking input request for the port, but enable in-
  3623.       terrupts on console input, or vice versa.
  3624. 0   - Handle port input in one process and console input in another, paral-
  3625.       lel process.  The UNIX Kermit program listed in this manual uses this
  3626.       method.
  3627. 0Any input at the port should be displayed immediately on the screen.  Any input
  3628.  from the console should be output immediately to the port.  In addition, if the
  3629.  connection is half duplex, console input should also be sent immediately to the
  3630.  screen.
  3631. 0The  terminal  emulation  code must examine each console character to determine
  3632.  whether it is the "escape character".  If so, it should take the next character
  3633.  as  a  special command, which it executes.  These commands are described above,
  3634.  in section 10.3.
  3635. 0The terminal emulator should be able to send every ASCII character, NUL through
  3636.  DEL,  and  it  should  also  be able to transmit a BREAK signal (BREAK is not a
  3637.  character, but an "escape" from ASCII transmission in which a 0 is put  on  the
  3638.  line  for  about  a  quarter  of a second, regardless of the baud rate, with no
  3639.  framing bits).  BREAK is important when  communicating  with  various  systems,
  3640.  such as IBM mainframes.
  3641. 0Finally, it is sometimes necessary to perform certain transformations on the CR
  3642.  character that is normally typed to end a line of input.  Some systems use  LF,
  3643.  EOT, or other characters for this function.  To complicate matters, intervening
  3644.  communications equipment (particularly the public packet-switched networks) may
  3645.  have  their  own independent requirements.  Thus if using Kermit to communicate
  3646.  over, say, TRANSPAC with a system that uses  LF  for  end-of-line,  it  may  be
  3647.  necessary to transform CR into LFCR (linefeed first -- the CR tells the network
  3648.  to send the packet, which will contain the LF, and the host  uses  the  LF  for
  3649.  termination).  The user should be provided with a mechanism for specifying this
  3650.                                         ________
  3651. +transformation, a command like "SET CR sequence".
  3652. 1Writing a Kermit Program
  3653. +Writing a Kermit Program
  3654. +Writing a Kermit Program                                                Page 78
  3655. 0
  3656.                                    CHAPTER 12
  3657. +                                  CHAPTER 12
  3658. +                                  CHAPTER 12
  3659.                             WRITING A KERMIT PROGRAM
  3660. +                           WRITING A KERMIT PROGRAM
  3661. +                           WRITING A KERMIT PROGRAM
  3662. 0Before writing a new implementation of Kermit or modifying an old one, first be
  3663.  sure  to  contact the Kermit Distribution center at Columbia University to make
  3664.  sure that you're not duplicating someone else's effort, and that you  have  all
  3665.  the  latest material to work from.  If you do write or significantly modify (or
  3666.  document) a Kermit program, please send it back to Columbia so that it  can  be
  3667.  included  in  the  standard Kermit distribution and others can benifit from it.
  3668.  It is only through this kind of sharing that Kermit has grown from  its  modest
  3669.  beginnings to its present scale.
  3670. 0The following sections provide some hints on Kermit programming.
  3671. 0
  3672.  12.1. Program Organization
  3673. +12.1. Program Organization
  3674. +12.1. Program Organization
  3675. 0A  basic  Kermit  implementation  can  usually be written as a relatively small
  3676.  program, self-contained in a single source file.  However, it is often the case
  3677.  that  a  program  written  to run on one system will be adapted to run on other
  3678.  systems as well.  In that case, it is best to avoid  having  totally  divergent
  3679.  sources,  because when new features are added to (or bugs fixed in) the system-
  3680.  independent parts of the program -- i.e. to the protocol itself -- only one im-
  3681.  plementation will reap the benefits initially, and the other will require pain-
  3682.  ful, error-prone "retrofitting" to bring it up to the same level.
  3683. 0Thus, if there is any chance that a Kermit program will run on  more  than  one
  3684.  machine, or under more than one operating system, or support more than one kind
  3685.  of port or modem, etc, it is desirable to isolate the system-dependent parts in
  3686.  a way that makes the common parts usable by the various implementations.  There
  3687.  are several approaches:
  3688. 0   1. Runtime support.  If possible, the program can inspect the  hardware
  3689.        or  inquire  of  the system about relevant parameters, and configure
  3690.        itself dynamically at startup time.  This is hardly ever possible.
  3691. 0   2. Conditional compilation (or assembly).  If the number of systems  or
  3692.        options  to  be supported is small, the system dependent code can be
  3693.        enclosed in conditional compilation brackets  (like  IF  IBMPC  ....
  3694.        ENDIF).    However,  as the number of system dependencies to be sup-
  3695.        ported grows, this method becomes unwieldy and  error-prone  --  in-
  3696.        stalling  support  for system X tends to break the pre-existing sup-
  3697.        port for system Y.
  3698. 0   3. Modular composition.  When there is a potentially  large  number  of
  3699.        options  a  program  should  support,  it  should  be broken up into
  3700.        separate modules (source  files),  with  clearly  specified,  simple
  3701.        calling conventions.  This allows people with new options to provide
  3702.        their own support for them in an easy way, without  endangering  any
  3703.        existing support.  Suggested modules for a Kermit program are:
  3704. 0   4. 
  3705. 1Writing a Kermit Program
  3706. +Writing a Kermit Program
  3707. +Writing a Kermit Program                                                Page 79
  3708. 0
  3709.           - System-Indendent  protocol  handling:  state  switching, packet
  3710.             formation, encoding (prefixing) and decoding, etc.
  3711. 0         - User Interface: the command parser.  Putting this in a separate
  3712.             module  allows  plug-in  of  command parsers to suit the user's
  3713.             taste, to mimic the style of the host system command parser  or
  3714.             some popular application, etc.
  3715. 0         - Screen i/o: This module would contain the screen control codes,
  3716.             cursor positioning routines, etc.
  3717. 0         - Port i/o: Allows support of various port hardware.  This module
  3718.             can  define the port status register location, the status bits,
  3719.             and so forth, and can implement the functions to read and write
  3720.             characters at the port.
  3721. 0         - Modem   control:   This   module  would  support  any  kind  of
  3722.             "intelligent" modem, which is not simply a  transparent  exten-
  3723.             sion  of  the communications port.  Such modems may accept spe-
  3724.             cial commands to perform functions like dialing out,  redialing
  3725.             a  recent  number,  hanging  up, etc., and may need special in-
  3726.             itialization (for instance, setting modem signals like DTR).
  3727. 0         - Console input: This module would supply  the  function  to  get
  3728.             characters  from  the  console;  it would know about the status
  3729.             register  locations  and  bits,  interrupt  structure,  key-to-
  3730.             character   mappings,   etc.,  and  could  also  implement  key
  3731.             redefinitions, keystroke macros,  programmable  function  keys,
  3732.             expanded control and meta functions, etc.
  3733. 0         - Terminal  Emulation:  This  module  would  interpret escape se-
  3734.             quences in the incoming character  stream  (obtained  from  the
  3735.             port i/o module) for the particular type of terminal being emu-
  3736.             lated and interpret them by making appropriate  calls  the  the
  3737.             screen i/o module, and it would send user typein (obtained from
  3738.             the console input module) out the serial port (again using  the
  3739.             port  i/o module).  Ideally, this module could be replacable by
  3740.             other modules to emulate different  kinds  of  terminals  (e.g.
  3741.             ANSI, VT52, ADM3A, etc).
  3742. 0         - File i/o: This module contains all the knowledge about the host
  3743.             system's file structure; how to open and close  files,  perform
  3744.             "get next file" operations, read and write files, determine and
  3745.             set their attributes, detect the end of a file, and  so  forth,
  3746.             and  provides  the  functions,  including  buffering,  to get a
  3747.             character from a file and put a character  to  a  file.    This
  3748.             module  may  also  provide  file  management services for local
  3749.             files -- directory listings, deleting, renaming,  copying,  and
  3750.             so forth.
  3751. 0         - Definitions  and  Data: Separate modules might also be kept for
  3752.             compile-time parameter definitions and for global runtime data.
  3753. 1Writing a Kermit Program
  3754. +Writing a Kermit Program
  3755. +Writing a Kermit Program                                                Page 80
  3756. 0
  3757.  12.2. Programming Language
  3758. +12.2. Programming Language
  3759. +12.2. Programming Language
  3760. 0The language to be used in writing a Kermit program is more than  a  matter  of
  3761.  taste.    The  primary consideration is that the language provide the necessary
  3762.  functionality and speed.  For instance, a microcomputer implementation of BASIC
  3763.  may  not  allow  the  kind of low-level access to device registers needed to do
  3764.  terminal emulation, or to detect console input during file transfer, or even if
  3765.  it  can  do  these things, it might not be able to run fast enough do drive the
  3766.  communication line at the desired baud rate.
  3767. 0The second consideration in choosing a language is portability.  This  is  used
  3768.  in  two  senses:  (1)  whether the language is in the public domain (or, equiv-
  3769.  alently, provided "free" as part of the basic system), and (2)  whether  it  is
  3770.  well  standardized and in wide use on a variety of systems.  A language that is
  3771.  portable in both senses is to be preferred.
  3772. 0Whatever programming language is selected, it is important that  all  lines  in
  3773.  the  program source be kept to 80 characters or less (after expansion of tabs).
  3774.  This is because Kermit material must often be shipped over RJE and other  card-
  3775.  format communication links.
  3776. 0In  addition,  it is important that the names of all files used in creating and
  3777.  supporting a particular Kermit implementation be (possibly  a  subset)  of  the
  3778.  form NAME.TYPE, where NAME is limited to six characters, and TYPE is limited to
  3779.  three, and where the NAME of each file begin with a common  2  or  3  character
  3780.  prefix.    This is so that all related files will be grouped together in an al-
  3781.  phabetic directory listing, and so when all of the hundreds of  Kermit  related
  3782.  files  are  placed together on a tape, all names will be both legal and unique,
  3783.  especially on systems (like PDP-11 operating  systems)  with  restrictive  file
  3784.  naming conventions.
  3785. 0
  3786.  12.3. Documentation
  3787. +12.3. Documentation
  3788. +12.3. Documentation
  3789. 0A  new  Kermit program should be thoroughly documented; one of the hallmarks of
  3790.  Kermit is its documentation.  The documentation should  be  at  both  the  user
  3791.  level  (how  to  use  the  program,  what the commands are, etc, similar to the
  3792.                                       ______ _____  _____
  3793. +documentation presently found in the Kermit Users  Guide),  and  the  implemen-
  3794.  tation  level  (describe system dependencies, give pointers for adapting to new
  3795.  systems, and so forth).    In  addition,  programs  themselves  should  contain
  3796.  copious  commentary.   Like program source, documentation should be kept within
  3797.  80-character lines.
  3798. 0If possible, a section for the implementation should be written for the  Kermit
  3799.  User  Guide using the UNILOGIC Scribe formatting language (subsets of which are
  3800.  also to be found in some microcomputer text processing software such as Perfect
  3801.  Writer  or  Final  Word),  using  the  same general conventions as the existing
  3802.  Scribe-format implementation sections.
  3803. 0Kermit programs should also contain a revision history, in which each change is
  3804.  briefly  explained,  assigned an "edit number", and the programmer and site are
  3805.  identified.  The lines or sections comprising the edit should  be  marked  with
  3806. 1Writing a Kermit Program
  3807. +Writing a Kermit Program
  3808. +Writing a Kermit Program                                                Page 81
  3809. 0
  3810.  the corresponding edit number, and the Kermit program, upon startup, should an-
  3811.  nounce its version and edit numbers, so that when users complain of problems we
  3812.  will know what version of the program is in question.
  3813. 0The version number changes when the functionality has been changed sufficiently
  3814.  to require major revisions of user documentation.  The edit number  should  in-
  3815.  crease  (monotonically,  irrespective  of  version number) whenever a change is
  3816.  made to the program.  The edit numbers are very important for  program  manage-
  3817.  ment;  after  shipping  out a version of, say, CP/M Kermit-80, we often receive
  3818.  many copies of it, each containing its own set of changes, which we must recon-
  3819.  cile in some manner.  Edit numbers help a great deal here.
  3820. 0
  3821.  12.4. Bootstrapping
  3822. +12.4. Bootstrapping
  3823. +12.4. Bootstrapping
  3824. 0Finally,  a  bootstrap  procedure should be provided.  Kermit is generally dis-
  3825.  tributed on magnetic tape to large central sites; the users at those sites need
  3826.  ways of "downloading" the various implementations to their micros and other lo-
  3827.  cal systems.  A simple bootstrap procedure would consist  of  precise  instruc-
  3828.  tions  on  how  to accomplish an "unguarded" capture of the program.  Perhaps a
  3829.  simple, short program can be written for each each end that will  do  the  job;
  3830.  listings and instructions can be provided for the user to type in and run these
  3831.  programs.
  3832. 1Packet Format and Types
  3833. +Packet Format and Types
  3834. +Packet Format and Types                                                 Page 82
  3835. 0
  3836.  I. PACKET FORMAT AND TYPES
  3837. +I. PACKET FORMAT AND TYPES
  3838. +I. PACKET FORMAT AND TYPES
  3839. 0Basic Kermit Packet Layout
  3840. +Basic Kermit Packet Layout
  3841. +Basic Kermit Packet Layout
  3842. 0       |<------Included in CHECK------>|
  3843.         |                               |
  3844.  +------+-----+-----+------+------ - - -+-------+
  3845.  | MARK | LEN | SEQ | TYPE | DATA       | CHECK |<terminator>
  3846.  +------+-----+-----+------+------ - - -+-------+
  3847.               |                                 |
  3848.               |<--------LEN-32 characters------>|
  3849. 0 MARK   A real control character, usually CTRL-A.
  3850.    LEN   One character, length of remainder of packet + 32, max 95
  3851.    SEQ   One character, packet sequence number + 32, modulo 64
  3852.   TYPE   One character, an uppercase letter
  3853.  CHECK   One, two, or three characters, as negotiated.
  3854. 0<terminator>  Any control character required for reading the packet.
  3855. 0Kermit Extended Packet Layout
  3856. +Kermit Extended Packet Layout
  3857. +Kermit Extended Packet Layout
  3858. 0       |<-------------------------Included in CHECK------------->|
  3859.         |                                                         |
  3860.         |<-------Included in HCHECK------->|                      |
  3861.         |                                  |                      |
  3862.  +------+-----+-----+------+-------+-------+--------+----- - - - -+-------+
  3863.  | MARK |     | SEQ | TYPE | LENX1 | LENX2 | HCHECK | DATA        | CHECK |
  3864.  +------+-----+-----+------+-------+-------+--------+----- - - - -+-------+
  3865.          blank                                      |                     |
  3866.                                                     |<------------------->|
  3867.                      LX1=LENX1-32, LX2=LX2-32         95 x LX1 + LX2 chars
  3868. 0HCHECK is a single-character type 1 checksum
  3869. 0Initialization String
  3870. +Initialization String
  3871. +Initialization String
  3872. 0 1       2       3       4       5       6       7       8       9       10
  3873.  +-------+-------+-------+-------+-------+-------+-------+-------+-------+- -
  3874.  | MAXL  | TIME  | NPAD  | PADC  | EOL   | QCTL  | QBIN  | CHKT  | REPT  |
  3875.  +-------+-------+-------+-------+-------+-------+-------+-------+-------+- -
  3876. 0     10              CAPAS+1  CAPAS+2  CAPAS+3
  3877.  - --+-------+-     -+--------+--------+--------+- -
  3878.      | CAPAS    ... 0| WINDO  | MAXLX1 | MAXLX1 |
  3879.  - --+-------+-     -+--------+--------+--------+- -
  3880. 0MAXL    Maximum length (0-94) +32
  3881.  TIME    Timeout, seconds (0-94) +32
  3882.  NPAD    Number of pad characters (0-94) +32
  3883.  EOL     Packet terminator (0-63) +32
  3884.  QCTL    Control prefix, literal
  3885. 1Packet Format and Types
  3886. +Packet Format and Types
  3887. +Packet Format and Types                                                 Page 83
  3888. 0
  3889.  QBIN    8th bit prefix, literal
  3890.  CHKT    Block check type {1,2,3}, literal
  3891.  REPT    Repeat count prefix, literal
  3892.  CAPAS   Extendable capabilities mask, ends when value-32 is even
  3893.  WINDO   Window size (0-31) +32
  3894.  MAXLX1  High part of extended packet maximum length (int(max/95)+32)
  3895.  MAXLX2  Low part of extended packet maximum length (mod(max,95)+32)
  3896. 0Packet Types
  3897. +Packet Types
  3898. +Packet Types
  3899. 0Y   Acknowledgment (ACK).  Data according to what kind of packet is being  ack-
  3900.      nowledged.
  3901.  N   Negative Acknowledgment (NAK).  Data field always empty.
  3902.  S   Send  Initiation.    Data  field  contains unencoded initialization string.
  3903.      Tells receiver to expect files.  ACK to this packet also contains unencoded
  3904.      initialization string.
  3905.  I   Initialize.   Data field contains unencoded initialization string.  Sent to
  3906.      server to set parameters prior to a command.  ACK to this packet also  con-
  3907.      tains unencoded initialization string.
  3908.  F   File  Header.    Indicates  file data about to arrive for named file.  Data
  3909.      field contains encoded file name.  ACK to this packet may  contain  encoded
  3910.      name receiver will store file under.
  3911.  X   Text  Header.   Indicates screen data about to arrive.  Data field contains
  3912.      encoded heading for display.
  3913.  A   File Attributes.  Data field contains unencoded attributes.  ACK  may  con-
  3914.      tain unencoded corresponding agreement or refusal, per attribute.
  3915.  D   Data  Packet.    Data  field contains encoded file or screen data.  ACK may
  3916.      contain X to interrupt sending this file,  Z  to  interrupt  entire  trans-
  3917.      action.
  3918.  Z   End of file.  Data field may contain D for Discard.
  3919.  B   Break transmission.
  3920.  E   Error.  Data field contains encoded error message.
  3921.  R   Receive Initiate.  Data field contains encoded file name.
  3922.  C   Host  Command.    Data  field  contains  encoded command for host's command
  3923.      processor.
  3924.  K   Kermit Command.  Data field contains encoded  command  for  Kermit  command
  3925.      processor.
  3926.  T   Timeout psuedopacket, for internal use.
  3927.  Q   Block check error psuedopacket, for internal use.
  3928.  G   Generic Kermit Command.  Data field contains a single character subcommand,
  3929.      followed by zero or more length-encoded operands, encoded after formation:
  3930. 0    I   Login [<%user[%password[%account]]>]
  3931.      C   CWD, Change Working Directory [<%directory[%password]>]
  3932.      L   Logout, Bye
  3933.      F   Finish (Shut down the server, but don't logout).
  3934.      D   Directory [<%filespec>]
  3935.      U   Disk Usage Query [<%area>]
  3936.      E   Erase (delete) <%filespec>
  3937.      T   Type <%filespec>
  3938.      R   Rename <%oldname%newname>
  3939.      K   Copy <%source%destination>
  3940. 1Packet Format and Types
  3941. +Packet Format and Types
  3942. +Packet Format and Types                                                 Page 84
  3943. 0
  3944.      W   Who's logged in? [<%user ID or network host[%options]>]
  3945.      M   Send a short Message <%destination%text>
  3946.      H   Help [<%topic>]
  3947.      Q   Server Status Query
  3948.      P   Program <%[program-filespec][%program-commands]>
  3949.      J   Journal <%command[%argument]>
  3950.      V   Variable <%command[%argument[%argument]]>
  3951. 1List of Features
  3952. +List of Features
  3953. +List of Features                                                        Page 85
  3954. 0
  3955.  II. LIST OF FEATURES
  3956. +II. LIST OF FEATURES
  3957. +II. LIST OF FEATURES
  3958. 0There's no true linear scale along which to rate  Kermit  implementations.    A
  3959.  basic,  minimal  implementation provides file transfer in both directions, and,
  3960.  for microcomputers (PC's, workstations, other single  user  systems),  terminal
  3961.  emulation.  Even within this framework, there can be variations.  For instance,
  3962.                         ____ _____
  3963. +can the program send a file group in a single command, or  must  a  command  be
  3964.  issued for each file?  Can it time out?  Here is a list of features that may be
  3965.  present; for any Kermit implementation, the documentation should  show  whether
  3966.  these features exist, and how to invoke them.
  3967. 0   - File  groups.    Can  it send a group of files with a single command,
  3968.       using "wildcard", pattern, or list notation?    Can  it  successfully
  3969.       send or receive a group of files of mixed types?  Can it recover from
  3970.       an error on a particular file and go on to the next one?  Can it keep
  3971.       a log of the files involved showing the disposition of each?
  3972. 0   - Filenames.  Can it take action to avoid overwriting a local file when
  3973.       a new file of the same name arrives?  Can it convert filenames to and
  3974.       from legal or "normal form"?
  3975. 0   - File types.  Can binary as well as text files be transmitted?
  3976. 0   - 8th-Bit  prefixing.    Can  it  send and receive 8-bit data through a
  3977.       7-bit channel using the prefixing mechanism?
  3978. 0   - Repeat-Count processing.  Can it send and receive data with  repeated
  3979.       characters replaced by a prefix sequence?
  3980. 0   - Terminal  Emulation.    Does  it  have a terminal emulation facility?
  3981.       Does it emulate a particular terminal?  To  what  extent?    Does  it
  3982.       provide  various  communication  options, such as duplex, parity, and
  3983.       handshake selection?  Can it transmit all ASCII characters?   Can  it
  3984.       transmit BREAK?  Can it log the remote session locally?
  3985. 0   - Communications Options.  Can duplex, parity, handshake, and line ter-
  3986.       minator be specified for file transfer?
  3987. 0   - Block Check Options.   In  addition  to  the  basic  single-character
  3988.       checksum,  can the two-character checksum and the three-character CRC
  3989.       be selected?
  3990. 0   - Basic Server.  Can it run in server mode, accepting commands to  send
  3991.       or receive files, and to shut itself down?
  3992. 0   - Advanced  Server.    Can  it  accept server commands to delete files,
  3993.       provide directory listings, send messages, and forth?
  3994. 0   - Issue Commands to Server.  Can it send  commands  to  a  server,  and
  3995.       handle all possible responses?
  3996. 0   - Host  Commands.  Can it parse and send remote "host commands"?  If it
  3997. 1List of Features
  3998. +List of Features
  3999. +List of Features                                                        Page 86
  4000. 0
  4001.       is a server, can it pass these commands to the  host  system  command
  4002.       processor and return the results to the local user Kermit?
  4003. 0   - Interrupt  File  Transfers.   Can it interrupt sending or receiving a
  4004.       file?  Can it respond to interrupt requests from the other side?
  4005. 0   - Local File Management Services.  Are  there  commands  to  get  local
  4006.       directory listings, delete local files, and so forth?
  4007. 0   - File  Attributes.  Can it send file attribute information about local
  4008.       files, and can deal with incoming file attribute  information?    Can
  4009.       alternate dispositions be specified.  Can files be archived?
  4010. 0   - Long Packets.  Is the long packet protocol extension implemented?
  4011. 0   - Sliding  Windows.    Is  the sliding window protocol extension imple-
  4012.       mented?
  4013. 0   - Debugging Capability.    Can  packet  traffic  be  logged,  examined,
  4014.       single-stepped?
  4015. 0   - Frills.    Does  it have login scripts?  Raw download/upload?  A DIAL
  4016.       command and modem control?  Phone directories?
  4017. 1The ASCII Character Set
  4018. +The ASCII Character Set
  4019. +The ASCII Character Set                                                 Page 87
  4020. 0
  4021.  III. THE ASCII CHARACTER SET
  4022. +III. THE ASCII CHARACTER SET
  4023. +III. THE ASCII CHARACTER SET
  4024. 0_____ ____ _____ __________
  4025. +ASCII_Code_(ANSI_X3.4-1968)
  4026. 0There are 128 characters in the ASCII (American national Standard Code for  In-
  4027.  formation Interchange) "alphabet".  The characters are listed in order of ASCII
  4028.  value; the columns are labeled as follows:
  4029. 0Bit             Even parity bit for ASCII character.
  4030.  ASCII Dec       Decimal (base 10) representation.
  4031.  ASCII Oct       Octal (base 8) representation.
  4032.  ASCII Hex       Hexadecimal (base 16) representation.
  4033.  EBCDIC Hex      EBCDIC hexadecimal equivalent for Kermit translate tables.
  4034.  Char            Name or graphical representation of character.
  4035.  Remark          Description of character.
  4036. 0The first group consists of nonprintable 'control' characters:
  4037. 1The ASCII Character Set
  4038. +The ASCII Character Set
  4039. +The ASCII Character Set                                                 Page 88
  4040. 0
  4041.       .....ASCII.... EBCDIC
  4042.  ___  ___   ___  ___  ___    ____  _______
  4043. +Bit  Dec   Oct  Hex  Hex    Char  Remarks
  4044.   0   000   000   00   00    NUL   ^@, Null, Idle
  4045.   1   001   001   01   01    SOH   ^A, Start of heading
  4046.   1   002   002   02   02    STX   ^B, Start of text
  4047.   0   003   003   03   03    ETX   ^C, End of text
  4048.   1   004   004   04   37    EOT   ^D, End of transmission
  4049.   0   005   005   05   2D    ENQ   ^E, Enquiry
  4050.   0   006   006   06   2E    ACK   ^F, Acknowledge
  4051.   1   007   007   07   2F    BEL   ^G, Bell, beep, or fleep
  4052.   1   008   010   08   16    BS    ^H, Backspace
  4053.   0   009   011   09   05    HT    ^I, Horizontal tab
  4054.   0   010   012   0A   25    LF    ^J, Line feed
  4055.   1   011   013   0B   0B    VT    ^K, Vertical tab
  4056.   0   012   014   0C   0C    FF    ^L, Form feed (top of page)
  4057.   1   013   015   0D   0D    CR    ^M, Carriage return
  4058.   1   014   016   0E   0E    SO    ^N, Shift out
  4059.   0   015   017   0F   0F    SI    ^O, Shift in
  4060.   1   016   020   10   10    DLE   ^P, Data link escape
  4061.   0   017   021   11   11    DC1   ^Q, Device control 1, XON
  4062.   0   018   022   12   12    DC2   ^R, Device control 2
  4063.   1   019   023   13   13    DC3   ^S, Device control 3, XOFF
  4064.   0   020   024   14   3C    DC4   ^T, Device control 4
  4065.   1   021   025   15   3D    NAK   ^U, Negative acknowledge
  4066.   1   022   026   16   32    SYN   ^V, Synchronous idle
  4067.   0   023   027   17   26    ETB   ^W, End of transmission block
  4068.   0   024   030   18   18    CAN   ^X, Cancel
  4069.   1   025   031   19   19    EM    ^Y, End of medium
  4070.   1   026   032   1A   3F    SUB   ^Z, Substitute
  4071.   0   027   033   1B   27    ESC   ^[, Escape, prefix, altmode
  4072.   1   028   034   1C   1C    FS    ^\, File separator
  4073.   0   029   035   1D   1D    GS    ^], Group separator
  4074.   0   030   036   1E   1E    RS    ^^, Record separator
  4075.   1   031   037   1F   1F    US    ^_, Unit separator
  4076. 0
  4077.  The last four are usually associated with the  control  version  of  backslash,
  4078.  right  square  bracket,  uparrow (or circumflex), and underscore, respectively,
  4079.  but some terminals do not transmit these control characters.
  4080.  The following characters are printable:
  4081. 1The ASCII Character Set
  4082. +The ASCII Character Set
  4083. +The ASCII Character Set                                                 Page 89
  4084. 0
  4085.  First, some punctuation characters.
  4086. 0     .....ASCII.... EBCDIC
  4087.  ___  ___   ___  ___  ___    ____  _______
  4088. +Bit  Dec   Oct  Hex  Hex    Char  Remarks
  4089.   1   032   040   20   40    SP    Space, blank
  4090.   0   033   041   21   5A    !     Exclamation mark
  4091.   0   034   042   22   7F    "     Doublequote
  4092.   1   035   043   23   7B    #     Number sign, pound sign
  4093.   0   036   044   24   5B    $     Dollar sign
  4094.   1   037   045   25   6C    %     Percent sign
  4095.   1   038   046   26   50    &     Ampersand
  4096.   0   039   047   27   7D    '     Apostrophe, accent acute
  4097.   0   040   050   28   4D    (     Left parenthesis
  4098.   1   041   051   29   5D    )     Right parenthesis
  4099.   1   042   052   2A   5C    *     Asterisk, star
  4100.   0   043   053   2B   4E    +     Plus sign
  4101.   1   044   054   2C   6B    ,     Comma
  4102.   0   045   055   2D   60    -     Dash, hyphen, minus sign
  4103.   0   046   056   2E   4B    .     Period, dot
  4104.   1   047   057   2F   61    /     Slash
  4105. 0
  4106.  Numeric characters:
  4107. 0     .....ASCII.... EBCDIC
  4108.  ___  ___   ___  ___  ___    ____  _______
  4109. +Bit  Dec   Oct  Hex  Hex    Char  Remarks
  4110.   0   048   060   30   F0    0     Zero
  4111.   1   049   061   31   F1    1     One
  4112.   1   050   062   32   F2    2     Two
  4113.   0   051   063   33   F3    3     Three
  4114.   1   052   064   34   F4    4     Four
  4115.   0   053   065   35   F5    5     Five
  4116.   0   054   066   36   F6    6     Six
  4117.   1   055   067   37   F7    7     Seven
  4118.   1   056   070   38   F8    8     Eight
  4119.   0   057   071   39   F9    9     Nine
  4120. 0
  4121.  More punctuation characters:
  4122. 0     .....ASCII.... EBCDIC
  4123.  ___  ___   ___  ___  ___    ____  _______
  4124. +Bit  Dec   Oct  Hex  Hex    Char  Remarks
  4125.   0   058   072   3A   7A    :     Colon
  4126.   1   059   073   3B   5E    ;     Semicolon
  4127.   0   060   074   3C   4C    <     Left angle bracket
  4128.   1   061   075   3D   7E    =     Equal sign
  4129.   1   062   076   3E   6E    >     Right angle bracket
  4130.   0   063   077   3F   6F    ?     Question mark
  4131.   1   064   100   40   7C    @     "At" sign
  4132. 1The ASCII Character Set
  4133. +The ASCII Character Set
  4134. +The ASCII Character Set                                                 Page 90
  4135. 0
  4136.  Upper-case alphabetic characters (letters):
  4137. 0     .....ASCII.... EBCDIC
  4138.  ___  ___   ___  ___  ___    ____  _______
  4139. +Bit  Dec   Oct  Hex  Hex    Char  Remarks
  4140.   0   065   101   41   C1    A
  4141.   0   066   102   42   C2    B
  4142.   1   067   103   43   C3    C
  4143.   0   068   104   44   C4    D
  4144.   1   069   105   45   C5    E
  4145.   1   070   106   46   C6    F
  4146.   0   071   107   47   C7    G
  4147.   0   072   110   48   C8    H
  4148.   1   073   111   49   C9    I
  4149.   1   074   112   4A   D1    J
  4150.   0   075   113   4B   D2    K
  4151.   1   076   114   4C   D3    L
  4152.   0   077   115   4D   D4    M
  4153.   0   078   116   4E   D5    N
  4154.   1   079   117   4F   D6    O
  4155.   0   080   120   50   D7    P
  4156.   1   081   121   51   D8    Q
  4157.   1   082   122   52   D9    R
  4158.   0   083   123   53   E2    S
  4159.   1   084   124   54   E3    T
  4160.   0   085   125   55   E4    U
  4161.   0   086   126   56   E5    V
  4162.   1   087   127   57   E6    W
  4163.   1   088   130   58   E7    X
  4164.   0   089   131   59   E8    Y
  4165.   0   090   132   5A   E9    Z
  4166. 0
  4167.  More punctuation characters:
  4168. 0     .....ASCII.... EBCDIC
  4169.  ___  ___   ___  ___  ___    ____  _______
  4170. +Bit  Dec   Oct  Hex  Hex    Char  Remarks
  4171.   1   091   133   5B   AD    [     Left square bracket
  4172.   0   092   134   5C   E0    \     Backslash
  4173.   1   093   135   5D   BD    ]     Right square bracket
  4174.   1   094   136   5E   5F    ^     Circumflex, up arrow
  4175.   0   095   137   5F   6D    _     Underscore, left arrow
  4176.   0   096   140   60   79    `     Accent grave
  4177. 1The ASCII Character Set
  4178. +The ASCII Character Set
  4179. +The ASCII Character Set                                                 Page 91
  4180. 0
  4181.  Lower-case alphabetic characters (letters):
  4182. 0     .....ASCII.... EBCDIC
  4183.  ___  ___   ___  ___  ___    ____  _______
  4184. +Bit  Dec   Oct  Hex  Hex    Char  Remarks
  4185.   1   097   141   61   81    a
  4186.   1   098   142   62   82    b
  4187.   0   099   143   63   83    c
  4188.   1   100   144   64   84    d
  4189.   0   101   145   65   85    e
  4190.   0   102   146   66   86    f
  4191.   1   103   147   67   87    g
  4192.   1   104   150   68   88    h
  4193.   0   105   151   69   89    i
  4194.   0   106   152   6A   91    j
  4195.   1   107   153   6B   92    k
  4196.   0   108   154   6C   93    l
  4197.   1   109   155   6D   94    m
  4198.   1   110   156   6E   95    n
  4199.   0   111   157   6F   96    o
  4200.   1   112   160   70   97    p
  4201.   0   113   161   71   98    q
  4202.   0   114   162   72   99    r
  4203.   1   115   163   73   A2    s
  4204.   0   116   164   74   A3    t
  4205.   1   117   165   75   A4    u
  4206.   1   118   166   76   A5    v
  4207.   0   119   167   77   A6    w
  4208.   0   120   170   78   A7    x
  4209.   1   121   171   79   A8    y
  4210.   1   122   172   7A   A9    z
  4211. 0
  4212.  More punctuation characters:
  4213. 0     .....ASCII.... EBCDIC
  4214.  ___  ___   ___  ___  ___    ____  _______
  4215. +Bit  Dec   Oct  Hex  Hex    Char  Remarks
  4216.   0   123   173   7B   C0     {    Left brace (curly bracket)
  4217.   1   124   174   7C   4F     |    Vertical bar
  4218.   0   125   175   7D   D0     }    Right brace (curly bracket)
  4219.   0   126   176   7E   A1     ~    Tilde
  4220. 0
  4221. 0Finally, one more nonprintable character:
  4222. 0 0    127   177  7F   07    DEL   Delete, rubout
  4223. 1 Index
  4224. + Index
  4225. +,Index                                                                Page xcii
  4226. 0
  4227.  INDEX
  4228. +INDEX
  4229. +INDEX
  4230. 0          8th Bit   6, 29                           Logical Record   11
  4231.                                                      Logical Records   11
  4232.            ACK   8                                   Long Packet Extension   52
  4233.            ASCII   7, 11, 87                         Long Reply   34
  4234. 0          Baud   9                                  NAK   8, 39
  4235.            Binary Files   10, 11, 12                 Normal Form for File Names   16
  4236.            Binary Mode   9
  4237.            Bit Positions   6                         Packet   8, 21
  4238.            Block Check   22, 23                      Parity   23, 28, 88
  4239.            Bootstrap   81                            Prefix   29, 32
  4240.            BREAK   77                                Prefixed Sequence   30
  4241.                                                      Printable Files   11
  4242.            Capabilies   27                           Program, Kermit   78
  4243.            CAPAS   27                                Protocol   4
  4244.            Checksum   22
  4245.            Control Character   7                     Raw Mode   9
  4246.            Control Characters   21, 88               Records   11
  4247.            Control Fields   23                       Remote   6, 9
  4248.            Ctl(x)   8                                Repeat Prefix   29
  4249. 0          Data Encoding   23                        Send-Init   25
  4250.            DEFINE   75                               Sequence Number   13
  4251.            Duplex   10                               Sequential Files   4
  4252.                                                      Server   6
  4253.            EBCDIC   9, 11, 87                        Server Command Wait   31
  4254.            Edit Number   80                          Server Commands   34
  4255.            Encoding   29, 32                         Server Operation   30
  4256.            End-Of-Line (EOL)   9, 22                 Short Reply   34
  4257.            Errors   15                               Sliding Window   55
  4258.                                                      SOH   9
  4259.            Fatal Errors   15
  4260.            File Names   16                           Tab Expansion   11
  4261.            Flow Control   10, 18                     Text Files   11
  4262.            Full Duplex   10                          Timeout   8
  4263.                                                      Tochar(x)   7
  4264.            GET Command   33                          Transaction   13
  4265.                                                      Transaction Log   17
  4266.            Half Duplex   10                          TTY   6
  4267.            Host   6
  4268.                                                      Unchar(x)   8
  4269.            Initial Connection   25                   User   6
  4270.            Interrupting a File Transfer   40
  4271.                                                      Window   55
  4272.            Kermit   4
  4273.                                                      XON/XOFF   10, 18, 88
  4274.            Language, Programming   80
  4275.            Line Terminator   22
  4276.            Line Terminator (see End-Of-Line)
  4277.            Local   6
  4278. 1Table of Contents
  4279. +Table of Contents
  4280. +Table of Contents                                                        Page i
  4281. 0
  4282.  Table of Contents
  4283. +Table of Contents
  4284. +Table of Contents
  4285. 01. Introduction
  4286. +1. Introduction
  4287. +1. Introduction                                                               4
  4288. 0   1.1. Background                                                            4
  4289.     1.2. Overview                                                              4
  4290. 02. Definitions
  4291. +2. Definitions
  4292. +2. Definitions                                                                6
  4293. 0   2.1. General Terminology                                                   6
  4294.     2.2. Numbers                                                               6
  4295.     2.3. Character Set                                                         7
  4296.     2.4. Conversion Functions                                                  7
  4297.     2.5. Protocol Jargon                                                       8
  4298. 03. System Requirements
  4299. +3. System Requirements
  4300. +3. System Requirements                                                        9
  4301. 04. Printable Text versus Binary Data
  4302. +4. Printable Text versus Binary Data
  4303. +4. Printable Text versus Binary Data                                         11
  4304. 0   4.1. Printable Text Files                                                 11
  4305.     4.2. Binary Files                                                         12
  4306. 05. File Transfer
  4307. +5. File Transfer
  4308. +5. File Transfer                                                             13
  4309. 0   5.1. Conditioning the Terminal                                            14
  4310.     5.2. Timeouts, NAKs, and Retries                                          14
  4311.     5.3. Errors                                                               15
  4312.     5.4. Heuristics                                                           16
  4313.     5.5. File Names                                                           16
  4314.     5.6. Robustness                                                           17
  4315.     5.7. Flow Control                                                         18
  4316.     5.8. Basic Kermit Protocol State Table                                    18
  4317. 06. Packet Format
  4318. +6. Packet Format
  4319. +6. Packet Format                                                             21
  4320. 0   6.1. Fields                                                               21
  4321.     6.2. Terminator                                                           22
  4322.     6.3. Other Interpacket Data                                               23
  4323.     6.4. Encoding, Prefixing, Block Check                                     23
  4324. 07. Initial Connection
  4325. +7. Initial Connection
  4326. +7. Initial Connection                                                        25
  4327. 08. Optional Features
  4328. +8. Optional Features
  4329. +8. Optional Features                                                         29
  4330. 0   8.1. 8th-Bit and Repeat Count Prefixing                                   29
  4331.     8.2. Server Operation                                                     30
  4332.         8.2.1. Server Commands                                                31
  4333.         8.2.2. Timing                                                         33
  4334.         8.2.3. The R Command                                                  33
  4335.         8.2.4. The K Command                                                  33
  4336.         8.2.5. Short and Long Replies                                         34
  4337.         8.2.6. Additional Server Commands                                     34
  4338. 1Table of Contents
  4339. +Table of Contents
  4340. +Table of Contents                                                       Page ii
  4341. 0
  4342.         8.2.7. Host Commands                                                  37
  4343.         8.2.8. Exchanging Parameters Before Server Commands                   37
  4344.     8.3. Alternate Block Check Types                                          37
  4345.     8.4. Interrupting a File Transfer                                         40
  4346.     8.5. Transmitting File Attributes                                         40
  4347.     8.6. Advanced Kermit Protocol State Table                                 48
  4348. 09. Performance Extensions
  4349. +9. Performance Extensions
  4350. +9. Performance Extensions                                                    52
  4351. 0   9.1. Long Packets                                                         52
  4352.     9.2. Sliding Windows                                                      55
  4353.         9.2.1. Overall Sequence of Events                                     55
  4354.         9.2.2. Questions and Answers about Sliding Windows                    63
  4355.         9.2.3. More Q-and-A About Windows                                     67
  4356. 010. Kermit Commands
  4357. +10. Kermit Commands
  4358. +10. Kermit Commands                                                          70
  4359. 0   10.1. Basic Commands                                                      70
  4360.     10.2. Program Management Commands                                         70
  4361.     10.3. Terminal Emulation Commands                                         71
  4362.     10.4. Special User-Mode Commands                                          71
  4363.     10.5. Commands Whose Object Should Be Specified                           71
  4364.     10.6. The SET Command                                                     73
  4365.     10.7. Macros, the DEFINE Command                                          75
  4366. 011. Terminal Emulation
  4367. +11. Terminal Emulation
  4368. +11. Terminal Emulation                                                       76
  4369. 012. Writing a Kermit Program
  4370. +12. Writing a Kermit Program
  4371. +12. Writing a Kermit Program                                                 78
  4372. 0   12.1. Program Organization                                                78
  4373.     12.2. Programming Language                                                80
  4374.     12.3. Documentation                                                       80
  4375.     12.4. Bootstrapping                                                       81
  4376. 0I. Packet Format and Types
  4377. +I. Packet Format and Types
  4378. +I. Packet Format and Types                                                   82
  4379. 0II. List of Features
  4380. +II. List of Features
  4381. +II. List of Features                                                         85
  4382. 0III. The ASCII Character Set
  4383. +III. The ASCII Character Set
  4384. +III. The ASCII Character Set                                                 87
  4385. 0Index
  4386. +Index
  4387. +Index                                                                         i
  4388.  
  4389.