Hello Guest

Author Topic: FBB Forwarding Protocol  (Read 326 times)


  • Administrator
  • Member
  • *****
  • Posts: 11
FBB Forwarding Protocol
« on: July 14, 2013, 07:27:47 PM »
     FBB Forward Protocole.

            FBB software includes  two forward protocoles.  The first one
       is standard with MBL/RLI protocole.  The second one was developped
       to allow  a better  efficiency, particularly  on long  links where
       propagation time  of data  are long.  The exchange  of commands is
       reduced to a  minimum, and not  acknoledged to get  time. The data
       transfer direction is changed every block of data, a block of data
       holding up to  five messages.  This uses the  "pipeline" effect of
       long links (Nodes and digipeaters),  and gain some time over short
       links (HF...).

            FBB protocole is very simple in its principle. It is based on
       MID/BID usage. The identification  is made by the  F letter in the
       SID (system  type identifier  contained  in square  brackets). All
       command lines must start in  first collumn with the 'F' character.
       All command lines are ended by a return (CR) character.

            Suppose I  call  another BBS  to  forward some  mail.  When I
       connect another BBS  using FBB  protocole, I will  receive the SID
       followed by a text and the prompt (">"). If the SID contains the F
       flag, I will send immediately my SID and the first proposal.

            Proposals looks like :

       FB P F6FBB FC1GHV FC1MVP 24657_F6FBB 1345

       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  receiving,  an error
       message will be send immediately followed by a disconnection.

            A proposal can  handle up  to five  FB command  lines. If the
       total size of messages seems to be too important, the proposal can
       handle less  lines. In  FBB  software, a  parameter is  defined in
       INIT.SRV file to tell 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.

       Exemple 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

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

            When receiving  the  proposal,  the  other  BBS  will reject,
       accept or defer the message. This command is made by a FS line :

       FS -+=

            This means :

            - I don't want the first message (-).
            - I need the second message (+).
            - I defer the third message, as I'm still receiving it.

            It should  interesting to  defer a  message if  you are still
       receiving it on a other channel, or  if you think that the size is
       to big,  or for  another  reason. The  message should  be proposed
       again at the next connection.

            FS line  MUST  have  as  many +,-,=  signs  as  lines  in the

            When  receiving  the  FS  lines,  I  can  send  the block  of
       messages. Each message is  made with the title  on the first line,
       the text, and  a Ctrl  Z in  the last line.  The is  no blank line
       between the messages.

       Title of 2nd message
       Text of 2nd message

            When the other  BBS has  received all the  asked messages, it
       acknoledges by sending its proposal, and the system is reversed.

            If it has no message to send, it only sends a line :   


            This line must not to be followed by a F>.

            If the other hand has no message, it sends a line :


            and asks for the disconnection.

       Example :

       F6FBB                    FC1GHV

       Connects FC1GHV


                                Bienvenue a Poitiers, 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

                                FS +-+  (accepts le 1st et le 3rd).

       Title 1st message
       Text 1st message
       Title 3rd message
       Text 3rd message

                                FB P FC1GHV F6FBB F6FBB 2734_FC1GHV 234
                                FB B FC1GHV F6FBB FC1CDC 2745_FC1GHV 3524

       FS --  (Don't need them, and send immediately the proposal).
       FB P FC1CDC F6ABJ F6AXV 24754_F6FBB 345

                                FS +  (Accepts the message)

       Title message
       Text message

                                FF  (no more message)

       FB B F6FBB TEST FRA 24654_F6FBB 145

                                FS +  (Accepts the message)

       Title message
       Text message

                                FF  (still no message)

       FQ  (No more message)

       Disconnection of the link.

            In this example,  FBB protocole is  used as the  two BBS were
       identified by the  F flag in  the SID.  If F6FBB had  sent the SID
       [FBB-5.10-MH$] when answering FC1GHV,  the protocole should be the
       standard MBL/RLI.

            All callsigns are only examples !

       Extension to the protocole. Compressed forward FBB.

       The protocole utilized for the  transfer of ascii files compressed
       is an extension to the  existing protocole. The compressed forward
       is  validated  by  the  presence  of  the  letter  B  in  the  SID
       [FBB-5.12-BFHM$]. The transfer  of compressed files  can only take
       place under FBB protocole. The presence of the letter B in the SID
       without the F letter will remain without effect.

            The only difference as regard to the standard protocol is the
       submit line.  It can  specify the  type of  data contained  in the
       compressed message. FA  means that  the transfer will  be an ascii
       compressed message.  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 transfered data are of a specific format. The transfer will be
       done in binary mode. This last one is derived of the YAPP protocol
       which is very reliable. All transfer  is made of a header, a block
       of data,  an  end of  message  and  a checksum.  Each  transfer is
       equivalent to the transfer of one message of the standard protocol
       and shall  not  be  followed  by  a control  Z,  the  end  of file
       specifier is defined in another way.  Unlike YAPP transfers, there
       is  no acknowledgement  during the  transmission of  messages, the
       protocole is then more simple and efficient.

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

       <SOH>                    1 byte = 01 hex
       Length of the header     1 byte = Length from the title,         
                                     including the two <NUL> characters.
       Title of the message     1 to 80 bytes
       <NUL>                    1 byte = 00 hex
       Offset                   1 to 6 bytes
       <NUL>                    1 byte = 00 hex

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

       <SOH>                    1 byte = 01 hex
       Length of the header     1 byte = Length from the filename,
                                     including the two <NUL> characters.
       Name of the file         1 to 80 bytes
       <NUL>                    1 byte = 00 hex
       Offset                   1 to 6 bytes
       <NUL>                    1 byte = 00 hex

       As to follow  the french regulation,  the title of  the message or
       the file name are transmitted in readable ascii, 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
       Number 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  datas  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 not taken
       to account and the system issues a disconnect request after having
       sent the comment :

       *** Erreur checksum

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

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

       Most of  ideas for this  binary transmission  are issued from YAPP
       protocole. Thanks to WA7MBL.