Document: FSC-0072
Version:  001
Date:     21-Feb-1993




                    The HYDRA file transfer protocol

               Joaquim H. Homrighausen and Arjen G. Lentz




Status of this document:

     This FSC suggests a proposed protocol for the FidoNet(r) community,
     and requests discussion and suggestions for improvements.
     Distribution of this document is subject to the restrictions listed
     below.

     Fido and FidoNet are registered marks of Tom Jennings and Fido
     Software.




    ---------------------------------------------------------------------
     Copyright 1991-1993 Joaquim H. Homrighausen. All rights reserved.
     Copyright 1991-1993 Lentz Software Development. All rights reserved.
    ---------------------------------------------------------------------


    Restrictions
    =====================================================================
    You are granted a license to implement the HYDRA file transfer
    protocol, HYDRA hereafter, in your own programs and/or use the sample
    source code and adapt these to your particular situation and needs;
    subject to the following conditions:

    o You must refer to it as the HYDRA file transfer protocol, and you
      must give credit to the authors of HYDRA in any information screens
      or literature pertaining to your programs that contains other such
      information (credits, your own copyrights, etc.).

    o HYDRA will always remain backwards compatible with previous
      revisions. HYDRA allows for expansion of its features without
      interfering with previous revisions. It is, however, important that
      different people do not expand the protocol in different directions.
      We therefore ask you to contact us if you have any needs/ideas
      regarding HYDRA, so development can be synchronized and beneficial
      to all.

    o If your implementation cannot converse with past or future revisions
      as supplied by us, then you must refer to it as "HYDRA derived", or
      as "a variation of HYDRA", or words to that effect.

    Permission is hereby granted to the FTSC (FidoNet Technical Standards
    Committee) and other technical organisations to republish this
    document in its entirety. Librarians may change the title page and
    page headers to match their library format as long as all copyrights
    and body text remain unaltered. The original document name and source
    must be mentioned in any republished versions of this document.

    No organization, company, person, or other being may impose any fees
    for any reason for providing this document. This document may not be
    sold or otherwise transferred for personal or company gain under any
    circumstances.


    Disclaimer
    =====================================================================
    This information is provided "as is" and comes with no warranties of
    any kind, either expressed or implied. There is no support available
    for this package. It's intended to be used by programmers and
    developers.

    In no event shall the authors be liable to you or anyone else for any
    damages, including any lost profits, lost savings or other incidental
    or consequential damages arising out of the use or inability to use
    this information.


    Revision timestamps
    =====================================================================
    001                           0x2b1aab00                 Dec 01, 1992


    Introduction
    =====================================================================
    This document will not attempt to convince the reader that HYDRA is
    of value to him/her or that it is better than other file transfer
    protocols, it will simply describe the protocol. Just to get it out
    of the way, HYDRA is not the ultimate file transfer protocol.

    The authors do, however, feel that it offers an significant
    improvement over those file transfer protocols available today. HYDRA
    is a bi-directional protocol with the ability to receive and send
    files simultaneously. There are other bi-directional file transfer
    protocols, but to the authors' knowledge no public specifications
    exist.

    HYDRA owes much to Zmodem and its designer, Chuck Forsberg as well as
    to Janus, designed by Rick Huebner. We would like to think of HYDRA
    as a combination of both with a few extra options installed.

    The basic concept of a bi-directional file transfer protocol is
    simple. Both data channels are utilized to transmit and receive files
    simultaneously. I.e. two 100 kb files can be exchanged between two
    parties in the time it takes a fully streaming uni-directional file
    transfer protocol to transmit one of the files.


    Protocol design
    =====================================================================
    The ultimate goal when designing HYDRA was to design a protocol that
    is as simple and robust as possible; complexity increase the problem
    of faulty implementations.

    The obvious function of a file transfer protocol is to transport a
    collection of data from its source to its destination as efficient
    possible and without jeopardizing the integrity of the data.

    The lack of data compression and lost packet management (as used in
    Kermit and Super Kermit) is intentional. The authors feel that this
    unnecessarily increases the complexity of the protocol.

    While HYDRA performs to its best on full duplex links, it should be
    possible to use it on links using proprietary protocols such as the
    US Robotics HST protocol which features one 14.4 kbps data channel
    and one 450 bps back channel.

    The protocol design should be flexible enough for future enhancements
    while maintaining backward compatibility.


    Protocol requirements and restrictions
    =====================================================================
    HYDRA require that the link can handle ASCII character 24 (DLE) as
    well as all ASCII characters in the range 32 through 126. All other
    characters can be escaped or encoded by the protocol as required by
    the link.

    Capability of the computer to perform simultaneous serial I/O as well
    as simultaneous serial I/O combined with disk access is preferred,
    but can be circumvented by opting for windowed transmission instead
    of full streaming.

    HYDRA calls for the ability to check whether there is anything in the
    serial input buffer (i.e. "peek-ahead"), but it doesn't mind if it
    has to wait for a second if there is no data available (using for
    instance the UNIX alarm() mechanism).

    The protocol is extremely tolerant with timeouts (i.e. satellite or
    network delays) while still maintaining maximum reliability,
    robustness, and throughput.


    Terms and definitions
    =====================================================================
    A BYTE                   An 8-bit unsigned character.
    A WORD                   A 16-bit unsigned integer.
    A DWORD                  A 32-bit unsigned integer.
    A LONG                   A 32-bit SIGNED integer.
    FILE OFFSETS (position)  A long.
    NUL                      The ASCII character 0.
    BS                       The ASCII character 8.
    CR                       The ASCII character 13.
    XOFF                     The ASCII character 17.
    XON                      The ASCII character 19.
    H_DLE                    The HYDRA link escape character, ASCII 24
                             (^X).
    SP or SPACE              The ASCII character 32.
    UNIX timestamp           A specific time and date expressed as the
                             number of seconds since midnight, January
                             1st, 1970. All UNIX timestamps used in HYDRA
                             are expressed in local time.

    Multi-byte items are transmitted in "low-byte first" order, so big-
    endian CPUs (like 680xx) need to do some byteswapping, depending on
    the implementation.

    Values preceded by '0x' are in hexadecimal notation (base 16, 0..9
    a..f). All values transmitted in hexadecimal notation must be
    converted to lowercase characters and left-padded to their full
    size with '0' prior to transmission. E.g. a WORD with the value 255
    (decimal) is expressed as 00ff. A LONG with the value 255 (decmial)
    is expressed as 000000ff.

    In formulas, "AND" means bitwise AND, "XOR" means bitwise Exclusive
    OR, "NOT" is ones complement (i.e. all zeros become ones, all ones
    become zeros). The ">>" is a shift operation to the right, "R >> 3"
    means shift R three bits to the right.


    General packet format
    =====================================================================
    All data exchange is done with framed packets protected by 16 or 32
    bit CRC values appended to the packet data and packet type (low-
    byte first). The only exception to this is the cancel sequence of 5
    consecutive H_DLE characters.

    All packets except those with the type DATA are followed by a CR
    (ASCII 13) to help get through some buffered environments and aid
    possible debugging and/or tracing. If requested by the other side in
    its INIT packet, packets can also be prefixed by a specific data
    string which can include NULs, delays or break signals. Refer to the
    section on the INIT packet for more information.


                          Format of unframed packet

                +------------------------------------------+
                ~ Zero or more bytes packet dependent data ~
                +------------------------------------------+
                | Packet type byte                         |
                +------------------------------------------+
                | CRC-16/32 of packet data and packet type |
                +------------------------------------------+


                            Table of packet types

         +--------+---------+-----+--------------------------------+
         |Name    |Character|ASCII|Description                     |
         +--------+---------+-----+--------------------------------+
         |START   |   'A'   |  65 |Startup sequence                |
         |INIT    |   'B'   |  66 |Session initialisation          |
         |INITACK |   'C'   |  67 |Response to INIT packet         |
         |FINFO   |   'D'   |  68 |File information                |
         |FINFOACK|   'E'   |  69 |Response to FINFO packet        |
         |DATA    |   'F'   |  70 |File data packet                |
         |DATAACK |   'G'   |  71 |File data position ACK packet   |
         |RPOS    |   'H'   |  72 |Reposition request packet       |
         |EOF     |   'I'   |  73 |End of file packet              |
         |EOFACK  |   'J'   |  74 |Response to EOF packet          |
         |END     |   'K'   |  75 |End of session                  |
         |IDLE    |   'L'   |  76 |Idle (just saying I'm alive)    |
         |DEVDATA |   'M'   |  77 |Data to specified device     (1)|
         |DEVDACK |   'N'   |  78 |Response to DEVDATA packet   (1)|
         +--------+---------+-----+--------------------------------+

    (1) Support for DEVDATA and DEVDACK types is optional and indicated
        in INIT state of a HYDRA session.


                           Format of framed packet

               +----------------------+--------------------+
               |        H_DLE         |Packet format byte  |
               +----------------------+--------------------+
               ~               Encoded packet              ~
               +----------------------+--------------------+
               |        H_DLE         |End of framed packet|
               +----------------------+--------------------+


                            Table of packet formats

           +----+---------+-----+--------------------------------+
           |Name|Character|ASCII|Description                     |
           +----+---------+-----+--------------------------------+
           |END |   'a'   |  97 |End of framed packet            |
           |BIN |   'b'   |  98 |Binary packet                   |
           |HEX |   'c'   |  99 |Hex encoded packet              |
           |ASC |   'd'   | 100 |Shifted 7-bit encoded packet (1)|
           |UUE |   'e'   | 101 |UUencoded packet             (1)|
           +----+---------+-----+--------------------------------+

    (1) Support for ASC and/or UUE formats is optional and indicated in
        the INIT state of a HYDRA session.


    Packet sender and receiver state charts
    ---------------------------------------------------------------------

TXPKT (Sender)
+--------+------------------------------+--------------------------+----------+
|State   |Predicate(s)                  |Action(s)                 |Next state|
+--------+-+----------------------------+--------------------------+----------+
|Begin   |1|pkttype == START or         |format = HEXPKT           |Format    |
|        | |pkttype == INIT or          |                          |          |
|        | |pkttype == INITACK or       |                          |          |
|        | |pkttype == END or           |                          |          |
|        | |pkttype == IDLE             |                          |          |
|        +-+----------------------------+--------------------------+----------+
|        |2|Escape 8th bit (7 bit link) |                          |Coding    |
|        +-+----------------------------+--------------------------+----------+
|        |3|else (no spc.pkt, 8bit link)|format = BINPKT           |Format    |
+--------+-+----------------------------+--------------------------+----------+
|Coding  |1|escape all control chars &  |format = UUEPKT           |Format    |
|        | |UUENCODED packets allowed   |                          |          |
|        +-+----------------------------+--------------------------+----------+
|        |2|ASCII packets allowed       |format = ASCPKT           |Format    |
|        +-+----------------------------+--------------------------+----------+
|        |3|7 bit link &                |format = HEXPKT           |Format    |
|        | |escape all control chars &  |                          |          |
|        | |UUE/ASC pkts not allowed    |                          |          |
+--------+-+----------------------------+--------------------------+----------+
|Format  |                              |Append format byte to data|CRC       |
+--------+-+----------------------------+--------------------------+----------+
|CRC     |1|format != HEXPKT &          |Calc CRC-32 (data,pkttype)|Encode    |
|        | |CRC-32 allowed              |Append one's complement of|          |
|        | |                            |CRC to data, lowbyte first|          |
|        +-+----------------------------+--------------------------+----------+
|        |2|else (HEXPKT or no CRC-32)  |Calc CRC-16 (data,pkttype)|Encode    |
|        | |                            |Append one's complement of|          |
|        | |                            |CRC to data, lowbyte first|          |
+--------+-+----------------------------+--------------------------+----------+
|Encode  |1|format == BINPKT            |BIN escape databuf        |Prefix    |
|        +-+----------------------------+--------------------------+----------+
|        |2|format == HEXPKT            |HEX encode databuf        |Prefix    |
|        +-+----------------------------+--------------------------+----------+
|        |3|format == ASCPKT            |ASC encode/escape databuf |Prefix    |
|        +-+----------------------------+--------------------------+----------+
|        |4|format == UUEPKT            |UUE encode databuf        |Prefix    |
+--------+-+----------------------------+--------------------------+----------+
|Prefix  |1|No more prefix characters   |                          |Transmit  |
|        +-+----------------------------+--------------------------+----------+
|        |2|Prefix character ASCII 221  |Send 1 second break signal|          |
|        +-+----------------------------+--------------------------+----------+
|        |3|Prefix character ASCII 222  |1 second delay            |          |
|        +-+----------------------------+--------------------------+----------+
|        |4|Prefix character ASCII 223  |Transmit NUL (ASCII 0)    |          |
|        +-+----------------------------+--------------------------+----------+
|        |5|else (any other character)  |Transmit character        |          |
+--------+-+----------------------------+--------------------------+----------+
|Transmit|                              |Transmit H_DLE,format byte|Suffix    |
|        |                              |Transmit encoded buffer   |          |
|        |                              |Transmit H_DLE,pktend byte|          |
+--------+-+----------------------------+--------------------------+----------+
|Suffix  |1|pkttype != DATA &           |Transmit CR,LF (ASC 13,10)|Done      |
|        | |pktformat != BINPKT         |                          |          |
|        +-+----------------------------+--------------------------+----------+
|        |2|else (pkttype == DATA or    |                          |Done      |
|        | |      pktformat == BINPKT)  |                          |          |
+--------+-+----------------------------+--------------------------+----------+


RXPKT (Receiver)
+--------+------------------------------+--------------------------+----------+
|State   |Predicate(s)                  |Action(s)                 |Next state|
+--------+------------------------------+--------------------------+----------+
|Reset   |                              |rxdle = 0                 |NextByte  |
|        |                              |format = 0                |          |
|        |                              |pktlen = 0                |          |
+--------+-+----------------------------+--------------------------+----------+
|NextByte|1|User wishes to abort session|Report reason for abort   |Abort     |
|        | |or carrier lost             |                          |          |
|        +-+----------------------------+--------------------------+----------+
|        |2|Byte available in inputbuf  |                          |StripIn   |
|        +-+----------------------------+--------------------------+----------+
|        |3|braintimer expired          |Report braindead situation|Abort     |
|        +-+----------------------------+--------------------------+----------+
|        |4|Any other timer expired     |Tell responsible party    |          |
+--------+-+----------------------------+--------------------------+----------+
|StripIn |1|Escape 8th bit (7 bit link) |c = c AND 0x7f (strip 8th)|StripC    |
|        +-+----------------------------+--------------------------+----------+
|        |2|else (8 bit link)           |                          |StripC    |
+--------+-+----------------------------+--------------------------+----------+
|StripC  |1|Escape ctlchars with 8th set|n = c AND 0x7f (strip 8th)|Process   |
|        +-+----------------------------+--------------------------+----------+
|        |2|else (let 8 bit ctl through)|n = c                     |Process   |
+--------+-+----------------------------+--------------------------+----------+
|Process |1|c == H_DLE                  |increment rxdle           |DLE       |
|        +-+----------------------------+--------------------------+----------+
|        |2|Escape XON/XOFF &           |Eat these                 |NextByte  |
|        | |n == XON or n == XOFF       |                          |          |
|        +-+----------------------------+--------------------------+----------+
|        |3|Escape all control chars &  |Eat these                 |NextByte  |
|        | |n < 32 or n == 127          |                          |          |
|        +-+----------------------------+--------------------------+----------+
|        |4|rxdle > 0                   |                          |Escape    |
|        +-+----------------------------+--------------------------+----------+
|        |5|else (no eating or escaping)|                          |Store     |
+--------+-+----------------------------+--------------------------+----------+
|DLE     |1|rxdle == 5                  |Report remote wants abort |Abort     |
|        +-+----------------------------+--------------------------+----------+
|        |2|else (rxdle < 5)            |                          |NextByte  |
+--------+-+----------------------------+--------------------------+----------+
|Escape  |1|c == PKTEND                 |                          |PktEnd    |
|        +-+----------------------------+--------------------------+----------+
|        |2|c == BINPKT                 |format = BINPKT           |PktStart  |
|        +-+----------------------------+--------------------------+----------+
|        |3|c == HEXPKT                 |format = HEXPKT           |PktStart  |
|        +-+----------------------------+--------------------------+----------+
|        |4|c == ASCPKT                 |format = ASCPKT           |PktStart  |
|        +-+----------------------------+--------------------------+----------+
|        |5|c == UUEPKT                 |format = UUEPKT           |PktStart  |
|        +-+----------------------------+--------------------------+----------+
|        |6|else (normal escaped char)  |c = c XOR 0x40            |Store     |
|        | |                            |rxdle = 0                 |Store     |
+--------+-+----------------------------+--------------------------+----------+
|Store   |1|format == 0                 |Garbage                   |NextByte  |
|        +-+----------------------------+--------------------------+----------+
|        |2|pktlen >= maximum           |Pkt too long / lost PKTEND|Reset     |
|        +-+----------------------------+--------------------------+----------+
|        |3|else (fmt > 0 & len < max)  |Append c to databuffer    |NextByte  |
|        | |                            |increment pktlen          |          |
+--------+-+----------------------------+--------------------------+----------+
|PktStart|                              |rxdle = 0                 |NextByte  |
|        |                              |pktlen = 0                |          |
+--------+-+----------------------------+--------------------------+----------+
|PktEnd  |1|format == 0                 |End without start, garbage|Reset     |
|        +-+----------------------------+--------------------------+----------+
|        |2|format == BINPKT            |(No more decoding needed) |CalcCRC   |
|        +-+----------------------------+--------------------------+----------+
|        |3|format == HEXPKT            |ok = Decode HEXPKT        |CheckDec  |
|        +-+----------------------------+--------------------------+----------+
|        |4|format == ASCPKT            |ok = Decode ASCPKT        |CheckDec  |
|        +-+----------------------------+--------------------------+----------+
|        |5|format == UUEPKT            |ok = Decode UUEPKT        |CheckDec  |
+--------+-+----------------------------+--------------------------+----------+
|CheckDec|1|ok (no errors during decode)|                          |CalcCRC   |
|        +-+----------------------------+--------------------------+----------+
|        |2|else (errors in decoding)   |Bad encoding, ignore pkt  |Reset     |
+--------+-+----------------------------+--------------------------+----------+
|CalcCRC |1|format != HEXPKT &          |Calc CRC-32 over databuf  |CheckCRC  |
|        | |CRC-32 allowed              |ok = (crc == 0xdebb20e3)  |          |
|        | |                            |pktlen = pktlen - 4       |          |
|        +-+----------------------------+--------------------------+----------+
|        |2|else (HEXPKT or no CRC-32)  |Calc CRC-16 over databuf  |CheckCRC  |
|        | |                            |ok = (crc == 0xf0b8)      |          |
|        | |                            |pktlen = pktlen - 2       |          |
+--------+-+----------------------------+--------------------------+----------+
|CheckCRC|1|ok (CRC matched magic)      |pkttype = last byte of buf|Reset     |
|        | |                            |pktlen = pktlen - 1       |          |
|        | |                            |Hand pkt to higher level  |          |
|        +-+----------------------------+--------------------------+----------+
|        |2|else (CRC check failed)     |Bad CRC, ignore packet    |Reset     |
+--------+-+----------------------------+--------------------------+----------+



    BIN packet format
    ---------------------------------------------------------------------
    The binary packet format require an 8-bit data channel. If requested
    by either side, one or more sets of control characters are escaped.
    In this case, when one of these characters appears in an unframed
    packet, a H_DLE is sent followed by the character XOR 0x40. The H_DLE
    character itself is always transmitted in this fashion. On the
    receiver side, if the character after a H_DLE is not one of the
    packet format bytes, this character is decoded using XOR 0x40 again.


BINPKT Escaping
+--------+------------------------------+--------------------------+----------+
|State   |Predicate(s)                  |Action(s)                 |Next state|
+--------+------------------------------+--------------------------+----------+
|Begin   |                              |txlastc = 0               |NextByte  |
+--------+-+----------------------------+--------------------------+----------+
|NextByte|1|No more bytes to process    |                          |Done      |
|        +-+----------------------------+--------------------------+----------+
|        |2|Escape ctlchars with 8th set|n = c AND 0x7f (strip 8th)|Escape    |
|        +-+----------------------------+--------------------------+----------+
|        |3|else (let 8 bit ctl through)|n = c                     |Escape    |
+--------+-+----------------------------+--------------------------+----------+
|Escape  |1|n == H_DLE                  |Output H_DLE              |Output    |
|        | |                            |c = c XOR 0x40            |          |
|        +-+----------------------------+--------------------------+----------+
|        |2|Escape XON/XOFF &           |Output H_DLE              |Output    |
|        | |n == XON or n == XOFF       |c = c XOR 0x40            |          |
|        +-+----------------------------+--------------------------+----------+
|        |3|Escape Telenet &            |Output H_DLE              |Output    |
|        | |n == CR &                   |c = c XOR 0x40            |          |
|        | |txlasc == '@'               |                          |          |
|        +-+----------------------------+--------------------------+----------+
|        |4|Escape all control chars &  |Output H_DLE              |Output    |
|        | |n < 32 or n == 127          |c = c XOR 0x40            |          |
|        +-+----------------------------+--------------------------+----------+
|        |5|else (any other character)  |                          |Output    |
+--------+-+----------------------------+--------------------------+----------+
|Output  |                              |Store c                   |NextByte  |
|        |                              |txlastc = c               |          |
+--------+------------------------------+--------------------------+----------+



    HEX packet format
    ---------------------------------------------------------------------
    Supported by all implementations, this packet format is used in
    worst-case situations and upon startup of a session when it is not
    yet known what restrictions the line and the other side will place on
    the link.

    Packet types always transmitted in HEX format are: START, INIT,
    INITACK, IDLE, END.

    HEX format packets always use a 16-bit CRC.

    HEX packets assume a 7-bit link, escaping all control characters and
    filtering all control characters upon receipt.

    ASCII characters in the range 128-255 (high bit set) are encoded by
    first transmitting a backslash ('\') character (ASCII 92), followed
    by the character in two lowercase hex-digits (bits 4-7 in first
    digit, bits 0-3 in second).

    Uppercase hex-digits are not permitted.

    The backslash character itself is transmitted as two backslashes.

    ASCII characters in the range 0-31 and 127 (all control characters)
    are escaped with H_DLE in the same fashion as in binary (BIN)
    packets.

    Decoded  byte 1
            +------+
            76543210
            +--++--+
    Encoded  h1  h2


HEXPKT Encoding/Escaping
+--------+------------------------------+--------------------------+----------+
|State   |Predicate(s)                  |Action(s)                 |Next state|
+--------+-+----------------------------+--------------------------+----------+
|NextByte|1|No more bytes to process    |                          |Done      |
|        +-+----------------------------+--------------------------+----------+
|        |2|High bit of c set           |Output \ (backslash)      |          |
|        | |                            |Output hexdigit(c bit 4-7)|          |
|        | |                            |Output hexdigit(c bit 0-3)|          |
|        +-+----------------------------+--------------------------+----------+
|        |3|c < 32 or c == 127          |Output H_DLE              |          |
|        | |                            |Output (c XOR 0x40)       |          |
|        +-+----------------------------+--------------------------+----------+
|        |4|c == \ (backslash)          |Output \ (backslash)      |          |
|        | |                            |Output \ (backslash)      |          |
|        +-+----------------------------+--------------------------+----------+
|        |5|else (any other character)  |Output c                  |          |
+--------+-+----------------------------+--------------------------+----------+


HEXPKT Decoding
+--------+------------------------------+--------------------------+----------+
|State   |Predicate(s)                  |Action(s)                 |Next state|
+--------+-+----------------------------+--------------------------+----------+
|NextByte|1|No more bytes to process    |                          |Done OK   |
|        +-+----------------------------+--------------------------+----------+
|        |2|c == \ (backslash)          |                          |Escape    |
|        +-+----------------------------+--------------------------+----------+
|        |3|else (any other character)  |Output c                  |Escape    |
+--------+-+----------------------------+--------------------------+----------+
|Escape  |1|No more bytes to process    |Premature end of data     |Error     |
|        +-+----------------------------+--------------------------+----------+
|        |2|c == \ (backslash)          |Output \ (backslash)      |          |
|        +-+----------------------------+--------------------------+----------+
|        |3|c == lowercase hexdigit     |Save c, move ptr to next  |NextHex   |
|        +-+----------------------------+--------------------------+----------+
|        |4|else (all other characters) |Invalid character         |Error     |
+--------+-+----------------------------+--------------------------+----------+
|NextHex |1|No more bytes to process    |Premature end of data     |Error     |
|        +-+----------------------------+--------------------------+----------+
|        |2|c == lowercase hexdigit     |Output (1st << 4 OR 2nd)  |NextByte  |
|        +-+----------------------------+--------------------------+----------+
|        |3|else (all other characters) |Invalid character         |Error     |
+--------+-+----------------------------+--------------------------+----------+


    ASC packet format
    ---------------------------------------------------------------------
    Support of this packet format is optional and signalled in the INIT
    packet with the ASC flag in the "Supported options" field. 8-bit data
    is transformed into 7-bit data by a simple shift operation. Each byte
    is inserted at the top of a shift register, the lower seven bits are
    moved out. So seven 8-bit bytes are encoded into eight 7-bit
    characters.

    The end of the packet is padded by a maximum of six bits of 0 to make
    the number of bits a multiple of seven and thereby creating
    complete characters (so the receiver stops decoding when there are
    less than seven bits left). The output can contain control
    characters, so if escaping of these characters is required, this is
    done as in BIN packets using the H_DLE method.


    Decoded  byte 7  byte 6  byte 5  byte 4  byte 3  byte 2  byte 1
            +------++------++------++------++------++------++------+
            76543210765432107654321076543210765432107654321076543210
            +-----++-----++-----++-----++-----++-----++-----++-----+
    Encoded   c8     c7      c6    c5     c4     c3     c2     c1


ASCPKT Encoding/Escaping
+--------+------------------------------+--------------------------+----------+
|State   |Predicate(s)                  |Action(s)                 |Next state|
+--------+------------------------------+--------------------------+----------+
|Reset   |                              |n = 0 (16 bit wide!)      |NextByte  |
|        |                              |bitshift = 0              |          |
+--------+-+----------------------------+--------------------------+----------+
|NextByte|1|No more bytes to process    |                          |Flush     |
|        +-+----------------------------+--------------------------+----------+
|        |2|else (more bytes to process)|n = n OR (c << bitshift)  |Shift     |
|        | |                            |BINPKT escape (n & 0x7f)  |          |
|        | |                            |n = n >> 7                |          |
|        | |                            |increment bitshift        |          |
+--------+-+----------------------------+--------------------------+----------+
|Shift   |1|bitshift == 7               |BINPKT escape (n & 0x7f)  |Reset     |
|        +-+----------------------------+--------------------------+----------+
|        |2|else (bitshift < 7)         |                          |NextByte  |
+--------+-+----------------------------+--------------------------+----------+
|Flush   |1|bitshift > 0                |BINPKT escape (n & 0x7f)  |Done      |
|        +-+----------------------------+--------------------------+----------+
|        |2|else (bitshift == 0)        |                          |Done      |
+--------+-+----------------------------+--------------------------+----------+

ASCPKT Decoding
+--------+------------------------------+--------------------------+----------+
|State   |Predicate(s)                  |Action(s)                 |Next state|
+--------+------------------------------+--------------------------+----------+
|Begin   |                              |n = 0 (16 bit wide!)      |NextByte  |
|        |                              |bitshift = 0              |          |
+--------+-+----------------------------+--------------------------+----------+
|NextByte|1|No more bytes to process    |                          |Done OK   |
|        +-+----------------------------+--------------------------+----------+
|        |2|else (more bytes to process)|c = c AND 0x7f            |Shift     |
|        | |                            |n = n OR (c << bitshift)  |          |
|        | |                            |bitshift = bitshift + 7   |          |
+--------+-+----------------------------+--------------------------+----------+
|Shift   |1|bitshift >= 8               |Output (n AND 0xff)       |NextByte  |
|        | |                            |n = n >> 8                |          |
|        | |                            |bitshift = bitshift - 8   |          |
|        +-+----------------------------+--------------------------+----------+
|        |2|else (bitshift < 8)         |                          |NextByte  |
+--------+-+----------------------------+--------------------------+----------+



    UUE packet format
    ---------------------------------------------------------------------
    Support of this packet format is optional and signalled in the INIT
    packet with the UUE flag in the "Supported options" field. The 8-bit
    data is transformed into printable ASCII using the UUENCODE
    algorithm. Three 8-bit bytes are encoded into four printable ASCII
    characters. This done by taking the bottom six bits left and adding
    '!' (ASCII 33) to move this character value into printable ASCII
    range.

    The end of the packet is padded by a maximum of five bits of 0 to
    make the number of bits a multiple of six and thereby creating 
    complete characters (so the receiver stops decoding when there are
    less than six bits left). The output of this coding scheme does not
    need any further escaping before transmission.

    Decoded  byte 3  byte 2  byte 1
            +------++------++------+
            765432107654321076543210
            +----++----++----++----+
    Encoded   c4    c3    c2    c1


UUEPKT Encoding
+--------+------------------------------+--------------------------+----------+
|State   |Predicate(s)                  |Action(s)                 |Next state|
+--------+-+----------------------------+--------------------------+----------+
|NextByte|1|Less than three bytes left  |                          |Flush     |
|        +-+----------------------------+--------------------------+----------+
|        |2|else (three or more left)   |UUE(in[0]>>2)             |          |
|        | |                            |UUE(in[0]<<4 OR in[1]>>4) |          |
|        | |                            |UUE(in[1]<<2 OR in[2]>>6) |          |
|        | |                            |UUE(in[2])                |          |
|        | |                            |(UUE: (c AND 0x3f) + '!') |          |
+--------+-+----------------------------+--------------------------+----------+
|Flush   |1|No more bytes left          |                          |Done      |
|        +-+----------------------------+--------------------------+----------+
|        |2|One byte left               |UUE(in[0]>>2)             |Done      |
|        | |                            |UUE(in[0]<<4)             |          |
|        +-+----------------------------+--------------------------+----------+
|        |3|Two bytes left              |UUE(in[0]>>2)             |Done      |
|        | |                            |UUE(in[0]<<4 OR in[1]>>4) |          |
|        | |                            |UUE(in[1]<<2)             |          |
+--------+-+----------------------------+--------------------------+----------+

UUEPKT Decoding
+--------+------------------------------+--------------------------+----------+
|State   |Predicate(s)                  |Action(s)                 |Next state|
+--------+-+----------------------------+--------------------------+----------+
|NextByte|1|Less than four bytes left   |                          |Flush     |
|        +-+----------------------------+--------------------------+----------+
|        |2|else (four or more left) &  |UD(i[0])<<2 OR UD(i[1])>>4|          |
|        | |(c AND 0x7f) is in UUE range|UD(i[1])<<4 OR UD(i[2])>>2|          |
|        | |                            |UD(i[2])<<6 OR UD(i[3])   |          |
|        | |                            |(UD: (c - '!') AND 0x3f)  |          |
|        +-+----------------------------+--------------------------+----------+
|        |3|else (all other characters) |Invalid character(s)      |Error     |
+--------+-+----------------------------+--------------------------+----------+
|Flush   |1|No bytes left or            |                          |Done OK   |
|        | |Less than two bytes left    |                          |          |
|        +-+----------------------------+--------------------------+----------+
|        |2|Two bytes left &            |UD(i[0])<<2 OR UD(i[1])>>4|Done OK   |
|        | |(c AND 0x7f) is in UUE range|                          |          |
|        +-+----------------------------+--------------------------+----------+
|        |3|Three bytes left &          |UD(i[0])<<2 OR UD(i[1])>>4|Done OK   |
|        | |(c AND 0x7f) is in UUE range|UD(i[1])<<4 OR UD(i[2])>>2|          |
|        +-+----------------------------+--------------------------+----------+
|        |4|else (all other characters) |Invalid character(s)      |Error     |
+--------+-+----------------------------+--------------------------+----------+



    START packet                                             (HEX format)
    ---------------------------------------------------------------------
    This packet is sent to tell the remote to initiate a HYDRA session.

    The complete framed packet as transmitted looks like:

        ASCII values   24    99  65  92 102  53  92  97  51    24    97
                    +-------+---+---+---+---+---+---+---+---+-------+---+
        Characters  | H_DLE | c | A | \ | f | 5 | \ | a | 3 | H_DLE | a |
                    +-------+---+---+---+---+---+---+---+---+-------+---+

    Applications may scan for this sequence to automatically start HYDRA
    when the remote transmits this packet (AutoStart). Prior to the START
    packet, a special string is transmitted to enable remote starting
    from a command prompt, hydra (the word hydra in lowercase):

        ASCII values 104 121 100 114  97  13
                    +---+---+---+---+---+----+
        Characters  | h | y | d | r | a | CR |
                    +---+---+---+---+---+----+

    The special string combined with the START packet is transmitted at
    five second intervals until either a START or INIT packet is received
    from the remote, or the maximum number of retries is reached. Any
    other packet types received in this stage must be ignored as they
    could be remains of a previous session.


    INIT packet                                              (HEX format)
    ---------------------------------------------------------------------
    The INIT packet contains file transfer session options. The remote
    acknowledges this packet by returning an INITACK packet.


                              INIT packet data

                 +---------------------------------------+
                 ~ Application ID string, NUL terminated ~
                 +---------------------------------------+
                 ~ Supported options, NUL terminated     ~
                 +---------------------------------------+
                 ~ Desired options, NUL terminated       ~
                 +---------------------------------------+
                 | Desired transmitter window size or 0  |
                 +---------------------------------------+
                 | Desired receiver window size or 0     |
                 +---------------------------------------+
                 ~ Other general options, NUL terminated ~
                 +---------------------------------------+
                 ~ Packet prefix string, NUL terminated  ~
                 +---------------------------------------+

    The application ID string contains a printable ASCII string with the
    document revision date, product name, product revision number, and
    optionally the product serial number. The format of the string is:

        <RevDate><ProductName><,><ProductRevision>[<,><ProductSerial#>]

    RevDate is the UNIX timestamp (the hour, minute, and second portion
    is assumed to be zero), in hexadecimal notation, of the HYDRA
    document that the application is supposed to support. None of the
    following three fields should exceed thirty characters in length and
    must not contain any control characters (ASCII 0-31) or the comma
    character (ASCII 44). The field separator is a comma (ASCII 44)
    character.

    Capability flags

        XON        Escape <XON> and <XOFF> characters.
        TLN        Escape the <CR>@<CR> sequence (Telenet escape).
        CTL        Escape ASCII characters 0-31 and 127.
        HIC        Escape above three with high bit set.
        HI8        Escape ASCII characters 128-255 and strip the high bit.
        BRK        Can transmit a break signal.
        ASC        Can handle ASC packets.
        UUE        Can handle UUE packets.
        C32        Can receive packets with 32-bit CRC error detection.
        DEV        Can receive device packets.
        FPT        Can receive filenames with paths.

    Capability flags are always three characters long, in uppercase, and
    seperated by a comma character (ASCII 44). Please note that the first
    five flags must be supported by all applications that implement the
    HYDRA specifications.

    The "Supported options" string contain the capability flags of the
    options that the application support. The "Desired options" string
    contain the capability flags of the options that the application
    would like to use/enable for the session. Some flags do not have to
    be specified in both strings. E.g. if the C32 flag is present in the
    "Supported options" string and the remote system indicates support
    for the same flag, 32-bit CRC error detection will be used. An
    application may not ask for an option it does not support.

    Escaping certain characters or bits also means filtering any
    occurrence of them in the incoming data stream. At the start of a
    session, it is assumed that the first five capability flags are in
    effect, i.e. the high bit is stripped off every received character
    and all control characters are filtered out.

    The "Desired transmitter/receiver window size" fields are long
    integers expressed in hexadecimal notation. With these options each
    side tells the other to use window management of the requested size
    when transmitting file data, instead of using full streaming (0).
    The window setting is completely seperate for both directions.
    If one side requests a smaller window size than the other, that
    smaller size will be used for that direction; also, a window of any
    size takes precedence over no window (0).
    Please note that the terms 'transmitter' and 'receiver' used for the
    fields in the INIT packet are from the view of the side transmitting
    that packet, so the other side should merge the 'transmitter' window
    field from the received INIT packet with its own 'receiver' window
    field.

    The "General options" string currently has no other fields than
    "Desired tx/rx window size"; the string is NUL terminated.

    The packet prefix string is normally empty, but may be provided by
    the remote if required. The maximum length of a packet prefix string
    is 30 characters. All characters should be transmitted as specified,
    with the following exceptions:

    
                Table of special packet prefix string chars

               +-----+--------------------------------------+
               |ASCII|Description                           |
               +-----+--------------------------------------+
               | 221 |Transmit a break signal for one second|
               | 222 |Delay one second before next character|
               | 223 |Transmit a NUL (ASCII 0) character    |
               +-----+--------------------------------------+


    INITACK packet                                           (HEX format)
    ---------------------------------------------------------------------
    The INITACK packet is used to acknowledge the receipt of the remote's
    INIT packet.

    Duplicate INIT packets should be acknowledged too, as the remote may
    have missed previous INITACK packets; the reception of such a
    duplicate packet should not however reset the braindead timer, as it
    does not mean a change of state and is not actual file data.


    FINFO packet
    ---------------------------------------------------------------------
    File information packet, sent to notify the remote that another file
    is to be transmitted, or to signal end of batch. After the FINFO
    packet has been transmitted, the timer is set to the normal timeout
    value. The sender then waits for an FINFOACK packet from the remote
    or for the timer to expire. In the event of a timeout, the transmit/
    wait sequence is repeated with half the normal timeout value until
    the maximum number of retries has been reached.


                              FINFO packet data
                   +-------------------------------------+
                   ~ File information, NUL terminated    ~
                   +-------------------------------------+


                   File information        End of batch
                  +-----------------+   +-----------------+
                  | Timestamp or 0  |   |       NUL       | 
                  +-----------------+   +-----------------+ 
                  | Filesize or 0   |
                  +-----------------+
                  | Reserved (0)    |
                  +-----------------+
                  | Transaction #   |
                  +-----------------+
                  | File count or 0 |
                  +-----------------+
                  ~ Short filename  ~
                  +-----------------+
                  ~ Real filename   ~
                  +-----------------+
                  |     NUL         |
                  +-----------------+
                     
    End of batch is signalled by an empty string (only the terminating
    NUL).

    The first five fields are long integers expressed in hexadecimal
    notation.

    Timestamp is a UNIX timestamp representing the creation time of the
    file. If the creation time is not known, this is zero.

    Filesize is the size of the file in bytes. If the size of the file is
    not known, this is zero. This field should not be used as an exact
    measure of the size of the file. It is safe to assume that you should
    not receive less data than specified in this field, but the file may
    grow while it is being transferred (e.g. the result of a background
    process).

    Transaction # is a unique number for each set of files being sent
    during the session. This is primarily used to allow the receiving
    application to group several files together and store them in
    specific directories as a result of automated file requests. If the
    file being sent is not a result of an automated file request, this
    field must be set to zero.

    File count is the session file counter. For the first file in a
    session, this field contains the total number of files to be sent
    during the session; for subsequent files, it contains the file number
    in the session, starting with two (2). If the total number of files
    is not known, this field contains zero for all files.

    The first filename field must be specified in lowercase characters.
    It must conform to MS-DOS filename conventions and not exceed 12
    characters in length (excluding the terminating NUL character). The
    second field, real filename, is the actual filename on the sending
    system. If this field is not present, the short filename field is
    used.

    No directory paths may be specified in the short filename. Directory
    paths may be specified in the real filename field if the "Desired
    options" of the receiver contains FPT. If the real filename field
    contains a path, it may include any ASCII character in the range 32
    (0x20) through 255 (0xff) with \ characters translated to /. A drive
    specifier may be present in the <Drive>: (e.g. c:) format. If both
    the short and real filename fields are present, they are separated
    by a NUL character. There is never more than one NUL character
    terminating the packet.
    

    FINFOACK packet
    ---------------------------------------------------------------------
    Sent in response to an FINFO packet. If the FINFO packet contained
    file information, the FINFOACK packet is also used to instruct the
    remote how to proceed with the transfer.


                            FINFOACK packet data
                 +---------------------------------------+
                 | Long file offset, special code, or 0  |
                 +---------------------------------------+

    The only data in this packet is a long integer. In response to an
    an end of batch FINFO packet, the file offset is set to zero (0). In
    all other cases, file offset is one of the following:


                       File offsets and special values
           +------+----------------------------------------------+
           |Offset|Description                                   |
           +------+----------------------------------------------+
           | >=0  |Seek to specified offset and start sending (1)|
           |  -1  |Already have file                          (2)|
           |  -2  |Send file during another batch (not now)      |
           +------+----------------------------------------------+

    (1) This can only be something other than zero if the FINFO packet
        specified a filesize other than zero (i.e. the size of the file
        is known to the receiver).

    (2) The sending application should consider the file as having been
        sent successfully. This is primarily used to prevent duplicate
        files from being transmitted.


    DATA packet
    ---------------------------------------------------------------------
    Packet containing actual file data.


                                  DATA packet
                  +-----------------------------------------+
                  | Long file offset of file data block     |
                  +-----------------------------------------+
                  ~ Variable length data block 0-2048 bytes ~
                  +-----------------------------------------+

    If the file offset corresponds with what is expected by the receiver,
    the data block is saved and the file position increased accordingly.
    If the file offset is not correct, DATA packets may have been lost or
    failed the CRC check. Bad packets are ignored because it is not
    certain that the bad packet was an actual DATA packet and not some
    other type of packet. The file offset comparison is therefore the
    only way to find out about lost or bad data.

    When a bad data packet is detected, an RPOS packet is transmitted by
    the receiver to force the sender to seek to the desired file offset
    and resume transmission from it. After transmitting the RPOS packet,
    the receiver initializes a timer and continues to monitor received
    DATA packets while comparing their file offset with its desired
    offset.

    If the offset of a newly received DATA packet is greater than the
    offset received in the last DATA packet prior to transmitting the
    RPOS packet, the sender has not yet seen the RPOS packet, or the
    DATA packet was already in the data stream when the RPOS packet was
    transmitted.

    If the received offset matches the requested offset, the transfer is
    resumed, otherwise, a new RPOS packet is transmitted by the receiver
    and the timer restarted.

    If the timer expires, another RPOS packet is transmitted by the
    receiver. This is repeated until the maximum number of retries has
    been reached.

    If the receiver encounters more missing or invalid DATA packets at
    the same offset than it finds acceptable and it is not the originator
    of the session, it may decide to revert to a one-way transfer and
    wait with sending the remainder of its own files until the remote has
    transmitted its end of batch signal. It is possible that some hard-
    ware is not capable or well suited for a bi-directional file transfer
    involving large volumes of data (see description of the IDLE packet).


    DATAACK packet
    ---------------------------------------------------------------------
    Transmitted by the receiver with its current file offset after
    receiving a valid DATA packet.


                              DATAACK packet data
                          +------------------------+
                          |    Long file offset    |
                          +------------------------+

    This packet is only transmitted if there is a window in operation
    for that direction (selected in the INIT stage of the session), in
    which case the sender uses the DATAACK file offsets to manage its
    transmit window. If the sender's file offset is greater than or equal
    to the last DATAACK offset received plus the window size, no more
    data is transmitted by the sender until a DATAACK packet is received
    which allows the sender to proceed without exceeding the window size.

    While waiting for the DATAACK packet, the sender checks its timer
    and retry counter. If the timer expires before a valid DATAACK packet
    is received, the next DATA packet is transmitted, the retry counter
    incremented, and the timer restarted with half the normal timeout.
    This system ensures that the two sides do not end up waiting for
    each other in case packets are lost; the receiver will respond with
    either a DATAACK or RPOS packet. Receipt of a DATAACK packet does not
    reset the braindead timer.

    There are two windowing systems the receiver can use: sliding window
    or segmented streaming.

    If the receiver is capable of simultaneous serial and disk I/O, it
    will transmit a DATAACK packet for every received DATA packet, or
    every few DATA packets if it wants to be more economical with line
    capacity.
    Sliding window transmission is just a method of keeping the runahaid
    of the transmitter within reasonable limits (for sattelite or network
    links with long delays), thereby allowing for faster error recovery.
    Because of Hydra's tolerancy to delays and method of error recovery,
    sliding windows transmission is not normally required and full
    streaming can be used.

    If however the receiver is not capable of simultaneous serial and
    disk I/O, it will will process received DATA packets until the window
    size is reached (or slightly exceeded), write the received packets to
    disk, and then transmit one DATAACK packet to signal that it can
    receive the next segment of data.

    If the sender cannot handle simultaneous serial and disk I/O, it can
    apply the segmented streaming technique for reading data segments of
    the negotiated window size from disk.


    RPOS packet
    ---------------------------------------------------------------------
    Transmitted by the receiver to force the sender to seek to a specific
    position in the file and resume the transfer (as described above).

    The RPOS packet is also used by the receiver to skip a file once the
    transfer has been initiated. This is done by transmitting a RPOS
    packet with -2 as the desired offset and then waiting for a EOF
    packet with the same offset (-2). Once the EOF packet is received,
    the receiver responds to it by transmitting a EOFACK packet and then
    proceeds to wait for the next FINFO packet.


                          RPOS packet dependent data
                  +----------------------------------------+
                  | Long file offset                       |
                  +----------------------------------------+
                  | Desired datablock size (word, 64-2048) |
                  +----------------------------------------+
                  | Long RPOS packet ID                    |
                  +----------------------------------------+


                                 File offsets 
             +------+-------------------------------------------+
             |Offset|Description                                |
             +------+-------------------------------------------+
             | >=0  |Seek to specified offset and resume sending|
             |  -2  |Send file during another batch (not now)   |
             +------+-------------------------------------------+

    The desired data blocksize field tells the sender what blocksize
    to use when it resumes transmitting from the specified file offset.

    Each new RPOS packet should be given a different packet ID. This
    allows the sender to identify and ignore duplicate RPOS packets.
    The ID need not be sequential, but it must not have the same value as
    any other RPOS packet sent during the transmission of the same file.
    A RPOS ID value of zero (0) is not permitted. The same ID value is
    only used when sending multiple RPOS packets due to an expired RPOS
    packet timer as described above (DATA packet).


    EOF packet
    ---------------------------------------------------------------------
    Indicates that the end of the file has been reached by the sender.
    The packet is transmitted after the last DATA packet with file data.
    The EOF packet only contains one field which holds the current file
    offset of the sender (i.e. the actual size of the file).

    After the EOF packet has been transmitted, the timer is set to the
    normal timeout value. The sender then waits for an EOFACK packet
    from the remote or for the timer to expire. In the event of a
    timeout, the transmit/wait sequence is repeated with half the normal
    timeout value until the maximum number of retries has been reached.

    In the event that the receiver requests to skip the file by
    transmitting a RPOS(-2) packet (see RPOS packet), the EOF packet
    contains the same value (-2). If the sender wants to skip the file
    currently being transmitted, it issues an EOF packet with -2 as the
    offset value.

    EOF packets with an incorrect offset should be treated by the
    receiver as if it was an incorrect DATA packet (i.e. transmitting an
    RPOS packet). Accepted EOF packets are acknowledged by transmitting
    an EOFACK packet.


                                EOF packet data
                     +----------------------------------+
                     | Long file offset or special code |
                     +----------------------------------+


                         File offsets and special value
               +------+----------------------------------------+
               |Offset|Description                             |
               +------+----------------------------------------+
               | >=0  |Final offset in file (size of file)     |
               |  -2  |Send file during another batch (not now)|
               +------+----------------------------------------+


    EOFACK packet
    ---------------------------------------------------------------------
    Transmitted in response to an accepted EOF packet. After transmitting
    this packet, the receiver waits for the FINFO packet of the next file
    or end of batch.


    END packet                                               (HEX format)
    ---------------------------------------------------------------------
    Once all files have been transmitted by both sides and no device
    packets remain to be transmitted, the end of session sequence is
    initiated. END packets are always sent in HEX format.

    Two END packets are transmitted and the transmit timer set to half
    the normal timeout. The application then waits for an END packet from
    the remote or for the transmit timer to expire. In the event of a
    timeout, the transmit/wait sequence is repeated until the maximum
    number of retries has been reached. At this point, the HYDRA session
    may be considered to be successful as both batches were completed.

    If an END packet is received before timeout, another three (3) END
    packets are transmitted and the protocol exits. Both sides need to
    transmit END packets and receive at least one from the remote.


    IDLE packet                                              (HEX format)
    ---------------------------------------------------------------------
    The IDLE packet is used to let the remote know that the application
    is still alive. This is only applicable in uni-directional transfer
    mode to let the remote know that your application is still alive when
    it is receiving files, and after having transmitted an end of batch
    signal to the remote and not having any more files to send for the
    remainder of the session.

    When applicable, the IDLE packet is transmitted every 20 seconds. The
    remote resets its braindead timer upon receipt of an IDLE packet. If
    an application receives an IDLE packet while it is in a state where
    it is transmitting IDLE packets to the remote, something is wrong.
    This could occur if both sides have accidentally switched to one-way
    mode waiting for the remote to finish its batch. In this situation,
    one-way should be disabled to prevent a complete deadlock. Note that
    if both sides have finished their batch, the end of session sequence
    (see END packet) should be initiated.


    DEVDATA packet
    ---------------------------------------------------------------------
    Support for the DEVDATA and DEVDACK packets is optional and indicated
    in the INIT packet with the DEV flag in the "Supported options"
    field. The ID value is a long, different for each new device data
    packet sent. A value of zero (0) is not permitted.

    Only one DEVDATA packet may be transmitted at a time; the side
    issuing it then waits either for a timeout of the device transmit
    timer, or for a DEVDACK packet with the correct ID value to be
    received from the remote. If the timer expires before a correct
    DEVDACK packet is received, the DEVDATA packet is again transmitted,
    and the nnumber of device transmit retries incremented. If the
    maximum number of retries is reached, the HYDRA session is aborted;
    apparently the other is not functioning properly, or data is not
    getting through. In either case, the normal operation of the
    protocol (transferring files) will also fail.

    The name of the device to which the data is addressed is transmitted
    as an uppercase fixed-length three character NUL terminated string.
    There are two pre-defined device names as described below. If an
    unknown device name is specified, or a duplicate DEVDATA packet is
    received (one with the same ID value as a previously received and
    acknowledged DEVDATA packet), the packet is simply discarded after
    transmitting a DEVDACK packet with the corresponding ID value.

    DEVDATA and DEVDACK packets do not reset the braindead timer. They
    operate independently from the normal protocol. Device packets may
    only be transmitted after the initialization sequence, and before
    both sides have completed their batch. If a DEVDATA packet has not
    yet been acknowledged, the end of session sequence is delayed until
    a DEVDACK packet has been sent in response.


                       DEVDATA packet dependent data
           +--------------------------------------------------+
           | Long DEVDATA packet ID value                     |
           +--------------------------------------------------+
           | 3 character uppercase device name, NUL terminated|
           +--------------------------------------------------+
           ~ Variable length device data block (0-2048)       ~
           +--------------------------------------------------+


                           Predefined device names
                +---+-------------------------------------+
                |Dev|Description                          |
                +---+-------------------------------------+
                |MSG|Print data in protocol message window|
                |CON|Print data to user console           |
                +---+-------------------------------------+

    The MSG device may be used to notify the remote of protocol-specific
    issues, i.e. "One-way transfer mode". Such messages may be logged,
    but should not be considered to be machine-readable.

    The CON device may be used to implement a "chat" or conversation
    feature. This is a special case in which a session *can* be prolonged
    after end of batch, but not against the remote's will.
    While chat is enabled, there is no transition from the REND to the
    END transmitter state. When a CON device packet is transmitted in
    chat mode and the txstate is REND, the own braindead timer is reset.
    If the other side does initiate the end sequence by sending an END
    packet, the chat mode is immediately terminated and the session ended
    in a clean manner. If one side does not want to (continue) chat, and
    the other side does not comply, the one side will abort after a
    braindead timeout, so this chat system does not mean a security flaw.
    Each side is responsible for keeping the session going on his end
    until its own user has finished chatting. It is suggested that the
    software apply a timeout of say 1 minute to keyboard input, ending
    the chat automatically if the user stops typing but does not exit
    chat mode. Also, the chat mode should be initiated with a special key
    so that it can not erronously be started or prolonged.


    DEVDACK packet
    ---------------------------------------------------------------------
    Transmitted in response to a DEVDATA packet. The device data ID value
    must correspond to the ID of the previously received DEVDATA packet.


                              DEVDACK packet data
                         +---------------------------+
                         | Long device data ID value |
                         +---------------------------+



DEVICE sender (devtxstate HTD_...)
+--------+------------------------------+--------------------------+----------+
|State   |Predicate(s)                  |Action(s)                 |Next state|
+--------+------------------------------+--------------------------+----------+
|Begin   |                              |devtxid = 0               |DONE      |
|        |                              |reset devtxtimer          |          |
+--------+-+----------------------------+--------------------------+----------+
|DONE    |1|wish to send device data &  |increase devtxid          |DATA      |
|        | |other side allows DEV pkts  |devtxretries = 0          |          |
|        | |                            |reset devtxtimer          |          |
|        +-+----------------------------+--------------------------+----------+
|        |2|wish to send device data &  |Tell calling function     |          |
|        | |other doesn't allow DEV pkts|it's not on...            |          |
+--------+-+----------------------------+--------------------------+----------+
|DATA    |1|devtxretries == 10          |Report too many errors    |Abort     |
|        +-+----------------------------+--------------------------+----------+
|        |2|else (devtxretries < 10)    |txpkt DEVDATA(id,dev,data)|DACK      |
|        | |                            |devtxtimer = timeout      |          |
+--------+-+----------------------------+--------------------------+----------+
|DACK    |1|rxpkt DACK &                |reset devtxtimer          |DONE      |
|        | |DACK(id) == devtxid         |                          |          |
|        +-+----------------------------+--------------------------+----------+
|        |2|devtxtimer expired          |Report devtx timeout      |DATA      |
|        | |                            |increase devtxretries     |          |
+--------+-+----------------------------+--------------------------+----------+
 
DEVICE RECEIVER
+--------+------------------------------+--------------------------+----------+
|State   |Predicate(s)                  |Action(s)                 |Next state|
+--------+------------------------------+--------------------------+----------+
|Begin   |                              |devrxid = 0               |DONE      |
+--------+-+----------------------------+--------------------------+----------+
|DONE    |1|rxpkt DEVDATA               |txpkt DEVDACK(id)         |CheckID   |
+--------+-+----------------------------+--------------------------+----------+
|CheckID |1|DEVDATA(id) != devrxid      |devrxid = DEVDATA(id)     |Process   |
|        +-+----------------------------+--------------------------+----------+
|        |2|else (apparent duplicate)   |                          |DONE      |
+--------+-+----------------------------+--------------------------+----------+
|Process |1|DEVDATA(dev) == MSG         |Print protocol message    |DONE      |
|        +-+----------------------------+--------------------------+----------+
|        |2|DEVDATA(dev) == CON         |Output to user console    |DONE      |
|        +-+----------------------------+--------------------------+----------+
|        |3|DEVDATA(dev) == known&ok    |Call processing routine   |DONE      |
|        +-+----------------------------+--------------------------+----------+
|        |4|else (unknown/not-ok device)|One-way into bitbucket    |DONE      |
+--------+-+----------------------------+--------------------------+----------+

 
    Packet length and data block size
    ---------------------------------------------------------------------
    The maximum length of a source data block (i.e. raw, non processed
    input file or device data) is 2048 bytes. The maximum allowed length
    of the packet data is 2048 + 8 = 2056 bytes. The eight bytes are to
    provide sufficient room for the additional fields in the DATA and
    DEVDATA packets. Packetizing adds an additional three to five bytes.
    The maximum length of a framed packet being transmitted can be three
    times the size of its source data depending on what type of encoding
    scheme is used (ASC, HEX, UUE, BIN). The minimum length of a data
    block is 64 bytes.

    The block size of DATA packets is based on the physical (DCE) link
    speed and is established as follows:

            +---------+------------------+-------------------+
            |DCE speed|Maximum block size|Starting block size|
            +---------+------------------+-------------------+
            |  300 bps|     256 bytes    |     256 bytes     |
            | 1200 bps|     512 bytes    |     256 bytes     |
            | 2400 bps|    1024 bytes    |     512 bytes     |
            |>2400 bps|    2048 bytes    |     512 bytes     |
            +---------+------------------+-------------------+

    The blocksize is initialized to the starting blocksize when a session
    is first started. After each kilobyte of file data transmitted, the
    blocksize is doubled until it reaches the maximum allowed blocksize.

    When the maximum allowed blocksize has been reached, the variable
    keeping track of how many bytes are needed to increase the blocksize
    is reset to zero.

    If a request for retransmission (RPOS packet) is received from the
    receiver, the blocksize is immediately set to that specified in the
    retransmission request. Every time this occurs, the number of bytes
    needed to double the blocksize is increased by 1024 with a maximum of
    of 8192 bytes. The end result is that more data has to be
    successfully transmitted before the blocksize is increased for each
    error that occurs.

    The length of a data block is dynamic and always in the range 0-2048
    bytes. A data block is never padded. If there is insufficient data
    to fill a block of the current blocksize, the blocksize is adjusted
    to the amount of remaining data.

    The blocksize logic is not reset between files in a session.


    Timers and retry counters
    =====================================================================
    Each process in the protocol (transmit, receive and device transmit)
    has its own timer and retry counter, and there is one overall
    braindead timer. Allowed are 10 tries, the braindead timeout is 120
    seconds, and the other timeouts are based on the speed of the line
    and the state of the protocol. It can be calculated as (40960/DCE
    rate), with a minimum of 10 seconds and a maximum of 60 seconds.

                     +---------+----------+----------+
                     |DCE speed|Timeout   |Half      |
                     +---------+----------+----------+
                     |  300 bps|60 seconds|30 seconds|
                     | 1200 bps|34 seconds|17 seconds|
                     | 2400 bps|17 seconds| 8 seconds|
                     |>2400 bps|10 seconds| 5 seconds|
                     +---------+----------+----------+

    If the output buffer is empty, the timeout value is halved. In
    general, this is the case if the number of tries is greater than zero
    and during the init and end sequences. These timeouts are not fatal
    situations, they just give the remote a reasonable amount of time to
    receive and respond to a packet before a retry occurs. Duplicate
    packets are always identified and ignored. A retry counter is reset
    if there is a change of state, or a reposition different from the
    previous file offset occurs.

    The braindead timer monitors useful data from the other side: a first
    response to a transmitted supervisiory packet, or a received packet
    with file data at the correct offset. Device packets and packets that
    do not signify any progress of the protocol do not affect the
    braindead timer.

    No other timers (such as one between characters in a packet) are
    necessary.


    Aborting a session
    =====================================================================
    A session is aborted with five consequetive CAN (^X or ASCII 24)
    characters. Whenever a state table mentions "Abort", the following
    procedure is to be followed:

    Clear the output buffer and transmit eight CAN characters followed by
    ten BS (^H or ASCII 8) characters; wait a few seconds for the data to
    be transmitted to the remote, purge the input buffer and exit the
    protocol code.


GENERAL sender (txstate HTX_...)
+--------+------------------------------+--------------------------+----------+
|State   |Predicate(s)                  |Action(s)                 |Next state|
+--------+------------------------------+--------------------------+----------+
|Begin   |                              |txretries = 0             |START     |
|        |                              |reset txtimer             |          |
|        |                              |blksize = startblksize    |          |
|        |                              |goodbytes = 0             |          |
|        |                              |goodneeded = 1024         |          |
|        |                              |braintimer = 120          |          |
+--------+-+----------------------------+--------------------------+----------+
|START   |1|txretries == 10             |Report too many errors    |Abort     |
|        +-+----------------------------+--------------------------+----------+
|        |2|else (txretries < 10)       |txstr AutoStart           |SWAIT     |
|        | |                            |txpkt START               |          |
|        | |                            |txtimer = 5               |          |
+--------+-+----------------------------+--------------------------+----------+
|SWAIT   |1|rxpkt START or              |txretries = 0             |INIT      |
|        | |rxpkt INIT                  |reset txtimer             |          |
|        | |                            |braintimer = 120          |          |
|        +-+----------------------------+--------------------------+----------+
|        |2|txtimer expired             |Report tx timeout         |START     |
|        | |                            |increment txretries       |          |
+--------+-+----------------------------+--------------------------+----------+
|INIT    |1|txretries == 10             |Report too many errors    |Abort     |
|        +-+----------------------------+--------------------------+----------+
|        |2|else (txretries < 10)       |txpkt INIT(linkinfo)      |INITACK   |
|        | |                            |txtimer = timeout/2       |          |
+--------+-+----------------------------+--------------------------+----------+
|INITACK |1|rxpkt INITACK               |txretries = 0             |RINIT     |
|        | |                            |reset txtimer             |          |
|        | |                            |braintimer = 120          |          |
|        +-+----------------------------+--------------------------+----------+
|        |2|txtimer expired             |Report tx timeout         |INIT      |
|        | |                            |increment txretries       |          |
+--------+-+----------------------------+--------------------------+----------+
|RINIT   |1|rxstate != INIT             |                          |NextFile  |
+--------+-+----------------------------+--------------------------+----------+
|NextFile|1|No files left?              |Report end of batch       |ToFName   |
|        | |                            |Set NULL fileinfo         |          |
|        +-+----------------------------+--------------------------+----------+
|        |2|Can access next file?       |Set up fileinfo           |ToFName   |
|        +-+----------------------------+--------------------------+----------+
|        |3|Can't access file?          |Report access failure     |NextFile  |
+--------+-+----------------------------+--------------------------+----------+
|ToFName |                              |txsyncid = 0              |FINFO     |
|        |                              |txretries = 0             |          |
|        |                              |reset txtimer             |          |
+--------+-+----------------------------+--------------------------+----------+
|FINFO   |1|txretries == 10             |Report too many errors    |Abort     |
|        +-+----------------------------+--------------------------+----------+
|        |2|txretries > 0               |txpkt FINFO(fileinfo)     |FINFOACK  |
|        | |                            |txtimer = timeout/2       |          |
|        +-+----------------------------+--------------------------+----------+
|        |3|else (txretries == 0)       |txpkt FINFO(fileinfo)     |FINFOACK  |
|        | |                            |txtimer = timeout         |          |
+--------+-+----------------------------+--------------------------+----------+
|FINFOACK|1|NULL fname (end of batch) & |txtimer = idletimeout     |REND      |
|        | |rxpkt FINFOACK              |braintimer = 120          |          |
|        +-+----------------------------+--------------------------+----------+
|        |2|rxpkt FINFOACK &            |txpos = FINFOACK(pos)     |DATA      |
|        | |FINFOACK(pos) >= 0          |txretries = 0             |          |
|        | |                            |txlastack = 0             |          |
|        | |                            |braintimer = 120          |          |
|        +-+----------------------------+--------------------------+----------+
|        |3|rxpkt FINFOACK &            |They already have file    |NextFile  |
|        | |FINFOACK(pos) == -1)        |braintimer = 120          |          |
|        +-+----------------------------+--------------------------+----------+
|        |4|rxpkt FINFOACK &            |Skip this file for now    |NextFile  |
|        | |FINFOACK(pos) == -2)        |braintimer = 120          |          |
|        +-+----------------------------+--------------------------+----------+
|        |5|txtimer expired             |Report tx timeout         |FINFO     |
|        | |                            |inrease txretries         |          |
+--------+-+----------------------------+--------------------------+----------+
|DATA    |1|rxstate != Done &           |txtimer = idletimeout     |XWAIT     |
|        | |hdxlink == True             |                          |          |
|        +-+----------------------------+--------------------------+----------+
|        |2|rxpkt DATAACK &             |txlastack = DATAACK(pos)  |          |
|        | |DATAACK(pos) > txlastack    |                          |          |
|        +-+----------------------------+--------------------------+----------+
|        |3|rxpkt RPOS &                |Skip this file for now    |SkipFile  |
|        | |RPOS(pos) < 0               |braintimer = 120          |          |
|        +-+----------------------------+--------------------------+----------+
|        |4|rxpkt RPOS &                |Report too many errors    |Abort     |
|        | |RPOS(id) == txsyncid &      |                          |          |
|        | |inc txretries == 10         |                          |          |
|        +-+----------------------------+--------------------------+----------+
|        |5|rxpkt RPOS &                |txpos = RPOS(pos)         |          |
|        | |RPOS(id) != txsyncid &      |txsyncid = RPOS(id)       |          |
|        | |RPOS(pos) >= 0              |txretries = 1             |          |
|        | |                            |blksize = RPOS(blksize)   |          |
|        | |                            |goodbytes = 0             |          |
|        | |                            |inc goodneeded + 1024     |          |
|        | |                            |if (goodneeded > 8192)    |          |
|        | |                            |   goodneeded = 8192      |          |
|        | |                            |braintimer = 120          |          |
|        +-+----------------------------+--------------------------+----------+
|        |6|File seek/read error or     |Skip this file for now    |SkipFile  |
|        | |user wishes to skip file    |                          |          |
|        +-+----------------------------+--------------------------+----------+
|        |7|txwindow &                  |if (txretries > 0)        |DATAACK   |
|        | |txpos >= txlastack+txwindow |   txtimer = timeout/2    |          |
|        | |                            |else                      |          |
|        | |                            |   txtimer = timeout      |          |
|        +-+----------------------------+--------------------------+----------+
|        |8|Enough room in output &     |txpkt DATA(pos,data)      |          |
|        | |more filedata(blksize) to go|txpos += datalen          |          |
|        | |                            |inc goodbytes + datalen   |          |
|        | |                            |if goodbytes > goodneeded |          |
|        | |                            |   Store txpos,blksize    |          |
|        | |                            |   blksize * 2 (max.2048) |          |
|        +-+----------------------------+--------------------------+----------+
|        |9|End of filedata reached     |                          |EOF       |
+--------+-+----------------------------+--------------------------+----------+
|SkipFile|                              |txpos = -1                |EOF       |
|        |                              |txretries = 0             |          |
+--------+-+----------------------------+--------------------------+----------+
|DATAACK |1|txretries == 10             |Report too many errors    |Abort     |
|        +-+----------------------------+--------------------------+----------+
|        |2|rxpkt DATAACK &             |txlastack = DATAACK(pos)  |DATA      |
|        | |DATAACK(pos) > txlastack &  |txretries = 0             |          |
|        | |txpos < DATAACK(pos) + txwin|reset txtimer             |          |
|        +-+----------------------------+--------------------------+----------+
|        |3|rxpkt RPOS                  |Handle RPOS in state DATA |          |
|        | |                            |but stay in this state    |          |
|        +-+----------------------------+--------------------------+----------+
|        |4|txtimer expired             |Report tx timeout         |DATA      |
|        | |                            |increment txretries       |          |
+--------+-+----------------------------+--------------------------+----------+
|XWAIT   |1|rxstate == Done             |reset txtimer             |DATA      |
|        +-+----------------------------+--------------------------+----------+
|        |2|rxpkt DATAACK &             |txlastack = DATAACK(pos)  |          |
|        | |DATAACK(pos) > txlastack    |                          |          |
|        +-+----------------------------+--------------------------+----------+
|        |3|rxpkt RPOS                  |Handle RPOS in state DATA |          |
|        | |                            |but stay in this state    |          |
|        +-+----------------------------+--------------------------+----------+
|        |4|rxpkt IDLE                  |hdxlink = False           |DATA      |
|        | |                            |reset txtimer             |          |
|        +-+----------------------------+--------------------------+----------+
|        |5|txtimer expired             |txpkt IDLE                |          |
|        | |                            |txtimer = idletimeout     |          |
+--------+-+----------------------------+--------------------------+----------+
|EOF     |1|txretries == 10             |Report too many errors    |Abort     |
|        +-+----------------------------+--------------------------+----------+
|        |2|txretries > 0               |txpkt EOF(txpos)          |EOFACK    |
|        | |                            |txtimer = timeout/2       |          |
|        +-+----------------------------+--------------------------+----------+
|        |3|else (txretries == 0)       |txpkt EOF(txpos)          |EOFACK    |
|        | |                            |txtimer = timeout         |          |
+--------+-+----------------------------+--------------------------+----------+
|EOFACK  |1|rxpkt EOFACK                |braintimer = 120          |NextFile  |
|        +-+----------------------------+--------------------------+----------+
|        |2|rxpkt DATAACK &             |txlastack = DATAACK(pos)  |          |
|        | |DATAACK(pos) > txlastack    |                          |          |
|        +-+----------------------------+--------------------------+----------+
|        |3|rxpkt RPOS &                |rxpos == -2               |EOF       |
|        | |RPOS(pos) == -2 &           |                          |          |
|        | |rxpos != -2                 |                          |          |
|        +-+----------------------------+--------------------------+----------+
|        |4|rxpkt RPOS &                |Handle as in state DATA   |DATA      |
|        | |RPOS(pos) >= 0              |                          |          |
|        +-+----------------------------+--------------------------+----------+
|        |5|txtimer expired             |Report tx timeout         |EOF       |
|        | |                            |increment txretries       |          |
+--------+-+----------------------------+--------------------------+----------+
|REND    |1|rxstate == DONE &           |txretries = 0             |END       |
|        | |devtxstate == DONE          |                          |          |
|        +-+----------------------------+--------------------------+----------+
|        |2|txtimer expired             |txpkt IDLE                |          |
|        | |                            |txtimer = idletimeout     |          |
+--------+-+----------------------------+--------------------------+----------+
|END     |1|txretries == 10             |                          |Abort     |
|        +-+----------------------------+--------------------------+----------+
|        |2|else (txretries < 10)       |txpkt END (twice)         |ENDACK    |
|        | |                            |txtimer = timeout/2       |          |
+--------+-+----------------------------+--------------------------+----------+
|ENDACK  |1|rxpkt END                   |txpkt END (thrice)        |Done      |
|        +-+----------------------------+--------------------------+----------+
|        |2|txtimer expired             |Report tx timeout         |END       |
|        | |                            |increment txretries       |          |
+--------+-+----------------------------+--------------------------+----------+

 
 
GENERAL RECEIVER (rxstate HRX_...)
+--------+------------------------------+--------------------------+----------+
|State   |Predicate(s)                  |Action(s)                 |Next state|
+--------+------------------------------+--------------------------+----------+
|Begin   |                              |reset rxtimer             |START     |
|        |                              |lastrxdlen = startblksize |          |
|        |                              |(tx handles braintimer)   |          |
+--------+-+----------------------------+--------------------------+----------+
|INIT    |1|rxpkt INIT &                |txpkt INITACK             |FINFO     |
|        | |INIT(options) are compatible|Set options               |          |
|        | |                            |braintimer = 120          |          |
|        +-+----------------------------+--------------------------+----------+
|        |2|INIT(options) not compatible|Report link failure       |Abort     |
+--------+-+----------------------------+--------------------------+----------+
|FINFO   |1|rxpkt INIT (apparent dup)   |txpkt INITACK             |          |
|        +-+----------------------------+--------------------------+----------+
|        |2|rxpkt FINFO &               |Report end of batch       |          |
|        | |FINFO(fileinfo) == Empty    |txpkt FINFOACK            |DONE      |
|        | |                            |braintimer = 120          |          |
|        +-+----------------------------+--------------------------+----------+
|        |3|rxpkt FINFO &               |do not want this file     |          |
|        | |we already have file        |txpkt FINFOACK(-1)        |          |
|        | |                            |braintimer = 120          |          |
|        +-+----------------------------+--------------------------+----------+
|        |4|rxpkt FINFO &               |Skip this file for now    |          |
|        | |open/diskspace error        |txpkt FINFOACK(-2)        |          |
|        | |                            |braintimer = 120          |          |
|        +-+----------------------------+--------------------------+----------+
|        |5|rxpkt FINFO &               |rxpos = resume offset     |ToData    |
|        | |file we want to resume      |                          |          |
|        +-+----------------------------+--------------------------+----------+
|        |6|rxpkt FINFO &               |rxpos = 0                 |ToData    |
|        | |new file for us             |                          |          |
|        +-+----------------------------+--------------------------+----------+
|        |7|rxpkt EOF (apparent dup)    |txpkt EOFACK              |          |
+--------+-+----------------------------+--------------------------+----------+
|ToData  |                              |txpkt FINFOACK(rxpos)     |DATA      |
|        |                              |rxsyncid = 0              |          |
|        |                              |rxlastsync = 0;           |          |
|        |                              |rxretries = 0             |          |
|        |                              |reset rxtimer             |          |
|        |                              |braintimer = 120          |          |
+--------+-+----------------------------+--------------------------+----------+
|DATA    |1|rxpkt FINFO (apparent dup)  |txpkt FINFOACK(rxpos)     |          |
|        +-+----------------------------+--------------------------+----------+
|        |2|rxpkt DATA &                |Store data                |          |
|        | |DATA(pos) == rxpos          |rxpos += datalen          |          |
|        | |                            |rxretries = 0             |          |
|        | |                            |rxlastsync = rxpos        |          |
|        | |                            |reset rxtimer             |          |
|        | |                            |braintimer = 120          |          |
|        | |                            |if (rxwindow)             |          |
|        | |                            |   txpkt DATAACK(rxpos)   |          |
|        +-+----------------------------+--------------------------+----------+
|        |3|rxpkt DATA &                |Report bad rxpos          |BadPos    |
|        | |DATA(pos) != rxpos          |                          |          |
|        +-+----------------------------+--------------------------+----------+
|        |4|rxpkt EOF &                 |Close file, received ok   |OkEOF     |
|        | |EOF(pos) == rxpos           |                          |          |
|        +-+----------------------------+--------------------------+----------+
|        |5|rxpkt EOF &                 |Close, save for resume    |OkEOF     |
|        | |EOF(pos) == -2              |                          |          |
|        +-+----------------------------+--------------------------+----------+
|        |6|rxpkt EOF &                 |Report bad EOF            |BadPos    |
|        | |EOF(pos) != rxpos           |                          |          |
|        +-+----------------------------+--------------------------+----------+
|        |7|File write error or         |Close, save for resume    |          |
|        | |user wishes to skip file    |rxpos = -2                |          |
|        +-+----------------------------+--------------------------+----------+
|        |8|rxpkt IDLE &                |braintimer = 120          |          |
|        | |hdxlink == False            |                          |          |
+--------+-+----------------------------+--------------------------+----------+
|BadPos  |1|DATA/EOF(pos) <= rxlastsync |rxretries = 0             |Timer     |
|        | |                            |reset rxtimer             |          |
|        | |                            |rxlastsync = pos          |          |
|        +-+----------------------------+--------------------------+----------+
|        |2|DATA/EOF(pos) > rxlastsync  |rxlastsync = pos          |Timer     |
+--------+-+----------------------------+--------------------------+----------+
|Timer   |1|rxtimer expired             |                          |HdxLink   |
|        +-+----------------------------+--------------------------+----------+
|        |2|else (rxtimer not expired)  |                          |DATA      |
+--------+-+----------------------------+--------------------------+----------+
|HdxLink |1|rxretries > 4 &             |hdxlink = True            |Retries   |
|        | |txstate < REND &            |rxretries = 0             |          |
|        | |originator == False &       |                          |          |
|        | |hdxlink == False            |                          |          |
|        +-+----------------------------+--------------------------+----------+
|        |2|else (above not the case)   |                          |Retries   |
+--------+-+----------------------------+--------------------------+----------+
|Retries |1|inc rxretries == 10         |Report too many errors    |Abort     |
|        +-+----------------------------+--------------------------+----------+
|        |2|rxretries == 1              |increase rxsyncid         |RPos      |
|        +-+----------------------------+--------------------------+----------+
|        |3|else (rxretries > 1)        |                          |RPos      |
+--------+-+----------------------------+--------------------------+----------+
|RPos    |                              |lastrxdatalen/=2 (min.64) |DATA      |
|        |                              |txpkt RPOS (rxpos,        |          |
|        |                              |   lastrxdatalen,rxsyncid)|          |
|        |                              |rxtimer = timeout         |          |
+--------+------------------------------+--------------------------+----------+
|OkEOF   |                              |txpkt EOFACK              |FINFO     |
|        |                              |reset rxtimer             |          |
|        |                              |braintimer = 120          |          |
+--------+-+----------------------------+--------------------------+----------+
|DONE    |1|rxpkt FINFO (apparent dup)  |txpkt FINFOACK(-2)        |          |
+--------+-+----------------------------+--------------------------+----------+


    HYDRA in FidoNet technology mailers
    =====================================================================
    HYDRA is suitable for use in FidoNet mailers. It can be implemented
    for EMSI and FTS-6 mail sessions. The FTS-6 (YooHoo) capability bit
    for HYDRA is 0x0020 (DOES_HYDRA). The EMSI and IEMSI protocol
    capability flag is HYD.

    When utilizing HYDRA in a mail session, two complete batches are
    always performed. Little else differs from a normal FTS-6 ZedZap mail
    session. The first batch is used to transmit all mail, files, and
    file requests by both sides. The second batch is always performed,
    sending nothing if there are no file requests to honor. The data
    buffers are not purged between the two batches since HYDRA ignores
    any leftovers from the previous batch (END packets, etc.).

    To integrate HYDRA into an existing mailer, the same code used for
    the ZedZap session flow can be used, but instead of one transmit and
    one receive session, two transmit sessions (or batches) are used.
    When the HYDRA end of batch is initiated it will not be terminated
    until an end of batch has been received from the remote and the end
    of session sequence has been finished.

    Fido and FidoNet are registered marks of Tom Jennings and Fido
    Software.


    Error detection using CRCs
    =====================================================================
    CRC (Cyclic Redundancy Check) values only provide their promised
    maximum error detection capability when properly applied, which
    involves calculating and transmitting low-bit first, presetting the
    CRC with all ones, and transmitting the ones' complement of the
    result. The receiver also initializes to all ones, processes all of
    the data AND the following CRC, and the result should match a "magic
    value" which is 0xf0b8 for the 16-bit CRC and 0xdebb20e3 for the
    32-bit CRC.

    The easiest and fastest way to perform CRC calculations is by using a
    table that does the algorithm's shift-operations in 8-bits at a time.


    CRC-16 error detection
    ---------------------------------------------------------------------
    16-bit CRC using the CCITT CRC-16 polynomial. This is the default at
    startup, and always used for HEX packets even if both sides are
    capable of handling 32-bit CRCs.

    This CRC-16 is not identical to the one used by the Xmodem and Zmodem
    file transfer protocols. The polynomial is the same
    (X^16+X^12+X^5+X^0 or 0x8408) but the bit-ordering is the opposite,
    and preconditioning and postconditioning is used as in 32-bit CRCs.
    This method is also used by the European version of X.25.

    The 16-bit CRC table is created as follows (pseudocode, the variable
    CRC16 and the table of 256 entries are 16-bit unsigned integers):

        FOR (i=0 TO 255)
            {
            CRC16=i
            FOR (N=1 TO 8)
                {
                IF (CRC16 AND 1)
                    CRC16=(CRC16 >> 1) XOR 0x8408
                ELSE
                    CRC16=CRC16 >> 1
                }
            CRC16TAB[i]=CRC16;
            }

    When processing data, each byte is run through the CRC calculation
    routine as follows (variable CRC stores the 16-bit CRC value/result,
    C is the next 8-bit char):

        CRC=CRC16TAB[(CRC XOR C) AND 0xff] XOR ((CRC>>8) AND 0x00ff)


    CRC-32 error detection
    ---------------------------------------------------------------------
    32-bit CRC using the CCITT CRC-32 polynomial. Support of CRC-32 is
    optional and signalled in the INIT packet.

    If both sides indicate they can handle CRC-32, all packets except
    those transmitted in HEX format use this algorithm instead of CRC-16
    to improve error detection.

    This CRC-32 is identical to the one used by the Zmodem protocol.
    The polynomial is (0xedb88320):

    X^32+X^26+X^23+X^22+X^16+X^12+X^11+X^10+X^8+X^7+X^5+X^4+X^2+X^1+X^0

    The principal method of calculation, transmission, and checking is
    identical to CRC-16 as described above, but the "magic value" for
    32-bit CRC is 0xdebb20e3.

    The CRC-32 table is created as follows (pseudocode, the variable
    CRC32 and the table of 256 entries are 32-bit unsigned integers):

    FOR (i=0 TO 255)
        {
        CRC32=i
        FOR (N=1 TO 8)
            {
            IF (CRC32 AND 1)
                CRC32 = (CRC32 >> 1) XOR 0xedb88320
            ELSE
                CRC32 = CRC32 >> 1
            }
        CRC32TAB[i] = CRC32;
        }

    When processing data, each byte is run through the CRC calculation
    routine as follows (variable CRC stores the 32-bit CRC value/result,
    C is the next 8-bit character):

        CRC=CRC32TAB[(CRC XOR C) AND 0xFF] XOR ((CRC>>8) AND 0x00ffffff)


    The authors
    =====================================================================
    The authors can be reached at the following addresses:

    Joaquim H. Homrighausen                    Arjen G. Lentz
    389, route d'Arlon                         Lentz Software Development
    L-8011 Strassen                            Langegracht 7B
    Luxembourg                                 3811 BT Amersfoort
                                               The Netherlands
	joho@ae.lu
    FidoNet 2:270/17                           aglentz@fido.lu
                                               FidoNet 2:283/512


    The name HYDRA
    =====================================================================
    Hydra is a greek mythological creature (the watersnake). Like the
    Nemeic lion, Hydra is the daughter of the giant Typhon and the snake
    Echidna.

    She grew up in the marshes of Lerna near/in Argolis (Argos). There
    she ate entire herds of cattle and destroyed large cropfields. Later,
    she lived in caves on a hill near the spring of Amymone.

    Hydra is a monstrous large snake with nine heads: eight mortal ones,
    and one (the middle one) immortal. She was defeated and killed by
    Heracles (Hercules) - son of Zeus and Alcemene, grandson of Perseus -
    as the second of his twelve tasks, with the help of his cousin
    Iolaos. Every time he cut of one of the heads with his sword, two new
    heads grew in its place. So Iolaos scorched the wound of each cut off
    head with burning branches so the head couldn't grow on again.

    Heracles buried the last and immortal head under a stone nearby. He
    also dipped his arrows in Hydra's poisonous blood, thereafter the
    wounds caused by those arrows were incurable.


    Also star constellation (sign of the watersnake) in the equatorial
    zone.


    Also a type of sweetwater polip (the Hydroidea Thin, tubeshaped body
    can be full contracted, just like the six (or more) tentacles. There
    is no generation change, the gender-products grow directly on the
    body.

    The animals catch their prey with nettlecells, and are very verocious.
    They can be found in various stilstanding and flowing water and were
    first described by Anthonie van Leeuwenhoek in the year 1704.


    Also small island (spelled Idhra in modern Greek) of the Sargonic
    group in the Aegean Sea, just of the eastern tip of the Argolis
    peninsula of the Peloponesus (Attika). Its length (NE/SW) is 21 km,
    with a total area of 49,6 square km. Its highest point is 597 meters
    above sea level. Population of 2794 (latest census: 1981). Only one
    real city with the same name as the island. Once quite wooded and
    well watered, now denuded and dry, with almost no arable land
    (infertile limestone). Certain times of the year the people have to
    ship in water from the main land. Its Turkish name is Camliza which
    means "Place of Pines".

    References:
         Dutch:  Oosthoeks Encyclopedie
                 Grote Winklerprins Encyclopedie
       English:  Encyclopaedia Brittannica

BackGo Back