TCP packet size?
Grant Edwards
ge at nowhere.none
Wed Jun 14 17:51:17 EDT 2000
In article <39487D5B.FC96BE3F at rpgarchive.com>, chris wrote:
> Is there a way to ensure or predict packet size when using TCP?
Nope.
TCP/IP guarantees that the bytes get there in the right order.
It neither knows nor cares about any sort of boundaries between
bytes.
> 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?
That's the way TCP/IP works. You're using a stream protocol to
try to send datagrams. That's like trying to juggle tennis
balls while wearing shoes on your hands. Shoes are a damn fine
invention, but you've got to use them for the right thing.
You want to use a datagram service instead of a stream service.
There's UDP, but it's unreliable, so you've got to add your own
ack/retry scheme -- bit of pain. On Linux "man socket" claims
to support reliable datagrams:
SOCK_SEQPACKET
Provides a sequenced, reliable, two-way connection-
based data transmission path for datagrams of fixed
maximum length; a consumer is required to read an entire
packet with each read system call.
That sounds like what you want, except it's not implemented for
address type AF_INET (which is probably what you're using).
Bummer.
There's also plain old unreliable datagrams (SOCK_DGRAM), and
reliable, unordered datagrams (SOCK_RDM). Probably the only
ones you can depend on being available are SOCK_STREAM (TCP/IP:
which is what you're using) and SOCK_DGRAM (UDP/IP: unreliable
datagrams).
>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.
Maybe you can find somebody who's already written a reliable
datagrram layer that runs on top of UDP/IP?
--
Grant Edwards grante Yow! Yow! We're going to
at a new disco!
visi.com
More information about the Python-list
mailing list