home *** CD-ROM | disk | FTP | other *** search
/ Programmer 7500 / MAX_PROGRAMMERS.iso / PROGRAMS / MISC / PROTO / PROTOCOL.TXT next >
Encoding:
Text File  |  1993-03-02  |  8.4 KB  |  204 lines
  1.  
  2.  
  3.  
  4.                              PROTOCOLS EXPLAINED
  5.                 *********************************************
  6.  
  7.  
  8.       This is a brief summary of asynchronous protocols commonly used
  9.       for sending and receiving files with personal computers.
  10.  
  11.       Sending files from one computer to another involves some sort of
  12.       checking to insure that the receiving end gets only what was sent.
  13.       This usually involves the use of some "protocol" or handshaking.
  14.       This is a set of rules and signals performed in concert by both
  15.       ends. Hence both ends must be using the same protocol!
  16.  
  17.  
  18.       -=-=-=-=-=-=-=-=-=-=   ASYNCHRONOUS PROTOCOLS   =-=-=-=-=-=-=-=-=-=-
  19.  
  20.  
  21.       When transferring files via a PC using a modem and a communications
  22.       program, it is necessary to select one protocol for use at both ends.
  23.  
  24.       Different communications packages support different transfer proto-
  25.       cols so you will need to check your documentaion to determine which
  26.       protocols your communications package supports.
  27.  
  28.       Following is a brief description of the most commonly used file
  29.       transfer protocols.
  30.  
  31.  
  32.  
  33.  
  34.                           ASCII DATA CAPTURE
  35.                           ******************
  36.  
  37.      NOTE:  You MAY NOT transfer a binary file (such as a .COM or
  38.      .EXE file) using this method!  You MAY NOT tranfer compressed
  39.      files such as .ZIP or .ARC files either. ASCII may only be used
  40.      for small text files where data integrity is not important.
  41.  
  42.      ASCII transfer is simply the sending of textual information, and
  43.      is limited to 7 bit information.  This excludes all characters
  44.      above 127 decimal such as the IBM PC graphics characters.  It may
  45.      be used for small text files over clean telephone lines.  If data
  46.      integrity is required, this method should NOT be used, or if used,
  47.      the file should be sent twice and received as different filenames
  48.      so that they can be compared with some utility such as COMP which
  49.      comes with DOS.
  50.  
  51.      The transfer of files in ASCII mode can be done if your system is
  52.      capable of any type of data capture.  Just be aware that data may
  53.      be dropped or garbage characters may be added from line noise during
  54.      the transfer. Since no error checking such as a checksum or block
  55.      length is being done, you are at the mercy of the irregular quality
  56.      of phone transmission and switching equipment.
  57.  
  58.      ASCII is presented here even though it is not truly a "protocol".
  59.      Even if the XON/XOFF (Control-S - Control-Q) signals are respected
  60.      by both ends to prevent overruns, and the eighth bit is used for
  61.      parity checking, the user has some aid, but not really enough.
  62.  
  63.  
  64.  
  65.  
  66.                                  KERMIT
  67.                                  ******
  68.  
  69.  
  70.      This protocol's main claim is not speed, but rather its ability to
  71.      interact with many types of computers from mainframes to micros.
  72.      It can cope with systems limited to seven-bit characters even when
  73.      the data to be transmittted is in eight-bit form.  All characters
  74.      to be sent are translated into standard printable characters and
  75.      reconstructed on the receiving end.  While not terribly efficient,
  76.      it is sometimes an absolute necessity for data transfer involving
  77.      different types of systmes and terminal types.  It is not recom-
  78.      mended for PC to PC transfers.
  79.  
  80.  
  81.  
  82.  
  83.                            XMODEM and XMODEM/CRC
  84.                            *********************
  85.  
  86.  
  87.      Xmodem is a file transfer protocol originally developed by Ward
  88.      Christensen. There are two basic type of XMODEM protocols, XMODEM
  89.      and XMODEM/CRC.  Xmodem offers the advantage of error checking on
  90.      a block by block basis to assure that the data sent contains no
  91.      errors.  It does this by adding a checksum byte to the end of each
  92.      128 byte block of data; the receiver calculates its own checksum
  93.      and compares it to the one received.  If an error is detected in
  94.      the transmission, XMODEM will request that the sending PC retrans-
  95.      mit the block of data.In addition to the above checksum comparison,
  96.      XMODEM/CRC adds another level of error detection using a complex
  97.      CYCLICAL REDUNANCY CHECK algorithm.
  98.  
  99.      XMODEM and XMODEM/CRC are slow protocols compared to many others
  100.      available but they are quite reliable and available in almost all
  101.      communications packages. They should only be used when you software
  102.      supports no other protocol. XMODEM/CRC is preferrable to XMODEM due
  103.      to its greatly improved error checking.
  104.  
  105.  
  106.  
  107.  
  108.  
  109.                                 1K-XMODEM
  110.                                 *********
  111.  
  112.  
  113.      This protocol performs exactly like regular XMODEM/CRC, but it
  114.      increases the block size to 1024 bytes, hence the name 1K. It is
  115.      slightly faster (on fairly clean phone lines) than regular XMODEM
  116.      due to a smaller number of blocks being sent, and therefore fewer
  117.      block checks being made.
  118.  
  119.  
  120.  
  121.  
  122.                                 1K-XMODEM/G
  123.                                  ***********
  124.  
  125.  
  126.      This version of 1K-XMODEM makes use of MNP hardware error correction
  127.      to do away with the block-by block checking in the normal version.
  128.      The result is a very fast single file transfer protocol for use if
  129.      YMODEM/G is not readily available.
  130.  
  131.  
  132.  
  133.  
  134.                                    YMODEM
  135.                                    ******
  136.  
  137.  
  138.      YMODEM is a protocol devised by Chuck Forsberg of Omen Technology
  139.      which adds enhancements to portocol based transfer. He is the author
  140.      of DSZ and PRO-YAM communications products.  These are mature and
  141.      robust file transfer programs.
  142.  
  143.      YMODEM block sizes are variable at 128/1024, but 1K (1024) is the
  144.      usual size. Error checking makes use of CRC-16, accurate to 99.99%.
  145.      By definition, all YMODEM transfers are capable of sending multiple
  146.      files at one request, with the file size and date included in the
  147.      "header block" sent prior to each file.  YMODEM supports multiple
  148.      file transfer (both down and up) of up to 50 files om a "batch".
  149.  
  150.      CAUTION:  A number of communication programs incorrectly use the
  151.                term YMODEM but actually send using 1K-XMODEM.  This
  152.                practice is not proper and will result in a failure when
  153.                used with a true YMODEM transfer.
  154.  
  155.       Use of YMODEM, if supported by a caller's software is recommended
  156.       over XMODEM and 1K-XMODEM for speed, reliability and features.
  157.  
  158.  
  159.  
  160.  
  161.                                  YMODEM/G
  162.                                  ********
  163.  
  164.  
  165.      This variation of YMODEM is usually only available when callers are
  166.      using modems supporting MNP (Microcom Networking Protocol) or the
  167.      U.S. Robotics ARQ hardware error checking. MNP is a hardware based
  168.      system in which the modems perform the actual error checking and
  169.      correction, if needed.  The software simply sends the information
  170.      blindly from one system to the other using the protocol for block
  171.      sorting information only.  YMODEM/G is among the fastest protocols
  172.      with the exception of the newer versions of ZMODEM. YMODEM/G also
  173.      supports multiple file transfer (both down and up) of up to 50 files
  174.      per "batch".
  175.  
  176.  
  177.  
  178.  
  179.                                  ZMODEM
  180.                                  ******
  181.  
  182.  
  183.      Use this protocol if it is available at both ends.  As of 1991, it
  184.      is the protocol of choice for asynchronous file transfers.  It is
  185.      solid, widely used, and fast.
  186.  
  187.      ZMODEM is another protocol developed by Chuck Forsberg of Omen tech-
  188.      nology. It is a "streaming protocol", one which sends variable sized
  189.      blocks of data with CRC-32 error checking for an accuracy of 99.9999%,
  190.      but does not wait for an acknowledgment from the receiving computer.
  191.      The sending system assumes data received is OK unless a repeat request
  192.      is sent for a specific block.  This streaming activity makes ZMODEM
  193.      one of the fastest protocols available.
  194.  
  195.      ZMODEM supports multiple files transfer capability. This is commonly
  196.      referred to as "batch transfers".  ZMODEM also has the unique capa-
  197.      bility to resume file transfers that have been aborted for some reason
  198.      and thus only partially completed.  This crash recovery facility is
  199.      usually not needed, but is very handy when it is.
  200.  
  201.  
  202.                  ------------------ END -------------------
  203.  
  204.