User Tools

Site Tools


b2f:bcf_v0

Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
b2f:bcf_v0 [2025/02/14 09:17] – [Binary Compressed Forward Version 0] f4hofb2f: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 ''B'' but no ''F'' will be treated as if neither extensions have been advertised.    * 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 ''B'' but no ''F'' will be treated as if neither extensions have been advertised. 
  
-The Binary Compressed Forward protocol MUST happen over a [[https://en.wikipedia.org/wiki/8-bit_clean|8-bit clean]] communication bearer, which provides reliable and ordered delivery.+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.
  
-===== Transfer Modes =====+===== Commands =====
  
-The actual message content is transferred in a different format from the ASCII Basic Protocol+The command list almost stays the same as the ASCII Basis Protocol.
-  +
-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 main change is the [[b2f:ascii#pending_mail_proposal|pending mail proposal]] is replaced by the following proposals.
  
-Unlike YAPP transfers, there is no individual packet acknowledgement during the transmission of messages, the protocol is thus simpler and more efficient. +^ Proposal ^ Usage ^ 
 +| ''FA'' | Pending ASCII Message Proposal | 
 +| ''FB'' | Pending Binary File Proposal |
  
-==== ASCII Message Transfer Mode ====+The proposal format stays the same as the one described in the [[b2f:ascii#pending_mail_proposal|pending mail proposal]] specification: 
 + 
 +==== Pending ASCII Message Proposal ==== 
 + 
 +==== Pending Binary File Proposal ==== 
 + 
 +===== Transfer Mode ====
 + 
 +The message/file payload is transferred using a different format from the ASCII Basic Protocol. 
 + 
 +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 37: Line 54:
 Security considerations: 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.   * 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 Mode ====+==== Binary File Transfer Header ==== 
 + 
 +FIXME proposal format definition
  
 Message header format: Message header format:
Line 94: Line 113:
 <code>*** Erreur checksum</code> <code>*** Erreur checksum</code>
  
 +===== Transaction flow =====
 +
 +FIXME To be completed
b2f/bcf_v0.1739524650.txt.gz · Last modified: 2025/02/14 09:17 by f4hof