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 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 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 F> 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 proposal. 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 ..... ^Z 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 : FF This line must not to be followed by a F>. If the other hand has no message, it sends a line : FQ and asks for the disconnection. Example : --------- F6FBB FC1GHV ---------------------------------------------------------------- Connects FC1GHV Connected [FBB-5.11-FHM$] 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 F> FS +-+ (accepts le 1st et le 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 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 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) : 1 byte = 01 hex Length of the header 1 byte = Length from the title, including the two characters. Title of the message 1 to 80 bytes 1 byte = 00 hex Offset 1 to 6 bytes 1 byte = 00 hex Format of header for a binary compressed file (submission FB) : 1 byte = 01 hex Length of the header 1 byte = Length from the filename, including the two characters. Name of the file 1 to 80 bytes 1 byte = 00 hex Offset 1 to 6 bytes 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 : 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 : 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 : = 00 hex = 01 hex = 02 hex = 04 hex Most of ideas for this binary transmission are issued from YAPP protocole. Thanks to WA7MBL.