Tcp {active, true} problem

[Scott Lystig Fritchie]

>>>>> "ml" == Martin Logan <martin@REDACTED> writes:

ml> My problem
ml> arises when I send a number of packets quickly( < 500 ms). I
ml> receive them as one large ascii string.

TCP will guarantee that your stream of data will arrive and with the
bytes in the proper order (or let you know something went wrong), but
it doesn't provide any guarantee beyond that.  If a TCP stream S is
established between A and B, and A writes 3 chunks of data to S (with
lengths of L1, L2, and L3), you have no guarantee that B, executing
read() or recv() or whatever three times, will read three chunks of
data with respective lengths L1, L2, and L3.(*)

In your greater than 500ms case, you were simply lucky that you got
three reads of the size you were expecting.

If you want that kind of record-boundary-honoring thing, you need to
use UDP.  UDP places limits on the maximum datagram size, so that
solution doesn't work in all cases.  Your other option is to embed
additional data in the stream itself to tell the receiver where record
boundaries lie.

-Scott

(*) Hm.  W. Richard Stevens, _TCP/IP Illustrated, Vol 1_ states this
more clearly?  Differently, at least.  IMO, every programmer should
have this book on his/her shelf.  After reading it all the way
through, of course.  :-)

Page 224 says (except for typos):

"A stream of 8-bit bytes is exchanged across the TCP connection
between the two applications.  There are no record markers
automatically inserted by TCP.  This is what we called a "byte stream
service".  If the application on one end writes 10 bytes, followed by
a write of 20 bytes, followed by a write of 50 bytes, the application
at the other end of the connection cannot tell what size the
individual writes were.  The other end may read the 80 bytes in four
reads of 20 bytes at a time.  One end puts a stream of bytes into TCP
and the same, identical stream of bytes appears at the other end.

"[...] This treatment of the byte stream by TCP is similar to the
treatment of a file by the UNIX operating system.  The UNIX kernel
does no interpretation whatsoever of the bytes that an application
reads or writes -- that is up to the application."