Search the FAQ Archives

3 - A - B - C - D - E - F - G - H - I - J - K - L - M
N - O - P - Q - R - S - T - U - V - W - X - Y - Z
faqs.org - Internet FAQ Archives

UUCP Internals Frequently Asked Questions
Section - UUCP `f' Protocol

( Single Page )
[ Usenet FAQs | Web FAQs | Documents | RFC Index | Airports ]


Top Document: UUCP Internals Frequently Asked Questions
Previous Document: UUCP `g' Protocol
Next Document: UUCP `t' Protocol
See reader questions & answers on this topic! - Help others by sharing your knowledge
UUCP `f' Protocol
=================

The `f' protocol is a seven bit protocol which checksums an entire file
at a time.  It only uses the characters between `\040' and `\176'
(ASCII `space' and `~') inclusive, as well as the carriage return
character.  It can be very efficient for transferring text only data,
but it is very inefficient at transferring eight bit data (such as
compressed news).  It is not flow controlled, and the checksum is
fairly insecure over large files, so using it over a serial connection
requires handshaking (XON/XOFF can be used) and error correcting
modems.  Some people think it should not be used even under those
circumstances.

I believe that the `f' protocol originated in BSD versions of UUCP.  It
was originally intended for transmission over X.25 PAD links.

The `f' protocol has no startup or finish protocol.  However, both
sides typically sleep for a couple of seconds before starting up,
because they switch the terminal into XON/XOFF mode and want to allow
the changes to settle before beginning transmission.

When a UUCP package transmits a command, it simply sends a string
terminated by a carriage return.

When a UUCP package transmits a file, each byte B of the file is
translated according to the following table:

            0 <= B <=  037: 0172, B + 0100 (0100 to 0137)
          040 <= B <= 0171:       B        ( 040 to 0171)
         0172 <= B <= 0177: 0173, B - 0100 ( 072 to  077)
         0200 <= B <= 0237: 0174, B - 0100 (0100 to 0137)
         0240 <= B <= 0371: 0175, B - 0200 ( 040 to 0171)
         0372 <= B <= 0377: 0176, B - 0300 ( 072 to  077)

That is, a byte between `\040' and `\171' inclusive is transmitted as
is, and all other bytes are prefixed and modified as shown.

When all the file data is sent, a seven byte sequence is sent: two bytes
of `\176' followed by four ASCII bytes of the checksum as printed in
base 16 followed by a carriage return.  For example, if the checksum
was 0x1234, this would be sent: `\176\1761234\r'.

The checksum is initialized to 0xffff.  For each byte that is sent it is
modified as follows (where B is the byte before it has been transformed
as described above):

           /* Rotate the checksum left.  */
           if ((ichk & 0x8000) == 0)
             ichk <<= 1;
           else
             {
               ichk <<= 1;
               ++ichk;
             }
     
           /* Add the next byte into the checksum.  */
           ichk += B;

When the receiving UUCP sees the checksum, it compares it against its
own calculated checksum and replies with a single character followed by
a carriage return.

`G'
     The file was received correctly.

`R'
     The checksum did not match, and the file should be resent from the
     beginning.

`Q'
     The checksum did not match, but too many retries have occurred and
     the communication session should be abandoned.

The sending UUCP checks the returned character and acts accordingly.

User Contributions:

Comment about this article, ask questions, or add new information about this topic:

CAPTCHA




Top Document: UUCP Internals Frequently Asked Questions
Previous Document: UUCP `g' Protocol
Next Document: UUCP `t' Protocol

Single Page

[ Usenet FAQs | Web FAQs | Documents | RFC Index ]

Send corrections/additions to the FAQ Maintainer:
ian@airs.com (Ian Lance Taylor)





Last Update March 27 2014 @ 02:12 PM