Differences

This shows you the differences between two versions of the page.

--- b2f:bcf_v1 [2025/02/14 14:19] – [Transfer Mode] f4hof
+++ b2f:bcf_v1 [2025/02/14 15:03] (current) – [Transfer Mode] f4hof
@@ Line 1: / Line 1: @@
 ====== Binary Compressed Forward Version 1 ======
-This version of the protocol is an extension to both the [[b2f:ascii|ASCII Basic Protocol]] and the [[b2f:bcf_v0|Binary Compressed Forward Version 0]]. It is used to transfer compressed ASCII Messages or binary files.
+This protocol version is an extension to both the [[b2f:ascii|ASCII Basic Protocol]] and the [[b2f:bcf_v0|Binary Compressed Forward Version 0]]. It is used to transfer compressed ASCII Messages or binary files.
-This version is advertised in the SID Features field with the ''B1'' and ''F'' strings
+This version is advertised in the SID Features field with the ''B1'' and ''F'' strings. A SID with the ''B1'' string but no ''F'' will be treated as if neither extensions have been advertised.
 //F4HOF's comment: some implementations actively check against the presence of ''B1F'', so it's strongly recommended to concatenate those flags together//.
@@ Line 10: / Line 10: @@
   * An enlarged set of selective retrieval replies.
   * The first transmitted block structure is slightly changed
+The Binary Compressed Forward protocol MUST operate over a [[https://en.wikipedia.org/wiki/8-bit_clean|8-bit clean]] communication bearer, which provides reliable and ordered delivery.
 ===== Commands =====
@@ Line 22: / Line 23: @@
 |  R  |     | Reject | Message is rejected |
 |  E  |     | Error  | Invalid proposal |
-|  A  |  !  | Append | Send the message, starting from offset then delete it from the queue |
+|  !  |  A  | Append | Send the message, starting from offset then delete it from the queue |
 ===== Transfer Mode =====
+Each transfer is equivalent to the transfer of one message of the standard protocol. It SHALL NOT be followed by the ''Ctrl+Z'' character, the end of file specifier is defined in another way.
+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.
+<code>*** Erreur checksum</code>
 <code>