<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META content="MSHTML 5.00.3017.2400" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=677102703-14062000>Hmm,
I'm very surprised you're needing to get down to this level when you're using
something as "high level" as XML as your encoding. XML is so inefficient
as a network protocol that most people would just use standard TCP streams (i.e.
open a stream socket and let TCP take care of the
ordering/guaranteeing/decomposition/reassembly), instead of trying to send TCP
packets as raw packets (heck of a lot of work for no real benefit I can
see). Or do you mean that you're doing a network sniff and are upset that
the packets are getting broken up and reassembled?</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=677102703-14062000></SPAN></FONT> </DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=677102703-14062000>I do
lots of work with UDP-based protocols where these issues come up, but since
UDP is non-guaranteeing, you wind up explicitly dealing with the issues
regardless (they're not easy, incidentally, lots of soft tradeoffs
dependent on current network conditions, required QOS, priority among
messages, etceteras). I tend to favour breaking messages up more (I target
256 bytes, include 26 byte UDP header), rather than less, as small UDP
packets may get through a crowded network, while larger UDP messages will
get dropped when load is high (or at least, that's what certain articles have me
believe :) ). To do it right, of course, you need a dynamically adapting
system that increases message size when load is low (and does a thousand other
optimisations, as well).</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=677102703-14062000></SPAN></FONT> </DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=677102703-14062000>If
I've missed the point, bear with me and explain again. Since I've not
actually grokked what the "problem" being tackled is, it's quite likely I have
missed the point one way or another. Enjoy yourself,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=677102703-14062000>Mike</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=677102703-14062000></SPAN></FONT> </DIV>
<DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma
size=2>-----Original Message-----<BR><B>From:</B> chris
[mailto:chris@rpgarchive.com]<BR><B>Sent:</B> Thursday, June 15, 2000 2:53
AM<BR><B>To:</B> Python List<BR><B>Subject:</B> TCP packet
size?<BR><BR></FONT></DIV>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?
<P>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.
<P>Thanks <PRE>--
chris davis
chris@rpgarchive.com
<A href="http://www.rpgarchive.com">http://www.rpgarchive.com</A>
news and adventure database!
<A href="http://www.openrpg.com">http://www.openrpg.com</A>
open source role playing!</PRE> </BODY></HTML>