Re: paket size TCP

From: Kasper Dupont (kasperd_at_daimi.au.dk)
Date: 01/25/04 

Date: Sun, 25 Jan 2004 03:42:48 +0100

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

If round-trip-time is important TCP might not be a
good choice. Sometimes UDP is a better choice.

>
> > 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'.

You are right, in that case you might never fill
the TCP window. If you have enough CPU power you
might be able to send data from user program to TCP
implementation faster than it can be send over
ethernet interface, in which case it will have the
opportunity to merge the data into fewer packets.

>
> 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!

Correct. But well, I only write such programs when
I actually want the TCP connection to send small
packets. If you actually have a program producing
output like this you have to ask yourself what is
most important latency or bandwidth. Do you want
the data transmitted as soon as generated in a
potentially very small packet, or do you rather
want the data to be delayed to save bandwith by
sending more data in each packet?

>
> 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.

You are right. Of course large writes give TCP a
better possibility to do something reasonable.
But it is still possible for TCP to do well even
in case of small writes, but you shouldn't count
on it. 

-- 
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use mailto:aaarep@daimi.au.dk
/* Would you like fries with that? */

Relevant Pages

  • Re: Serial (rs232 etc.) to IP
    ... TCP is a connection based protocol and as such it ensures that all data is ... There is no need to 'use' another protocol like Telnet if all you wish to do ... acknowledgement when the socket is first negotiated. ... >>>character packets when many common embedded TCP devices try to talk to ...
    (comp.arch.embedded)
  • Re: Serial (rs232 etc.) to IP
    ... >> corresponds to 100-1000 character times. ... >character packets when many common embedded TCP devices try to talk to ... If you are using a protocol that was initially written for serial line ...
    (comp.arch.embedded)
  • Re: Serial (rs232 etc.) to IP
    ... Some converters wait 10-100 ms after the last serial character received, before the (TCP or UDP) IP-frame is sent. ... character packets when many common embedded TCP devices try to talk to common desktop operating systems. ... If you are using a protocol that was initially written for serial line ...
    (comp.arch.embedded)
  • Re: Socket help...
    ... >> You are going to have to give us more details of the protocol, ... > I think the packets are pretty simple; just one or two characters at a time. ... the "RST flag" is extremely ... TCP in some bizarre way, or are you talking about some higher-level ...
    (comp.lang.tcl)
  • Re: UPD better than TCP in streaming video/audio ?
    ... > UDP gains speed over TCP because it carries no information that would ... it doesn't even know that packets were lost. ... which is perfect for UDP. ... > Finally, there's the possibility of multicast data - for instance, a live ...
    (microsoft.public.win32.programmer.networks)