b2f:bcf_v1
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
b2f:bcf_v1 [2025/02/14 13:29] – [Binary Compressed Forward Version 1] f4hof | b2f:bcf_v1 [2025/02/14 15:03] (current) – [Transfer Mode] f4hof | ||
---|---|---|---|
Line 1: | Line 1: | ||
====== Binary Compressed Forward Version 1 ====== | ====== Binary Compressed Forward Version 1 ====== | ||
- | This version of the protocol is an extension to both the [[b2f: | + | This protocol |
- | This version is advertised in the SID Features field with the '' | + | This version is advertised in the SID Features field with the '' |
+ | |||
+ | // | ||
The main differences with version 0 are: | The main differences with version 0 are: | ||
* An enlarged set of selective retrieval replies. | * An enlarged set of selective retrieval replies. | ||
- | * The first transmitted block is slightly changed | + | * The first transmitted block structure |
- | + | ||
+ | The Binary Compressed Forward protocol MUST operate over a [[https:// | ||
===== Commands ===== | ===== Commands ===== | ||
Line 20: | Line 23: | ||
| R | | Reject | Message is rejected | | | R | | Reject | Message is rejected | | ||
| E | | Error | Invalid proposal | | | E | | Error | Invalid proposal | | ||
- | | | + | | |
+ | |||
+ | ===== Transfer Mode ===== | ||
+ | |||
+ | Each transfer is equivalent to the transfer of one message of the standard protocol. It SHALL NOT be followed by the '' | ||
+ | |||
+ | The first transmitted data block MUST contain the full binary file's CRC16 checksum, the full uncompressed file size as a 32 bit little-endian integer, and the binary content of the file, starting from the start of the file, or from the requested offset, depending on the decision transmitted through the selective retrieval command. | ||
+ | |||
+ | In case of a checksum error, the message or the file MUST NOT be considered as transmitted. The system MUST send the comment, then issue a disconnect request. | ||
+ | |||
+ | < | ||
+ | |||
+ | |||
+ | |||
+ | < | ||
+ | The first transmitted block of data must contain a header containing : | ||
+ | the CRC16 of the full binary file (2 bytes) | ||
+ | the size of the full uncompressed file (4 bytes) | ||
+ | This data is in little-endian Intel format (less significant first). | ||
+ | The last data block is followed by the end of file specifier and the checksum of the data sent. | ||
+ | |||
+ | End of file specifier format : | ||
+ | |||
+ | <EOT> 1 byte = 04 hex Checksum 1 byte = 00 to ff hex | ||
+ | |||
+ | |||
+ | |||
+ | The checksum is equal to the sum of all the data bytes of the transmitted data, modulo 256 (8 bits) and then two's complemented. | ||
+ | |||
+ | The checking of the checksum is very simple : | ||
+ | |||
+ | The sum of the data bytes from the file and the checksum received modulo 256 shall be equal to zero. | ||
+ | |||
+ | In case of a checksum error, the message or the file is ignored and the system issues a disconnect request after having sent the comment : | ||
+ | |||
+ | |||
+ | |||
+ | *** Erreur checksum | ||
+ | |||
+ | A CRC16 is computed for the full binary file including the length of the uncompressed file (4 bytes in top of file). In the case of a resume, it will be the only means available to ensure that all the parts of the message or file has been received correctly. | ||
+ | The LZHUF_1 program, when used with option " | ||
+ | In case of forwarding with a BBS using version 0, only the part from offset 2 will be sent | ||
+ | In case of forwarding with a BBS using version 1, the 6 top bytes will be always sent, then if resume seek to asked offset, then send data. | ||
+ | Ascii values of the characters (1 byte) used in the protocol : | ||
+ | |||
+ | <NUL> = 00 hex | ||
+ | |||
+ | <SOH> = 01 hex | ||
+ | |||
+ | <STX> = 02 hex | ||
+ | |||
+ | <EOT> = 04 hex | ||
+ | </ |
b2f/bcf_v1.1739539753.txt.gz · Last modified: 2025/02/14 13:29 by f4hof