[ee122] records

[Merry Choi]

So, when we call recv(), do we always have to read in 2048 bytes? We can
pass the number of message bytes in Send() by strlen(buffer), but there is
no such call for recv() since we don't know if num_received = recv() is
really the entire message. Correct?



-----Original Message-----
From: Vern Paxson [mailto:vern at icir.org] 
Sent: Thursday, September 20, 2007 9:16 AM
To: Merry Choi
Cc: ee122 at ICSI.Berkeley.EDU
Subject: Re: [ee122] records 

> 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
> records?

Likewise, no.

> 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.

		Vern