b2f:bcf_v0
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
b2f:bcf_v0 [2025/02/14 08:58] – [ASCII Message Transfer Mode] f4hof | b2f:bcf_v0 [2025/02/14 10:45] (current) – [Binary File Transfer Mode] f4hof | ||
---|---|---|---|
Line 6: | Line 6: | ||
* As it is an extension of the basic protocol, the SID extension field MUST also advertise the ASCII Basic Protocol with the letter F. A SID with the letter '' | * As it is an extension of the basic protocol, the SID extension field MUST also advertise the ASCII Basic Protocol with the letter F. A SID with the letter '' | ||
- | ===== Transfer Modes ===== | + | The Binary Compressed Forward protocol MUST operate over a [[https:// |
- | The actual message content is transferred in a different format from the ASCII Basic Protocol. | + | ===== Commands ===== |
- | + | ||
- | The format used is derived from the YAPP protocol which is very reliable. Each message is made up of a header, blocks of data, an end of message marker and a checksum. | + | |
- | This is directly equivalent to the transfer of one message in the ASCII Basic Protocol. | + | The command list almost stays the same as the ASCII Basis Protocol. |
- | Unlike YAPP transfers, there is no individual packet acknowledgement during | + | The main change |
- | ==== ASCII Message Transfer Mode ==== | + | ^ Proposal ^ Usage ^ |
+ | | '' | ||
+ | | '' | ||
+ | |||
+ | The proposal format stays the same as the one described in the [[b2f: | ||
+ | |||
+ | ==== Pending | ||
+ | |||
+ | ==== Pending Binary File Proposal ==== | ||
+ | |||
+ | ===== Transfer Mode ===== | ||
+ | |||
+ | The message/ | ||
+ | |||
+ | Each message is made up of a header, blocks of data, an end-of-message marker, and a checksum. | ||
+ | |||
+ | Unlike YAPP transfers, there is no individual packet acknowledgement during the transmission of messages. The protocol is thus simpler and more efficient. | ||
+ | |||
+ | As with the underlying protocol, the channel direction is immediately reversed after the completion of a transfer batch. | ||
+ | ==== ASCII Message Transfer Header ==== | ||
+ | |||
+ | FIXME proposal format definition | ||
Message header format: | Message header format: | ||
Line 27: | Line 46: | ||
<code abnf> | <code abnf> | ||
- | BCFv0_ASCII_HDR_SZ | + | BCFv0_ASCII_ATTR_SZ |
BCFv0_ASCII_HDR_TITLE = 1*80( WSP / HTAB / VCHAR ) | BCFv0_ASCII_HDR_TITLE = 1*80( WSP / HTAB / VCHAR ) | ||
BCFv0_ASCII_OFFSET | BCFv0_ASCII_OFFSET | ||
- | BCFv0_ASCII_HEADER | + | BCFv0_ASCII_HEADER |
</ | </ | ||
- | ==== Binary File Transfer | + | Security considerations: |
+ | * If you're using a memory-unsafe language, you SHOULD pay extra care with the attribute size field to avoid buffer overflow attacks. | ||
+ | ==== Binary File Transfer | ||
+ | |||
+ | FIXME proposal format definition | ||
Message header format: | Message header format: | ||
Line 83: | Line 106: | ||
To perform validation, compute the sum of data and checksum bytes, modulo 256. The checksum is considered valid if the result of the last calculation equals 0. | To perform validation, compute the sum of data and checksum bytes, modulo 256. The checksum is considered valid if the result of the last calculation equals 0. | ||
- | In case of a checksum error, the message or the file is ignored | + | In case of a checksum error: |
+ | - The message or the file is ignored. | ||
+ | - The following comment is sent back. | ||
+ | - The system issues a disconnect request | ||
< | < | ||
+ | ===== Transaction flow ===== | ||
+ | |||
+ | FIXME To be completed |
b2f/bcf_v0.1739523495.txt.gz · Last modified: 2025/02/14 08:58 by f4hof