Re: paket size TCP

From: David Schwartz (davids_at_webmaster.com)
Date: 01/24/04 

Date: Sat, 24 Jan 2004 09:08:32 -0800

"Kasper Dupont" <kasperd@daimi.au.dk> wrote in message
news:4012359B.16F7AA50@daimi.au.dk...

> David Schwartz wrote:

>> I mean, for example, that you must pass as much data as possible in
>> each
>> call to 'write' or you will be likely to get small packets, low
>> throughput,
>> and high delays.

> Passing lots of data in each write call is a god
> idea because of the system call overhead.

    It's also critical in cases where round-trip-time is important because
you have lots of protocol turnarounds.

> But
> assuming you have enough CPU power to actually
> perform enough system calls per second to use
> the full bandwith it shouldn't turn out as bad
> as you describe. Eventually TCP will not be able
> to put data on the wire immediately either
> because it has send a full window or because the
> network interface is not ready to send a packet.
> In that case it should start buffering data,
> which means the program can continue producing
> more data that will eventually be send in
> larger packets.

    If your protocol has lots of turnarounds (situations where one side
can't continue sending until it gets a response from the other side), you
may never reach this 'eventually'.

    Similarly, if your protocol produces data at a slow, continuous pace,
you may also never reach this 'eventually'. This is a case that's often
forgotten!

    Consider, for example, a chat server. You care about network efficiency
because you're maintaining thousands of connections. While each one
individually is low bandwidth, it would really hurt you if every private
message (or even more than a few) was sent in two packets, one with the
command and one with the data. This is true even though there are no
turnarounds in the protocol at all.

    DS