TCP packet size?

[Thomas Wouters]

On Thu, Jun 15, 2000 at 01:53:15AM -0500, chris wrote:

> Is there a way to ensure or predict packet size when using TCP?  I'm
> developing a Multi-user application that functions much like a
> muli-player game.  The applications are sharing xml data.  The xml data
> can get very big 3000-6000 bytes.  Unfortunately, when the size of the
> network message gets over about 2000, its to get broken up into smaller
> packets.  So, when I send a 3000 byte message it gets cut up into 2-3
> packets.  Anther problem I get is when I send two small messages back to
> back, they are sometimes received together.  Is there something I'm
> missing here?

> I tried using headers and breaking up messages into smaller chunks, but
> the size of the receiving packets doesn't always match what I sent.  I'd
> appreciate any help or suggestions on how I can tackle this problem.
> I'd be happy to send someone my network code.

Are you sure you are using TCP ? A TCP connection is supposed to createa a
'virtual circuit' that relieves you of all the troubles of determining
packet size, handling out of order arrival, losing packets, etc. What you
describe sounds more like UDP than TCP, and if you are working with UDP, you
better be damned certain you want UDP ;-)

IP packet sizes are limited by the 'Maximum Transmission Unit', which should
be between 68 and 1500 bytes. Most modern TCP/IP stacks do path MTU
discovery to lower the MTU when it is necessary (the other side, or a router
on the link to the other side, apparently can't or won't handle a large MTU,
so it is lowered.) so it's not really safe to rely on that size.

This restriction goes for both TCP and UDP, though TCP automatically breaks
up any data you send through the connection into packets of the right size,
and reassembles them on the other size, in order. TCP packets are also
guaranteed to arrive in-order, and there is error-control so that lost
packets are re-sent.

UDP does not have all these control functions (that's why it's called the
Unreliable Datagram Protocol ;-) and that means you have to do all those
things yourself: keep a packet counter, notify the other end when packets
are lost, wait for them to arrive in-order, and make sure your packets
aren't too large(*). For large datatransfers it is likely not worth it. If
you really need the unreliable properties of UDP (like not stalling when you
are experiencing packetloss), make two connections, TCP for data and UDP for
signaling the other side.

You should also keep in mind that using UDP will probably fail when the
connection has to pass through a firewall or NAT (Network Address
Translation) situation.

*) I haven't done enough UDP things in Python to know how to do these things
easily, so I can't help you there, sorry ;-P

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!