Michael O'Keefe wrote:
You don't want to use TCP for this because almost all of TCP overhead
is set up for *unreliable, shared* transport as opposed to a cable
which is *reliable, dedicated* transport.
I'm not sure about that.
TCP helps enourmously over dedicated, reliable transport becoz the app
on the other end cannot read the data as fast as it is pumped in (so the
buffers fill up), so TCP backs off transmission
With an unreliable protocol (UDP), the buffers overflow and packets get
dropped, regardless of the transport reliability
I think you are confusing some things.
The context here is not TCP vs UDP. It's TCP vs. ATA or possibly
ethernet vs. direct cable.
TCP is set up to work over an unreliable, shared resource which is
typically ethernet. Ethernet has no guaranteed endpoints, delivery
guarantees, time bounds, etc. TCP has to cope with all of that (which
it does quite well) and expends lots of overhead to do so.
ATA, on the other hand, is set up to work over a reliable, dedicated
resource which is typically a cable. This is point to point, extremely
reliable, and can prenegotiate the characteristics of the channel
(buffer size, processing time, etc.) which then typically do not change
for a long time. As such, it can use far less overhead to cope with
exceptional conditions since they occur *far* less often.
As a simple example, ATA can actually *ask* what the remote buffer size
is and get a definitive answer. This means that congestion control *is
simply not required*. TCP can never do that, it must make adjustments
based upon dynamic feedback. ATA can *assume* that large chunks of
bytes always move correctly and in order; TCP cannot.
There are many other examples.
-a
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
