FBB forwarding protocol

Fbb forwarding protocols can operate either in ASCII or binary compressed modes.

This page describes the three versions of this protocol. Each version is backwards compatible with the previous one. These versions are :

• Ascii basic protocol
• Binary compressed protocol version 0
• Binary compressed protocol version 1

Source code is available. Click here.

Ascii Basic Protocol

• The Ascii protocol in FBB software implements two forward protocols. The first one is the standard MBL/RLI protocol. The second one was developed for greater efficiency, particularly on long links where the command propagation delays occupy a significant portion of time. The exchange of commands and data is reduced to a minimum by sending several requests at a time. In normal VHF use up to five requests or messages are sent in one block. The data transfer direction is reversed after every block of data, This minimises the delaying effect of long links through Nodes and digipeaters, and also saves some time over short links (eg HF...).
  
• FBB protocol is very simple in operation. It is based on MID/BID message identification. The protocol availability is indicated by the F letter in the SID (system type identifier contained in square brackets). All protocol command lines start in first column with the 'F' character. All protocol command lines are terminated by a return (CR) character.
  
• This is the specification of the basic Ascii protocol. When I connect to another BBS that is FBB protocol capable, I will receive the SID followed by some text and the prompt (">"). The SID must contain the F flag, I send immediately my SID and the first proposal.
  
• Proposals looks like :

FB P F6FBB FC1GHV FC1MVP 24657_F6FBB 1345

F> 

FB : Identifies the type of the command (proposal)
P : Type of message (P = Private, B = Bulletin).
F6FBB : Sender (from field).
FC1GHV : BBS of recipient (@field).
FC1MVP : Recipient (to field).
24657_F6FBB : BID ou MID.
1345 : Size of message in bytes.
F> : End of proposal.


• ALL the fields are necessary. This kind of command must hold seven fields. If a field is missing upon receipt, an error message will be sent immediately followed by a disconnection.
  
• Messages are sent in blocks. There can be up to five FB command proposals per block. The number of command proposals are determined by the maximum size of a block of messages. In FBB software there is a parameter in INIT.SRV file which defines the maximum size of the message block. It is set by default to 10KB for VHF use. It can be adjusted according to the quality of the link.
  
• Example of proposal :
  

FB P F6FBB FC1GHV.FFPC.FRA.EU FC1MVP 24657_F6FBB 1345

FB P FC1CDC F6ABJ F6AXV 24643_F6FBB 5346

FB B F6FBB FRA FBB 22_456_F6FBB 8548

F>

• This proposal is limited to three FB lines, as the total size of the messages overran the 10KB limit defined for this link.
  

• When receiving the proposal, the other BBS will reject, accept or defer each message. This done with an FS line :

  FS -+= 

• This means :
  
• I don't want the first message (-). I need the second message (+). Defer the third message, as I'm already receiving it (=).
  
• You would defer a message if you are already receiving it on a other channel, or if you think that the message is too big, or for some other reason. The message should be proposed again at the next connection.
  
• FS line MUST have as many +,-,= signs as lines in the proposal.
  
• After receiving the FS lines, the block of messages will be sent. Each message is has :
  
• the title on the first line,
• the text,
• the Ctrl Z in the last line.
• Then the next message
  
• the title on the first line,
• the text,
• the Ctrl Z in the last line.
• And so on until the number of messages in the block has been sent.
  
• When the other BBS has received all the messages in a block, it implicitly acknowledges by sending its proposal for messages that it wants to send back to you, and thus the direction of transfer is reversed.
  
• If there are no message to send, it only sends a line :

FF 

This line must not to be followed by a F>.
If the other side has no message (after receiving an FF), it sends a line :

FQ 

and disconnects.

Connects xxxxx
Connected to xxxxx

[FBB-5.11-FHM$]

Welcome, Jean-Paul. 

> 

[FBB-5.11-FHM$] (F6FBB has the F flag in the SID) 

FB P F6FBB FC1GHV.FFPC.FRA.EU FC1MVP 24657_F6FBB 1345 

FB P FC1CDC F6ABJ F6AXV 24643_F6FBB 5346 

FB B F6FBB FRA FBB 22_456_F6FBB 8548 

F> 

FS +-+ (accept the 1st and the 3rd)

Title 1st message

Text 1st message ...... 

^Z 

Title 3rd message 

Text 3rd message ...... 

^Z 

FB P FC1GHV F6FBB F6FBB 2734_FC1GHV 234 

FB B FC1GHV F6FBB FC1CDC 2745_FC1GHV 3524 

F> 

