Indeed, the common description of TCP is that of a "byte stream"
protocol.  You stuff bytes into a TCP connection at one end, and a
stream of bytes emerges at the other.  Message boundaries are the
responsibility of the application.

If your application was not _quite_ keeping-up all the time before,
some quantity of data may have queued in the socket buffer, and then
when it called recv() et al, it would get more data.  If the
applicationis then keeping ahead of the network, then it will get data
in something closer to the size of the TCP segments when they were
sent.

On networks with a 1500 byte MTU, and applications pushing non-trivial
quantities of data, it is common for there to be 1460 bytes of data in
each TCP segment.

Greater detail can be found in most of the books on TCP/IP - the works
of the late W. Richard Stevens come to mind.

Now, having said that...

Long ago, (and I've no idea if it is still there today), NetIPC and
the NS Transport TCP code conspired to produce a non-standard hack
called "message mode" whereby TCP would overload a bit in the header
to serve as a message marker, and NetIPC could be told to only provide
complete messages.  This was non-standard, icky, and not (iirc)
brought forward to the sockets stuff in MPE/XL (does that show how
long it's beeen since I've done MPE?-)

rick jones


--
oxymoron n, commuter in a gas-guzzling luxury SUV with an American flag
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to raj in cup.hp.com  but NOT BOTH...

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *