TCP packet size?

[David Bolen]

chris <chris at rpgarchive.com> writes:

> The messages just aren't reassembled the way I thought TCP worked.  I'm
> hoping to find a way to received one message at a time in its entirety,
> or determine the start and end of my messages.

The wrinkle you're running into is trying to overlay your "message"
concept on top of TCP's "byte stream" concept.  TCP sees your message
as a bunch of bytes, nothing more.  It's perfectly willing (and likely
depending on network conditions) to only get some of those bytes
through before it hands some to the receiver, or to get multiple sent
pieces of data through at the same time.

I think that latter bit - determining the start and end of your
messages - is the way to go.  It sounds like you just need to impose
some structure on top of your raw data being exchanged.  Or, if you
already have some (perhaps to identify the changes at some higher
level), just ensure that you encode it in a way that can be recognized
in a constant stream of data.

Really dumb and simple example - if you're sending XML then you know
that the data stream is a fairly limited character set.  Pick some
byte that is invalid for XML (say a NUL, ASCII 0) or anything else
that won't show up in your data stream.  Use that byte to divide
messages.  On the receiving side, parse through any buffer you receive
(and keep receiving) until you find that character, and only return
the stuff before it.  If you have other data received that's after the
byte, keep it in the buffer until the next time your receiving routine
is called.

Other approaches include having a small header on each message that
includes the length count (TCP is guaranteed delivery, so you can be
sure you'll get that amount of data if it was sent unless the
connection breaks down), or if you want to use a dividing byte that
may occur in the stream, just make sure you quote it (an easy approach
is to double it) within the stream itself.

It takes a little more setup in the beginning when writing your basic
transmit and receive functions, but the important point is to hide
this processing down in those fairly low level routines.  That way,
you only have one place that worries about this - the rest of your
system can just make a request to send or read one of your "messages"
and it will always work at the full message level, no matter how many
individual sends or receives the lower level routines have to do.

--
-- David
-- 
/-----------------------------------------------------------------------\
 \               David Bolen            \   E-mail: db3l at fitlinxx.com  /
  |             FitLinxx, Inc.            \  Phone: (203) 708-5192    |
 /  860 Canal Street, Stamford, CT  06902   \  Fax: (203) 316-5150     \
\-----------------------------------------------------------------------/