From: Gary Wright <gwtmp01@...>
Date: 2009-07-21T23:02:19+09:00
Subject: Re: Another TCPSocket Question


On Jul 21, 2009, at 9:42 AM, Greg Chambers wrote:
> Does anyone have any idea as how to fix my use
> of #readpartial or maybe another method that will suit my needs?

I suspect that you are thinking about this problem
as if TCP keeps track of message boundaries, which
is not the case.

If one side of a TCP connection sends 20 bytes of
data via a single call to write, there is no way
to ensure that the other side reads the same exact
20 bytes of data via a single read. The reading
side may see one read of 20 bytes or perhaps 2
reads of 10 bytes or even 20 reads of a byte each.
In theory there can be arbitrarily long delays
between the successful reads. TCP connections
are streams of bytes with no message boundaries.

In practice, this means that you need to impose
your own record boundaries on the data and track
them yourself.  The easiest example would be to
insert newlines while sending and look for them
while receiving.  Another common approach is to
have a header that indicates the length of the
record so that the reading size knows how many
bytes to read.

There is no right or wrong answer here it just
depends on how you design your protocol on top
of the TCP byte stream.

If your data has newlines ending each message
(or even some other message separator)
you should be able to use gets or readline.  If
the message size is built-in to the protocol then
you should be read the correct number of bytes
based on your protocol definition (or header).

If there is no way to determine the end of the
message other then some sort of ambiguous timing
constraint (data hasn't arrived for a couple of
seconds) then I think you'll need to rethink
your protocol.

Gary Wright