Greg Hudson wrote:
> Say I have four files I want to get from computer A to computer B.
>
> Plan #1: Open four TCP connections in parallel, send the four files.
>
> Plan #2: Concatenate the four files together (with some kind of
> separator), open one TCP connection, and send the concatenation.
>
> If plan #1 is ever faster than plan #2, I strongly suspect it's only
> because it's grabbing a larger share of a congested pipe. I don't know
> why anyone would think four TCP connections between the same two
> endpoints would intrinsically have more bandwidth than a single
> connection.
>
Not necessarily disagreeing - but another example I thought of:
TCP/IP is stream-based, presented a serial stream of characters. In the
case of an unreliable link, if a set of 64 Kbytes of packets are
received, but the first 1K is corrupt or lost, we might have to wait for
TCP/IP to signal a retry and wait for the missing 1K before the whole 64
Kbyte can be read by the server. This "wait" time will take the form of
the pipe being idle at one or both sides for a measurable period of time
(something a bit more than the round-trip latency of the connection). If
two streams are running in parallel, the chance of both streams being
interrupted at the same instant are lower.
This is one of the main reasons why SCTP was introduced. The TCP
emphasis on a reliable stream of data has certain limitations that
cannot be overcome.
Cheers,
mark
--
Mark Mielke <mark_at_mielke.cc>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-11-06 18:47:57 CET