From comp.mail.uucp Tue Nov 12 12:45:20 1991
Path: psgrain!uunet!airs!ian
From: ian@airs.com (Ian Lance Taylor)
Newsgroups: comp.mail.uucp
Subject: The 't' protocol
Message-ID: <2887@airs.com>
Date: 12 Nov 91 18:50:09 GMT
Sender: news@airs.com
Lines: 34

I got rapid answers to my questions about the UUCP 't' protocol from
Lyndon Nereberg and Earle Ake, for which I thank them.  To help people
who may be in my situation in the future, I will describe my
understanding of how the protocol works (it's very simple).

Commands (e.g. "S file file user -options temp mode") are always sent
in blocks of 512 bytes.  They are terminated by a null byte, but not a
newline.  The final byte of the final block of a command must also be
a null byte.  Of course, most commands will fit in a single 512 byte
block.

File data is sent in blocks.  Each block is preceded by a four byte
length in network byte order (this is most significant byte first).
When the file is finished a zero length block is sent.  For example, a
ten byte file containing "abcdefghij" would be sent as:

        0 0 0 10 a b c d e f g h i j 0 0 0 0

That is, a length of ten, followed by ten bytes, followed by a length
of zero (and conceptually by the zero bytes in the final block).

The BSD implementation can handle a block of at most 1024 bytes, not
counting the length.  Therefore, although the protocol could in
principle send almost any file in a single large block, it would be
wise to avoid sending more than 1024 bytes at a time.

As you can see, the 't' protocol does no data checking whatsoever.  It
can only be safely used on a communication path that provides full end
to end reliability, such as TCP.
-- 
Ian Taylor                  ian@airs.com                  uunet!airs!ian
First person to identify this quote wins a free e-mail message:
``It doesn't matter how obvious the truth is if the truth is that you'll
  never escape.''

.