Extension to the protocol. Compressed forward FBB.
The protocol utilized for the transfer of ascii files compressed is an
extension to the existing protocol. 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 protocol. 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 in the version 5.12).
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 transferred 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.
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 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. (00 if length = 256 bytes).
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 a 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 from the file and the checksum received modulo 256
anded with FF) 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 :
*** Checksum error
Extension to the protocol. XFWD compressed forward.
X forwarding Protocol is implemented.
XForwarding now supports re-routing and swapping.
Binary forwarding via telephone modem (FBB or XFWD)
This website uses cookies to improve your experience. We'll assume you're ok with this, but you can opt-out if you wish.AcceptRead More
Privacy & Cookies Policy
Privacy Overview
This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.