bbs/deb-mbse
Archived
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
This repository has been archived on 2024-04-08. You can view files and clone it, but cannot push or open issues or pull requests.
ced93cb072
deb-mbse/html/ftsc/fsc-0072.html
Michiel Broek 0aa608b565 Fixed HTML codes in Fidonet documents
2002-02-16 21:38:40 +00:00

1927 lines
108 KiB
HTML
Executable File
Raw Blame History

<HTML>
<!-- $Id$ -->
<HEAD>
<TITLE>The HYDRA file transfer protocol.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
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 "&gt;&gt;" is a shift operation to the right, "R &gt;&gt; 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 &amp; |format = UUEPKT |Format |
| | |UUENCODED packets allowed | | |
| +-+----------------------------+--------------------------+----------+
| |2|ASCII packets allowed |format = ASCPKT |Format |
| +-+----------------------------+--------------------------+----------+
| |3|7 bit link &amp; |format = HEXPKT |Format |
| | |escape all control chars &amp; | | |
| | |UUE/ASC pkts not allowed | | |
+--------+-+----------------------------+--------------------------+----------+
|Format | |Append format byte to data|CRC |
+--------+-+----------------------------+--------------------------+----------+
|CRC |1|format != HEXPKT &amp; |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 &amp; |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 &amp; |Eat these |NextByte |
| | |n == XON or n == XOFF | | |
| +-+----------------------------+--------------------------+----------+
| |3|Escape all control chars &amp; |Eat these |NextByte |
| | |n &lt; 32 or n == 127 | | |
| +-+----------------------------+--------------------------+----------+
| |4|rxdle &gt; 0 | |Escape |
| +-+----------------------------+--------------------------+----------+
| |5|else (no eating or escaping)| |Store |
+--------+-+----------------------------+--------------------------+----------+
|DLE |1|rxdle == 5 |Report remote wants abort |Abort |
| +-+----------------------------+--------------------------+----------+
| |2|else (rxdle &lt; 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 &gt;= maximum |Pkt too long / lost PKTEND|Reset |
| +-+----------------------------+--------------------------+----------+
| |3|else (fmt &gt; 0 &amp; len &lt; 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 &amp; |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 &amp; |Output H_DLE |Output |
| | |n == XON or n == XOFF |c = c XOR 0x40 | |
| +-+----------------------------+--------------------------+----------+
| |3|Escape Telenet &amp; |Output H_DLE |Output |
| | |n == CR &amp; |c = c XOR 0x40 | |
| | |txlasc == '@' | | |
| +-+----------------------------+--------------------------+----------+
| |4|Escape all control chars &amp; |Output H_DLE |Output |
| | |n &lt; 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 &lt; 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 &lt;&lt; 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 &lt;&lt; bitshift) |Shift |
| | | |BINPKT escape (n &amp; 0x7f) | |
| | | |n = n &gt;&gt; 7 | |
| | | |increment bitshift | |
+--------+-+----------------------------+--------------------------+----------+
|Shift |1|bitshift == 7 |BINPKT escape (n &amp; 0x7f) |Reset |
| +-+----------------------------+--------------------------+----------+
| |2|else (bitshift &lt; 7) | |NextByte |
+--------+-+----------------------------+--------------------------+----------+
|Flush |1|bitshift &gt; 0 |BINPKT escape (n &amp; 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 &lt;&lt; bitshift) | |
| | | |bitshift = bitshift + 7 | |
+--------+-+----------------------------+--------------------------+----------+
|Shift |1|bitshift &gt;= 8 |Output (n AND 0xff) |NextByte |
| | | |n = n &gt;&gt; 8 | |
| | | |bitshift = bitshift - 8 | |
| +-+----------------------------+--------------------------+----------+
| |2|else (bitshift &lt; 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]&gt;&gt;2) | |
| | | |UUE(in[0]&lt;&lt;4 OR in[1]&gt;&gt;4) | |
| | | |UUE(in[1]&lt;&lt;2 OR in[2]&gt;&gt;6) | |
| | | |UUE(in[2]) | |
| | | |(UUE: (c AND 0x3f) + '!') | |
+--------+-+----------------------------+--------------------------+----------+
|Flush |1|No more bytes left | |Done |
| +-+----------------------------+--------------------------+----------+
| |2|One byte left |UUE(in[0]&gt;&gt;2) |Done |
| | | |UUE(in[0]&lt;&lt;4) | |
| +-+----------------------------+--------------------------+----------+
| |3|Two bytes left |UUE(in[0]&gt;&gt;2) |Done |
| | | |UUE(in[0]&lt;&lt;4 OR in[1]&gt;&gt;4) | |
| | | |UUE(in[1]&lt;&lt;2) | |
+--------+-+----------------------------+--------------------------+----------+
UUEPKT Decoding
+--------+------------------------------+--------------------------+----------+
|State |Predicate(s) |Action(s) |Next state|
+--------+-+----------------------------+--------------------------+----------+
|NextByte|1|Less than four bytes left | |Flush |
| +-+----------------------------+--------------------------+----------+
| |2|else (four or more left) &amp; |UD(i[0])&lt;&lt;2 OR UD(i[1])&gt;&gt;4| |
| | |(c AND 0x7f) is in UUE range|UD(i[1])&lt;&lt;4 OR UD(i[2])&gt;&gt;2| |
| | | |UD(i[2])&lt;&lt;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 &amp; |UD(i[0])&lt;&lt;2 OR UD(i[1])&gt;&gt;4|Done OK |
| | |(c AND 0x7f) is in UUE range| | |
| +-+----------------------------+--------------------------+----------+
| |3|Three bytes left &amp; |UD(i[0])&lt;&lt;2 OR UD(i[1])&gt;&gt;4|Done OK |
| | |(c AND 0x7f) is in UUE range|UD(i[1])&lt;&lt;4 OR UD(i[2])&gt;&gt;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<CR> (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:
&lt;RevDate&gt;&lt;ProductName&gt;&lt;,&gt;&lt;ProductRevision&gt;[&lt;,&gt;&lt;ProductSerial#&gt;]
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 &lt;XON&gt; and &lt;XOFF&gt; characters.
TLN Escape the &lt;CR&gt;@&lt;CR&gt; 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 &lt;Drive&gt;: (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 |
+------+----------------------------------------------+
| &gt;=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 |
+------+-------------------------------------------+
| &gt;=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 |
+------+----------------------------------------+
| &gt;=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 &amp; |increase devtxid |DATA |
| | |other side allows DEV pkts |devtxretries = 0 | |
| | | |reset devtxtimer | |
| +-+----------------------------+--------------------------+----------+
| |2|wish to send device data &amp; |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 &lt; 10) |txpkt DEVDATA(id,dev,data)|DACK |
| | | |devtxtimer = timeout | |
+--------+-+----------------------------+--------------------------+----------+
|DACK |1|rxpkt DACK &amp; |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&amp;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 |
|&gt;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|
|&gt;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 &lt; 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 &lt; 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 &gt; 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) &amp; |txtimer = idletimeout |REND |
| | |rxpkt FINFOACK |braintimer = 120 | |
| +-+----------------------------+--------------------------+----------+
| |2|rxpkt FINFOACK &amp; |txpos = FINFOACK(pos) |DATA |
| | |FINFOACK(pos) &gt;= 0 |txretries = 0 | |
| | | |txlastack = 0 | |
| | | |braintimer = 120 | |
| +-+----------------------------+--------------------------+----------+
| |3|rxpkt FINFOACK &amp; |They already have file |NextFile |
| | |FINFOACK(pos) == -1) |braintimer = 120 | |
| +-+----------------------------+--------------------------+----------+
| |4|rxpkt FINFOACK &amp; |Skip this file for now |NextFile |
| | |FINFOACK(pos) == -2) |braintimer = 120 | |
| +-+----------------------------+--------------------------+----------+
| |5|txtimer expired |Report tx timeout |FINFO |
| | | |inrease txretries | |
+--------+-+----------------------------+--------------------------+----------+
|DATA |1|rxstate != Done &amp; |txtimer = idletimeout |XWAIT |
| | |hdxlink == True | | |
| +-+----------------------------+--------------------------+----------+
| |2|rxpkt DATAACK &amp; |txlastack = DATAACK(pos) | |
| | |DATAACK(pos) &gt; txlastack | | |
| +-+----------------------------+--------------------------+----------+
| |3|rxpkt RPOS &amp; |Skip this file for now |SkipFile |
| | |RPOS(pos) &lt; 0 |braintimer = 120 | |
| +-+----------------------------+--------------------------+----------+
| |4|rxpkt RPOS &amp; |Report too many errors |Abort |
| | |RPOS(id) == txsyncid &amp; | | |
| | |inc txretries == 10 | | |
| +-+----------------------------+--------------------------+----------+
| |5|rxpkt RPOS &amp; |txpos = RPOS(pos) | |
| | |RPOS(id) != txsyncid &amp; |txsyncid = RPOS(id) | |
| | |RPOS(pos) &gt;= 0 |txretries = 1 | |
| | | |blksize = RPOS(blksize) | |
| | | |goodbytes = 0 | |
| | | |inc goodneeded + 1024 | |
| | | |if (goodneeded &gt; 8192) | |
| | | | goodneeded = 8192 | |
| | | |braintimer = 120 | |
| +-+----------------------------+--------------------------+----------+
| |6|File seek/read error or |Skip this file for now |SkipFile |
| | |user wishes to skip file | | |
| +-+----------------------------+--------------------------+----------+
| |7|txwindow &amp; |if (txretries &gt; 0) |DATAACK |
| | |txpos &gt;= txlastack+txwindow | txtimer = timeout/2 | |
| | | |else | |
| | | | txtimer = timeout | |
| +-+----------------------------+--------------------------+----------+
| |8|Enough room in output &amp; |txpkt DATA(pos,data) | |
| | |more filedata(blksize) to go|txpos += datalen | |
| | | |inc goodbytes + datalen | |
| | | |if goodbytes &gt; 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 &amp; |txlastack = DATAACK(pos) |DATA |
| | |DATAACK(pos) &gt; txlastack &amp; |txretries = 0 | |
| | |txpos &lt; 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 &amp; |txlastack = DATAACK(pos) | |
| | |DATAACK(pos) &gt; 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 &gt; 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 &amp; |txlastack = DATAACK(pos) | |
| | |DATAACK(pos) &gt; txlastack | | |
| +-+----------------------------+--------------------------+----------+
| |3|rxpkt RPOS &amp; |rxpos == -2 |EOF |
| | |RPOS(pos) == -2 &amp; | | |
| | |rxpos != -2 | | |
| +-+----------------------------+--------------------------+----------+
| |4|rxpkt RPOS &amp; |Handle as in state DATA |DATA |
| | |RPOS(pos) &gt;= 0 | | |
| +-+----------------------------+--------------------------+----------+
| |5|txtimer expired |Report tx timeout |EOF |
| | | |increment txretries | |
+--------+-+----------------------------+--------------------------+----------+
|REND |1|rxstate == DONE &amp; |txretries = 0 |END |
| | |devtxstate == DONE | | |
| +-+----------------------------+--------------------------+----------+
| |2|txtimer expired |txpkt IDLE | |
| | | |txtimer = idletimeout | |
+--------+-+----------------------------+--------------------------+----------+
|END |1|txretries == 10 | |Abort |
| +-+----------------------------+--------------------------+----------+
| |2|else (txretries &lt; 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 &amp; |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 &amp; |Report end of batch | |
| | |FINFO(fileinfo) == Empty |txpkt FINFOACK |DONE |
| | | |braintimer = 120 | |
| +-+----------------------------+--------------------------+----------+
| |3|rxpkt FINFO &amp; |do not want this file | |
| | |we already have file |txpkt FINFOACK(-1) | |
| | | |braintimer = 120 | |
| +-+----------------------------+--------------------------+----------+
| |4|rxpkt FINFO &amp; |Skip this file for now | |
| | |open/diskspace error |txpkt FINFOACK(-2) | |
| | | |braintimer = 120 | |
| +-+----------------------------+--------------------------+----------+
| |5|rxpkt FINFO &amp; |rxpos = resume offset |ToData |
| | |file we want to resume | | |
| +-+----------------------------+--------------------------+----------+
| |6|rxpkt FINFO &amp; |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 &amp; |Store data | |
| | |DATA(pos) == rxpos |rxpos += datalen | |
| | | |rxretries = 0 | |
| | | |rxlastsync = rxpos | |
| | | |reset rxtimer | |
| | | |braintimer = 120 | |
| | | |if (rxwindow) | |
| | | | txpkt DATAACK(rxpos) | |
| +-+----------------------------+--------------------------+----------+
| |3|rxpkt DATA &amp; |Report bad rxpos |BadPos |
| | |DATA(pos) != rxpos | | |
| +-+----------------------------+--------------------------+----------+
| |4|rxpkt EOF &amp; |Close file, received ok |OkEOF |
| | |EOF(pos) == rxpos | | |
| +-+----------------------------+--------------------------+----------+
| |5|rxpkt EOF &amp; |Close, save for resume |OkEOF |
| | |EOF(pos) == -2 | | |
| +-+----------------------------+--------------------------+----------+
| |6|rxpkt EOF &amp; |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 &amp; |braintimer = 120 | |
| | |hdxlink == False | | |
+--------+-+----------------------------+--------------------------+----------+
|BadPos |1|DATA/EOF(pos) &lt;= rxlastsync |rxretries = 0 |Timer |
| | | |reset rxtimer | |
| | | |rxlastsync = pos | |
| +-+----------------------------+--------------------------+----------+
| |2|DATA/EOF(pos) &gt; rxlastsync |rxlastsync = pos |Timer |
+--------+-+----------------------------+--------------------------+----------+
|Timer |1|rxtimer expired | |HdxLink |
| +-+----------------------------+--------------------------+----------+
| |2|else (rxtimer not expired) | |DATA |
+--------+-+----------------------------+--------------------------+----------+
|HdxLink |1|rxretries &gt; 4 &amp; |hdxlink = True |Retries |
| | |txstate &lt; REND &amp; |rxretries = 0 | |
| | |originator == False &amp; | | |
| | |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 &gt; 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 &gt;&gt; 1) XOR 0x8408
ELSE
CRC16=CRC16 &gt;&gt; 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&gt;&gt;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 &gt;&gt; 1) XOR 0xedb88320
ELSE
CRC32 = CRC32 &gt;&gt; 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&gt;&gt;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
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0">Go Back</A>
</BODY>
</HTML>
Reference in New Issue View Git Blame Copy Permalink