vern at icir.org
Thu Sep 20 09:16:03 PDT 2007
> Can anyone illuminate what records are again? And how any of them could not
> be full?
We haven't particularly used the term "record". In general, applications
exchange "messages", and it's up to the application to figure out how to
tell where one message stops and another begins. (Such messages might be
thought of as records if they have a consistent set of fields within them.)
When using UDP, the service model is that whatever datagram you hand UDP
using send() is what shows up at the other end (if it shows up at all) via
a call to recv().
However, for TCP no such send() boundaries are preserved. A single send()
call might require multiple recv() calls on the other end to recover all
of the bytes; a single recv() call might return bytes that were sent using
multiple send() calls, including fractions (e.g., just the last 1/3 of the
bytes sent by a send() call for which the previous 2/3 bytes were returned
by the previous recv() call).
> Would the only reason for recv() return part of a record be because
> the buffer exceeded the max 2048 size?
Per the above, for TCP, no.
> And on that note, the common mistakes states: Separating the records in a
> TCP stream. How do we have any control over whether or not send() splits the
> Or does it have more to do with how we select() clients?
Yes. If you call recv() and not all of the bytes were available, then
once they are select() will again indicate that the file descriptor has
data ready to be read.
More information about the ee122