Path: utzoo!attcan!uunet!lll-winken!ubvax!vsi1!daver!
From: daver@daver.UUCP (Dave Rand)
Newsgroups: comp.protocols.misc
Subject: Re: About Protocols for File Transfer
Message-ID: <454@daver.UUCP>
Date: 27 May 88 23:06:57 GMT
References: <692@ncrcce.StPaul.NCR.COM> <8WbMLYy00Vs8EzltB4@andrew.cmu.edu>
Reply-To: daver@daver.UUCP (Dave Rand)
Organization: Assn. for the prevention of Polar Bears and Kangaroos
Lines: 51

In article <8WbMLYy00Vs8EzltB4@andrew.cmu.edu> jk3k+@ANDREW.CMU.EDU (Joe Keane) writes:
>In article <303@cfcl.UUCP> dwh@cfcl.UUCP (Dave Hamaker) writes:
>>Using ordinary asynchronous RS-232 full-duplex serial communications, is an
>>error-detecting/correcting file-transfer protocol possible which is as fast
>>as or faster than non-protocol transfer?  If not, why not?  If so, how?
>
>Sure, why not?  Assuming no errors (otherwise the question is really
>stupid), the only overhead is acks from the receiver (`block 0 OK',
>`block 1 OK', ...)  Assuming the protocol has a reasonable window and
>the acks are smaller than the data, this doesn't slow anything down.
>Of course most protocols delimit the blocks.


Incorrect. In order for a windowed protocol to work, a CRC/checksum and
packet number must be attached to the data. For example, in the uucico
g protocol (the "standard"), the format is 6 bytes of header, and 58 bytes
of data per packet. There is normally up to three windows outstanding,
and you are correct in assuming that if the ACKS take less time to
transmit than the data outstanding, you will achieve maximum transmission
rate. However, as may be obvious, if you cannot use every byte of
transmitted data for the file, then you are not using 100 % of the
channel capacity.

In the g protocol, each packet is 64 bytes.  The ACTUAL file occupies 58
of these bytes, thus the maximum throughput of a standard uucp
connection is 58/64, or 90.625% of channel capacity. The following table
summarizes this:

	bps rate	throughput with g protocol
	300		27 cps (characters per second)
	1200		109 cps
	2400		218 cps
	9600		870 cps
	19200		1740 cps

Even if you limit the "error checking" information to a few bytes at the
end of the file, the full channel capacity cannot be used. If you
compress the data, or otherwise alter it during transmission, you
can, of course, increase the transfer rate. But with any error
checking protocol, you must ADD information to the file, to ensure
that it was received correctly. When you add information, it takes
longer to transmit, and thus cannot achieve full utilization of
a channel.

Summary: It is not possible to implement an error-detecting/correcting
file transfer protocol which is as fast as a non-protocol transfer, due
to the fact that additional information must be added to the file to ensure
that the received data is correct. If the data is compressed or altered
as part of the protocol, it is possible, but this was specifically ruled
out in the original posting.

Dave Rand