github.com/la5nta/wl2k-go@v0.11.8/docs/F6FBB-B2F/protocole.html (about) 1 <html> 2 3 <head> 4 <title>F6FBB Pages : FBB</title> 5 <link title="fbbmain" rel="stylesheet" href="fbbmain.css" type="text/css"> 6 </head> 7 8 <body text="#000000" bgcolor="#C0C0C0" link="#0000EE" vlink="#551A8B" alink="#FF0000" background="back_fbb.jpg"> 9 10 <h1 align="center">FBB forwarding protocol</h1> 11 12 <p>Fbb forwarding protocols can operate either in ASCII or binary compressed modes.</p> 13 14 <p>This page describes the three versions of this protocol. Each version is backwards 15 compatible with the previous one. These versions are : 16 17 <ul> 18 <li><img src="blue.gif" hspace="8" WIDTH="14" HEIGHT="14"><a href="protocole.html#Basic">Ascii basic protocol</a></li> 19 <li><img src="blue.gif" hspace="8" WIDTH="14" HEIGHT="14"><a href="protocole.html#version0">Binary compressed 20 protocol version 0</a></li> 21 <li><img src="blue.gif" hspace="8" WIDTH="14" HEIGHT="14"><a href="protocole.html#version1">Binary compressed 22 protocol version 1</a></li> 23 </ul> 24 25 <p>Source code is available. Click <a href="ftp://ftp.f6fbb.org/pub/f6fbb/utils/lzhuf_1.zip">here</a>.</p> 26 27 <hr width="100%"> 28 29 <p><a name="Basic"></a></p> 30 31 <h3><img src="blue.gif" border="0" align="absmiddle" hspace="5" WIDTH="14" HEIGHT="14">Ascii Basic Protocol </h3> 32 33 <ul class="txt"> 34 <li>The Ascii protocol in FBB software implements two forward protocols. The first one is 35 the standard MBL/RLI protocol. The second one was developed for greater efficiency, 36 particularly on long links where the command propagation delays occupy a significant 37 portion of time. The exchange of commands and data is reduced to a minimum by sending 38 several requests at a time. In normal VHF use up to five requests or messages are sent in 39 one block. The data transfer direction is reversed after every block of data, This 40 minimises the delaying effect of long links through Nodes and digipeaters, and also saves 41 some time over short links (eg HF...). <br> 42 </li> 43 <li>FBB protocol is very simple in operation. It is based on MID/BID message identification. 44 The protocol availability is indicated by the F letter in the SID (system type identifier 45 contained in square brackets). All protocol command lines start in first column with the 46 'F' character. All protocol command lines are terminated by a return (CR) character. <br> 47 </li> 48 <li>This is the specification of the basic Ascii protocol. When I connect to another BBS 49 that is FBB protocol capable, I will receive the SID followed by some text and the prompt 50 (">"). The SID must contain the F flag, I send immediately my SID and the 51 first proposal. <br clear="both"> 52 </li> 53 <li>Proposals looks like : </li> 54 </ul> 55 56 <ul class="txt"> 57 <dl> 58 <dd><pre>FB P F6FBB FC1GHV FC1MVP 24657_F6FBB 1345 59 F> </pre> 60 </dd> 61 <blockquote> 62 <blockquote> 63 <p>FB : Identifies the type of the command (proposal)<br> 64 P : Type of message (P = Private, B = Bulletin).<br> 65 F6FBB : Sender (from field).<br> 66 FC1GHV : BBS of recipient (@field).<br> 67 FC1MVP : Recipient (to field).<br> 68 24657_F6FBB : BID ou MID.<br> 69 1345 : Size of message in bytes.<br> 70 F> : End of proposal. <br clear="both"> 71 </p> 72 </blockquote> 73 </blockquote> 74 </dl> 75 <li>ALL the fields are necessary. This kind of command must hold seven fields. If a field is 76 missing upon receipt, an error message will be sent immediately followed by a 77 disconnection. <br> 78 </li> 79 <li>Messages are sent in blocks. There can be up to five FB command proposals per block. The 80 number of command proposals are determined by the maximum size of a block of messages. In 81 FBB software there is a parameter in INIT.SRV file which defines the maximum size of the 82 message block. It is set by default to 10KB for VHF use. It can be adjusted according to 83 the quality of the link. <br clear="both"> 84 </li> 85 <li>Example of proposal : <br> 86 </li> 87 <dl class="txt"> 88 <dd><pre>FB P F6FBB FC1GHV.FFPC.FRA.EU FC1MVP 24657_F6FBB 1345 89 FB P FC1CDC F6ABJ F6AXV 24643_F6FBB 5346 90 FB B F6FBB FRA FBB 22_456_F6FBB 8548 91 F></pre> 92 </dd> 93 </dl> 94 <li>This proposal is limited to three FB lines, as the total size of the messages overran 95 the 10KB limit defined for this link. <br> 96 </li> 97 <li><pre>When receiving the proposal, the other BBS will reject, accept or defer each message. This done with an FS line :</pre> 98 <blockquote> 99 <pre>FS -+= </pre> 100 </blockquote> 101 </li> 102 </ul> 103 104 <ul class="txt"> 105 <li>This means : <br> 106 </li> 107 <ul> 108 <li>I don't want the first message (-). I need the second message (+). Defer the third 109 message, as I'm already receiving it (=). <br> 110 </li> 111 <li>You would defer a message if you are already receiving it on a other channel, or if you 112 think that the message is too big, or for some other reason. The message should be 113 proposed again at the next connection. <br clear="both"> 114 </li> 115 </ul> 116 <li>FS line MUST have as many +,-,= signs as lines in the proposal. <br> 117 </li> 118 <li>After receiving the FS lines, the block of messages will be sent. Each message is has :<br> 119 </li> 120 <ul> 121 <li>the title on the first line, </li> 122 <li>the text, </li> 123 <li>the Ctrl Z in the last line. </li> 124 </ul> 125 <li>Then the next message<br> 126 </li> 127 <ul> 128 <li>the title on the first line, </li> 129 <li>the text, </li> 130 <li>the Ctrl Z in the last line. </li> 131 </ul> 132 <li>And so on until the number of messages in the block has been sent. <br clear="both"> 133 </li> 134 <li>When the other BBS has received all the messages in a block, it implicitly acknowledges 135 by sending its proposal for messages that it wants to send back to you, and thus the 136 direction of transfer is reversed. <br> 137 </li> 138 <li>If there are no message to send, it only sends a line : </li> 139 </ul> 140 141 <ul class="txt"> 142 <blockquote> 143 <pre>FF </pre> 144 </blockquote> 145 </ul> 146 147 <blockquote> 148 <p>This line must not to be followed by a F>. <br> 149 If the other side has no message (after receiving an FF), it sends a line :<ul class="txt"> 150 <pre>FQ </pre> 151 </ul> 152 </blockquote> 153 154 <blockquote> 155 <p class="txt">and disconnects. </p> 156 </blockquote> 157 158 <ul> 159 <li><hr width="98%" size="3"> 160 </li> 161 <li><blockquote> 162 </blockquote> 163 </li> 164 </ul> 165 166 <blockquote> 167 <blockquote> 168 <p><font color="#00FFFF">Connects xxxxx<br> 169 Connected to xxxxx</font><ul> 170 <ul> 171 </ul> 172 </ul> 173 <pre><font color="#00FF00"><i>[FBB-5.11-FHM$] 174 Welcome, Jean-Paul. 175 > </i></font></pre> 176 <pre><font color="#FF0000">[FBB-5.11-FHM$] <b>(F6FBB has the F flag in the SID)</b> 177 FB P F6FBB FC1GHV.FFPC.FRA.EU FC1MVP 24657_F6FBB 1345 178 FB P FC1CDC F6ABJ F6AXV 24643_F6FBB 5346 179 FB B F6FBB FRA FBB 22_456_F6FBB 8548 180 F> </font></pre> 181 <pre><font color="#00FF00"><i>FS +-+ <b>(accept the 1st and the 3rd)</b></i></font> 182 <font color="#FF0000">Title 1st message 183 Text 1st message ...... 184 ^Z 185 Title 3rd message 186 Text 3rd message ...... 187 ^Z </font></pre> 188 <pre><font color="#00FF00"><i>FB P FC1GHV F6FBB F6FBB 2734_FC1GHV 234 189 FB B FC1GHV F6FBB FC1CDC 2745_FC1GHV 3524 190 F> </i></font></pre> 191 <pre><font color="#FF0000">FS -- <b>(Don't need them, and I send immediately the proposal)</b> 192 FB P FC1CDC F6ABJ F6AXV 24754_F6FBB 345 193 F> </font></pre> 194 <pre><font color="#00FF00"><i>FS + <b>(Accepts the message)</b></i></font> 195 <font color="#FF0000">Title message 196 Text message ...... 197 ^Z </font></pre> 198 <pre><font color="#00FF00"><i>FF <b>(no more message)</b></i> 199 FB B F6FBB TEST FRA 24654_F6FBB 145 200 F></font> </pre> 201 <pre><font color="#FF0000"><i>FS + <b>(Accepts the message)</b> </i></font> 202 <font color="#00FF00">Title message 203 Text message ...... 204 ^Z </font></pre> 205 <pre><font color="#FF0000"><i>FF <b>(still no message)</b> </i></font></pre> 206 <pre><font color="#00FF00">FQ <b>(No more message)</b></font></pre> 207 <p><font color="#00FFFF">Disconnection<br> 208 Disconnection of the link.</font></p> 209 <p> </p> 210 </blockquote> 211 </blockquote> 212 213 <ul class="txt"> 214 <li>In this example, FBB protocol is used as the two BBSs had the F flag in their SIDs. If 215 F6FBB had sent the SID [FBB-5.10-MH$] when answering FC1GHV, the protocol would have been 216 standard MBL/RLI. </li> 217 </ul> 218 219 <ul class="txt"> 220 <li><hr width="98%" size="4"> 221 </li> 222 </ul> 223 224 <h3><a name="version0"></a><img src="blue.gif" border="0" align="absmiddle" hspace="5" WIDTH="14" HEIGHT="14">Binary 225 Compressed Forward Version 0 </h3> 226 227 <ul class="txt"> 228 <li>The compressed version of the protocol is an extension to the basic Ascii protocol. 229 Compressed forward is indicated a letter B in the SID [FBB-5.15-BFHM$]. As it is an 230 extension of the basic protocol, the SID must also have a letter F. A SID with just a 231 letter B (and no F) will be treated as having neither letter. <br> 232 </li> 233 <li>In the message proposal section there are now two possible commands: FA means that the 234 transfer will be an ascii compressed message and FB means that the message will be a 235 binary compressed file (this last possibility is not yet implemented). <br clear="both"> 236 </li> 237 <li>The submission of an ascii message will be in the form : <br> 238 </li> 239 <blockquote> 240 <pre>FA P FC1CDC F6ABJ F6AXV 24754_F6FBB 345</pre> 241 </blockquote> 242 </ul> 243 244 <ul class="txt"> 245 <li>The submission of a binary file will be in the form :<br> 246 </li> 247 <blockquote> 248 <pre>FB P FC1CDC F6ABJ F6AXV 24754_F6FBB 345 </pre> 249 </blockquote> 250 </ul> 251 252 <ul class="txt"> 253 <li>The actual message content is transfered in a different format from the Ascii protocol. 254 The transfer is done in binary mode. The format used is derived from the YAPP protocol 255 which is very reliable. Each message is made up of a header, blocks of data, an end of 256 message marker and a checksum. This is directly equivalent to the transfer of one message 257 in the Ascii protocol. Unlike YAPP transfers, there is no individual packet 258 acknowledgement during the transmission of messages, the protocol is thus simpler and more 259 efficient. <br> 260 </li> 261 <li><p class="txt"><b>Format of header for an ascii compressed message (type FA) : </b></p> 262 </li> 263 <blockquote> 264 <pre><SOH> 1 byte = 01 hex 265 Length of the header 1 byte = Length of the title and offset, including the two separating <NUL> characters 266 Title of the message 1 to 80 ascii bytes 267 <NUL> 1 byte = 00 hex 268 Offset 1 to 6 ascii bytes 269 <NUL> 1 byte = 00 hex</pre> 270 </blockquote> 271 </ul> 272 273 <blockquote> 274 <p><b>Format of header for a binary compressed file (type FB) : </b></p> 275 </blockquote> 276 277 <ul class="txt"> 278 <blockquote> 279 <pre><SOH> 1 byte = 01 hex 280 Length of the header 1 byte = Length of the filename and offset, including the two <NUL> characters. 281 Name of the file 1 to 80 ascii bytes 282 <NUL> 1 byte = 00 hex 283 Offset 1 to 6 ascii bytes 284 <NUL> 1 byte = 00 hex </pre> 285 </blockquote> 286 </ul> 287 288 <ul class="txt"> 289 <li>French regulations require that the title of the message or the file name are 290 transmitted in readable ascii and are not compressed. <p>The offset is also transmitted in 291 ascii and specifies the offset at which the data should be inserted in the file (in case 292 of a fragmented file). In the version 5.12, this parameter is not utilized and is always 293 equal to zero. </p> 294 <p>A data block contains from one to 256 bytes. It begins by two bytes which specify the 295 format. <br> 296 </p> 297 </li> 298 <li><b>Data block format : <br> 299 </b><ul class="txt"> 300 <li><pre><STX> 1 byte = 02 hex 301 Size of data 1 byte = 00 to ff hex. if length is 256 bytes, the value is 00. 302 Data bytes 1 to 256 bytes 303 The last data block is followed by the end of file specifier and the checksum. 304 End of file specifier format : 305 <EOT> 1 byte = 04 hex 306 Checksum 1 byte = 00 to ff hex 307 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. 308 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. 309 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 : </pre> 310 </li> 311 <li><pre>*** Erreur checksum 312 </pre> 313 </li> 314 <li><pre>Ascii values of the characters (1 byte) used in the protocol : </pre> 315 <pre><NUL> = 00 hex 316 <SOH> = 01 hex 317 <STX> = 02 hex 318 <EOT> = 04 hex 319 </pre> 320 </li> 321 </ul> 322 </li> 323 <li>Most of ideas for this binary transmission comes from YAPP protocol. Thanks to WA7MBL. </li> 324 </ul> 325 326 <ul> 327 <li><hr width="100%"> 328 </li> 329 </ul> 330 331 <h3><a name="version1"></a><img src="blue.gif" border="0" align="absmiddle" hspace="5" WIDTH="14" HEIGHT="14">Binary 332 Compressed Forward Version 1 </h3> 333 334 <p> 335 336 <ul class="txt"> 337 <li>This protocol, used for the transfer of compressed ascii messages or binary files, is an 338 extension to the existing version 0 protocol. This version is indicated by the presence of 339 the letters B1 in the SID :</li> 340 </ul> 341 342 <blockquote> 343 <blockquote> 344 <pre class="txt">[FBB-5.15-B1FHLM$]. 345 </pre> 346 </blockquote> 347 </blockquote> 348 349 <ul class="txt"> 350 <li>As in version 0, there must also be a letter F in the SID for this version to be used.<p>The 351 differences with regard to the version 0 are: <ul> 352 <ul> 353 <li>A variable number of extra fields in each submit line including at least the seven 354 fields of the previous version.</li> 355 <li>A new set of answers in an FS line :<br> 356 </li> 357 <ul> 358 <li>+ or Y : Yes, message accepted</li> 359 <li>- or N : No, message already received</li> 360 <li>= or L : Later, already receiving this message</li> 361 <li>H : Message is accepted but will be held</li> 362 <li>R : Message is rejected</li> 363 <li>E : There is an error in the line</li> 364 <li>!offset or Aoffset : Yes, message accepted from (Offset)</li> 365 </ul> 366 <li>Most of these answer do not need explanation or were already used in previous version. + 367 and Y, - and N, = and L, ! and A are equivalent but are still available for compatibility. </li> 368 <li>Aoffset asks the remote BBS to start transfer from Offset. </li> 369 </ul> 370 </ul> 371 <p>For instance, YLA3350RH (or +L!3350RH) means that : <ul> 372 <ul> 373 <li>1st message is accepted </li> 374 <li>2nd message is delayed </li> 375 <li>3rd message will be sent from offset 3350 (in compressed file) </li> 376 <li>4th message is refused </li> 377 <li>5th message is accepted but will be held <br> 378 </li> 379 </ul> 380 </ul> 381 <p>The submission of an ascii message will be in the form : </p> 382 </li> 383 <blockquote> 384 <pre>FA P FC1CDC F6ABJ F6AXV 24754_F6FBB 345</pre> 385 </blockquote> 386 </ul> 387 388 <blockquote> 389 <p>The submission of a binary file will be in the form : </p> 390 <blockquote> 391 <p>FB P FC1CDC F6ABJ F6AXV 24754_F6FBB 345</p> 392 </blockquote> 393 </blockquote> 394 395 <ul class="txt"> 396 <li>The actual message content is transfered in a different format from the Ascii protocol. 397 The transfer is done in binary mode. The format used is derived from the YAPP protocol 398 which is very reliable. Each message is made up of a header, blocks of data, an end of 399 message marker and a checksum. This is directly equivalent to the transfer of one message 400 in the Ascii protocol. Unlike YAPP transfers, there is no individual packet 401 acknowledgement during the transmission of messages, the protocol is thus simpler and more 402 efficient. <br> 403 <ul> 404 <li><b>Format of header for an ascii compressed message (type FA) : <br> 405 </b></li> 406 </ul> 407 </li> 408 <blockquote> 409 <pre><SOH> 1 byte = 01 hex 410 Length of the header 1 byte = Length of the title and offset, including the two separating <NUL> characters 411 Title of the message 1 to 80 ascii bytes 412 <NUL> 1 byte = 00 hex 413 Offset 1 to 6 ascii bytes 414 <NUL> 1 byte = 00 hex</pre> 415 </blockquote> 416 </ul> 417 418 <blockquote> 419 <blockquote> 420 <p><b>Format of header for a binary compressed file (type FB) : </b></p> 421 </blockquote> 422 </blockquote> 423 424 <blockquote> 425 <blockquote> 426 <pre><font color="#FFFFFF"><SOH> 1 byte = 01 hex 427 Length of the header 1 byte = Length of the filename and offset, including the two <NUL> characters. 428 Name of the file 1 to 80 ascii bytes 429 <NUL> 1 byte = 00 hex 430 Offset 1 to 6 ascii bytes 431 <NUL> 1 byte = 00 hex </font></pre> 432 </blockquote> 433 </blockquote> 434 435 <blockquote> 436 <p>French regulations require that the title of the message or the file name are 437 transmitted in readable ascii and are not compressed. </p> 438 </blockquote> 439 440 <blockquote> 441 <p>The offset is also transmitted in ascii and specifies the offset at which the data 442 should be inserted in the file (in case of a fragmented file). In the version 5.12, this 443 parameter is not utilized and is always equal to zero. </p> 444 </blockquote> 445 446 <blockquote> 447 <p>A data block contains from one to 256 bytes. It begins by two bytes which specify the 448 format. <br> 449 </p> 450 </blockquote> 451 452 <blockquote> 453 <blockquote> 454 <p><b>Data block format : </b></p> 455 </blockquote> 456 </blockquote> 457 458 <blockquote> 459 <blockquote> 460 <blockquote> 461 <pre><font color="#FFFFFF"><STX> 1 byte = 02 hex </font></pre> 462 </blockquote> 463 </blockquote> 464 </blockquote> 465 466 <blockquote> 467 <p>Size of data 1 byte = 00 to ff hex. if length is 256 bytes, the value is 00. </p> 468 </blockquote> 469 470 <blockquote> 471 <p>Data bytes 1 to 256 bytes </p> 472 </blockquote> 473 474 <blockquote> 475 <ul class="txt"> 476 <li>The first transmitted block of data must contain a header containing :<br> 477 </li> 478 <ul> 479 <li>the CRC16 of the full binary file (2 bytes)</li> 480 <li>the size of the full uncompressed file (4 bytes)</li> 481 </ul> 482 <li>This data is in little-endian Intel format (less significant first). <br> 483 </li> 484 <li>The last data block is followed by the end of file specifier and the checksum of the 485 data sent. <br> 486 </li> 487 <li>End of file specifier format : </li> 488 </ul> 489 <blockquote> 490 <blockquote> 491 <pre><font color="#FFFFFF"><EOT> 1 byte = 04 hex Checksum 1 byte = 00 to ff hex </font></pre> 492 </blockquote> 493 </blockquote> 494 <ul class="txt"> 495 <li>The checksum is equal to the sum of all the data bytes of the transmitted data, modulo 496 256 (8 bits) and then two's complemented. <br> 497 </li> 498 <li>The checking of the checksum is very simple : <br> 499 </li> 500 <li>The sum of the data bytes from the file and the checksum received modulo 256 shall be 501 equal to zero. <br> 502 </li> 503 <li><pre class="txt">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 : 504 505 *** Erreur checksum </pre> 506 </li> 507 <li>A CRC16 is computed for the full binary file including the length of the uncompressed 508 file (4 bytes in top of file). In the case of a resume, it will be the only means 509 available to ensure that all the parts of the message or file has been received correctly. 510 <br> 511 </li> 512 <li>The LZHUF_1 program, when used with option "e1", generates a binary compressed 513 file in the following format : CRC16 : 2bytes Length: 4 bytes Data : rest of the file <br> 514 </li> 515 <li>In case of forwarding with a BBS using version 0, only the part from offset 2 will be 516 sent <br> 517 </li> 518 <li>In case of forwarding with a BBS using version 1, the 6 top bytes will be always sent, 519 then if resume seek to asked offset, then send data. <br> 520 </li> 521 <li>Ascii values of the characters (1 byte) used in the protocol : <br> 522 </li> 523 <blockquote> 524 <pre><NUL> = 00 hex 525 <SOH> = 01 hex 526 <STX> = 02 hex 527 <EOT> = 04 hex </pre> 528 </blockquote> 529 <li>Comments will be welcome. </li> 530 </ul> 531 </blockquote> 532 </body> 533 </html>