FS -- (Don't need them, and I send immediately the proposal)

FB P FC1CDC F6ABJ F6AXV 24754_F6FBB 345 

F> 

FS + (Accepts the message)

Title message 

Text message ...... 

^Z 

FF (no more message)

FB B F6FBB TEST FRA 24654_F6FBB 145 

F> 

FS + (Accepts the message) 

Title message 

Text message ...... 

^Z 

FF (still no message) 

FQ (No more message)

Disconnection
Disconnection of the link.

 

• In this example, FBB protocol is used as the two BBSs had the F flag in their SIDs. If F6FBB had sent the SID [FBB-5.10-MH$] when answering FC1GHV, the protocol would have been standard MBL/RLI.

Binary Compressed Forward Version 0

• The compressed version of the protocol is an extension to the basic Ascii protocol. Compressed forward is indicated a letter B in the SID [FBB-5.15-BFHM$]. As it is an extension of the basic protocol, the SID must also have a letter F. A SID with just a letter B (and no F) will be treated as having neither letter.
  
• In the message proposal section there are now two possible commands: FA means that the transfer will be an ascii compressed message and FB means that the message will be a binary compressed file (this last possibility is not yet implemented).
  
• The submission of an ascii message will be in the form :
  

FA P FC1CDC F6ABJ F6AXV 24754_F6FBB 345

• The submission of a binary file will be in the form :
  

FB P FC1CDC F6ABJ F6AXV 24754_F6FBB 345 

• The actual message content is transfered in a different format from the Ascii protocol. The transfer is done in binary mode. 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 protocol. Unlike YAPP transfers, there is no individual packet acknowledgement during the transmission of messages, the protocol is thus simpler and more efficient.
  

• Format of header for an ascii compressed message (type FA) :

<SOH> 1 byte = 01 hex

Length of the header 1 byte = Length of the title and offset, including the two separating <NUL> characters

Title of the message 1 to 80 ascii bytes 

<NUL> 1 byte = 00 hex 

Offset 1 to 6 ascii bytes 

<NUL> 1 byte = 00 hex

Format of header for a binary compressed file (type FB) :

<SOH> 1 byte = 01 hex 

Length of the header 1 byte = Length of the filename and offset, including the two <NUL> characters. 

Name of the file 1 to 80 ascii bytes 

<NUL> 1 byte = 00 hex 

Offset 1 to 6 ascii bytes 

<NUL> 1 byte = 00 hex 

• French regulations require that the title of the message or the file name are transmitted in readable ascii and are not compressed.

  The offset is also transmitted in ascii and specifies the offset at which the data should be inserted in the file (in case of a fragmented file). In the version 5.12, this parameter is not utilized and is always equal to zero.

  A data block contains from one to 256 bytes. It begins by two bytes which specify the format.
  

• Data block format :
  

  • <STX> 1 byte = 02 hex 
    
    Size of data 1 byte = 00 to ff hex. if length is 256 bytes, the value is 00. 
    
    Data bytes 1 to 256 bytes 
    
    The last data block is followed by the end of file specifier and the checksum. 
    
    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 file, 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 
    
    

  • Ascii values of the characters (1 byte) used in the protocol : 

    <NUL> = 00 hex 
    
    <SOH> = 01 hex 
    
    <STX> = 02 hex 
    
    <EOT> = 04 hex 
    
    

• Most of ideas for this binary transmission comes from YAPP protocol. Thanks to WA7MBL.

Binary Compressed Forward Version 1

• This protocol, used for the transfer of compressed ascii messages or binary files, is an extension to the existing version 0 protocol. This version is indicated by the presence of the letters B1 in the SID :

[FBB-5.15-B1FHLM$].

• As in version 0, there must also be a letter F in the SID for this version to be used.

  The differences with regard to the version 0 are:

  • A variable number of extra fields in each submit line including at least the seven fields of the previous version.
  • A new set of answers in an FS line :
    
  • + or Y : Yes, message accepted
  • - or N : No, message already received
  • = or L : Later, already receiving this message
  • H : Message is accepted but will be held
  • R : Message is rejected
  • E : There is an error in the line
  • !offset or Aoffset : Yes, message accepted from (Offset)
  • Most of these answer do not need explanation or were already used in previous version. + and Y, - and N, = and L, ! and A are equivalent but are still available for compatibility.
  • Aoffset asks the remote BBS to start transfer from Offset.

  For instance, YLA3350RH (or +L!3350RH) means that :

  • 1st message is accepted
  • 2nd message is delayed
  • 3rd message will be sent from offset 3350 (in compressed file)
  • 4th message is refused
  • 5th message is accepted but will be held
    

  The submission of an ascii message will be in the form :

FA P FC1CDC F6ABJ F6AXV 24754_F6FBB 345

The submission of a binary file will be in the form :

FB P FC1CDC F6ABJ F6AXV 24754_F6FBB 345

• The actual message content is transfered in a different format from the Ascii protocol. The transfer is done in binary mode. 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 protocol. Unlike YAPP transfers, there is no individual packet acknowledgement during the transmission of messages, the protocol is thus simpler and more efficient.
  
  • Format of header for an ascii compressed message (type FA) :
    

<SOH> 1 byte = 01 hex 

Length of the header 1 byte = Length of the title and offset, including the two separating <NUL> characters

Title of the message 1 to 80 ascii bytes 

<NUL> 1 byte = 00 hex 

Offset 1 to 6 ascii bytes 

<NUL> 1 byte = 00 hex

Format of header for a binary compressed file (type FB) :

<SOH> 1 byte = 01 hex 

Length of the header 1 byte = Length of the filename and offset, including the two <NUL> characters. 

Name of the file 1 to 80 ascii bytes 

<NUL> 1 byte = 00 hex 

Offset 1 to 6 ascii bytes 

<NUL> 1 byte = 00 hex 

French regulations require that the title of the message or the file name are transmitted in readable ascii and are not compressed.

The offset is also transmitted in ascii and specifies the offset at which the data should be inserted in the file (in case of a fragmented file). In the version 5.12, this parameter is not utilized and is always equal to zero.

A data block contains from one to 256 bytes. It begins by two bytes which specify the format.

Data block format :

<STX> 1 byte = 02 hex 

Size of data 1 byte = 00 to ff hex. if length is 256 bytes, the value is 00.

Data bytes 1 to 256 bytes

• 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 "e1", generates a binary compressed file in the following format : CRC16 : 2bytes Length: 4 bytes Data : rest of the file
  
• 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 

• Comments will be welcome.