Click above to get retro games delivered to your door ever month!

   Protocols

   Telepathy supports Xmodem (including Xmodem/CRC and Xmodem-1K),
   Ymodem and Ymodem-G, Zmodem, and Kermit file transfers.  This section
   contains brief descriptions of each of those protocols.

   Xmodem.  This is the simplest protocol.  It is not very robust and
   tends to be slow (though Kermit can be slower), but is supported by
   most microcomputers.  Each file is sent as a series of 128-byte
   blocks.  Only one file can be sent at a time.  The file name is not
   sent as part of the protocol, so the receiver must be given the name
   beforehand.  The file size is not sent either.  The receiver has no
   way of knowing how large the file will be until the transfer is
   finished.  Files sent by Xmodem are padded out to a multiple of 128
   bytes, normally with ASCII EOF (control-Z) characters, though some
   implementations may include ASCII zeros or garbage characters in the
   padding.  There is no way to know for certain how much of the last
   128 bytes of the file is padding, though text file can be assumed to
   end with the first EOF character.

   Xmodem/CRC.  Identical to straight Xmodem except that each 128-byte
   block has a 16-byte CRC (cyclic redundancy checksum) instead of an
   8-byte arithmetic checksum to guard against errors in transmission.
   This makes Xmodem/CRC somewhat more reliable.  Most implementations
   that support Xmodem today also support Xmodem/CRC, so it is
   preferred.

   Xmodem-1K.  This is Xmodem/CRC with 1024-byte (1K) blocks instead of
   the original 128-byte blocks.  Larger blocks make the protocol
   faster, since much of the time lost in these protocols is spent
   waiting for acknowledgements to return to the sender after every
   block.  The only disadvantage is that the file may be padded to a
   multiple of 1024 bytes instead of 128 bytes as with the other Xmodem
   variations.  Some implementations of Xmodem-1K will "step down" to
   128 byte blocks when they get near the end of the file, to avoid this
   problem, but Telepathy does not.  However, if receiving a file from a
   program that does step down, it will handle that case correctly.

   Xmodem-1K is often confused with Ymodem.  If you see the phrase
   "Ymodem batch", you know that the person who wrote that phrase uses a
   different terminology which says "Ymodem" for what we call Xmodem-1K,
   and "Ymodem batch" for what we call plain Ymodem.

   Ymodem.  An extension to Xmodem-1K.  (See note about names in
   previous paragraph.)  Ymodem is a batch protocol, allowing multiple
   files to be sent in one transfer.  Each file's name and its actual
   size are sent just before the file data, so the receiver does not
   have to know the names beforehand.  At the end of the transfer the
   file is truncated to the specified size, so there is no padding.

   Ymodem-G.  This is Ymodem with one important difference: the sender
   does not wait for the receiver to acknowledge each block before
   sending the next one.  Ymodem-G is intended for use with error-
   correcting modems which automatically eliminate line noise and other
   errors.  If a transmission error occurs during a Ymodem-G transfer,
   there is no way to recover, and the transfer simply aborts.

   Zmodem.  Despite the name, Zmodem is not related to Xmodem or Ymodem.
   It is one of the fastest protocols available (though Ymodem-G with an
   error-free connection is faster).  It is a batch protocol.  Zmodem
   also has the ability to resume a transfer, when a previous transfer
   was aborted but part of the file has already been transmitted.


   Kermit.  Kermit is the best protocol for transferring files between
   many different computers and operating systems.  It is widely
   available on mainframes and workstations which may not support any
   other protocols.  Kermit works well over seven-bit connections (all
   of the other protocols supported by Telepathy require full eight-bit
   connections), and with weird systems and networks that may work with
   no other.  However, it is very slow.  As with Xmodem, the length of a
   file being received is not known until the end of the file; however,
   the received file is not padded in any way.

   Kermit Extensions

   Telepathy supports several extensions to the Kermit protocol.

   Eighth-Bit Quoting.  This is necessary to transmit binary files over
   a seven-bit serial link.  Unlike most other supported protocols,
   Kermit protocol functions do NOT set the link to eight bits during a
   file transfer.  Instead, they check the comm parameters to decide
   whether to attempt eight-bit quoting:

       If the link is set to seven bits (including an eight-bit link
       with tp_striphi() set), the protocol send function will SUGGEST
       eighth-bit quoting, and the receive function will ACCEPT quoting
       if the sender is capable.

       If the link is set to eight bits, the send function will not
       suggest eight-bit quoting, but will state that it is CAPABLE of
       it, and use it if the receiver requests.  The receive function
       will ACCEPT quoting if the sender suggests it, but decline it
       otherwise.

   If you end up sending a binary file over a seven-bit link without
   quoting, the sender will strip out all high-order bits.  The transfer
   will probably complete without error, but if the file was truly a
   binary file, it will probably not be usable.  Make sure you know your
   comm settings when sending binary files!  Since eight-bit quoting
   adds considerably to transfer time, it's best to use an eight-bit
   link when possible.

   Run-Length Encoding.  This optional feature allows the sender to
   compress runs of identical characters in a file to shorter sequences,
   cutting transfer time.  RLE works especially well on DBF files, which
   tend to contain a lot of empty space, fairly well on many text files,
   and not at all on compressed ZIP or ARC files.  RLE is automatic; the
   protocol functions will always use it if both ends are capable.

   Large Blocks.  The maximum length of a block, or packet, in the
   original Kermit protocol is 94 bytes.  This very small limit leads to
   slow transfers, especially over packet nets.  If both parties in a
   transfer support large blocks, the transfer will use a block length
   acceptable to both.

   Both ends must be configured to accept large blocks.  The default
   maximum block length for Telepathy is 94 bytes, but this can be
   changed by the tp_kparam() function.


   Extended Checksums.  Original Kermit used a 6-bit arithmetic checksum
   on each block, sufficient for normal small blocks, but inadequate for
   large blocks.  Later versions allow three different block check
   types:

       Type 1: the original 6-bit arithmetic checksum (one byte per
       packet).

       Type 2: an extended 12-bit arithmetic checksum (two bytes per
       packet).

       Type 3: a 16-bit cyclic redundancy checksum (three bytes per
       packet).

   As with large blocks, the sender and receiver negotiate at the start
   of a transfer to find a block check type agreeable to both.  By
   default, Telepathy will use only a type 1 checksum, but this can be
   changed by the tp_kparam() function.