[ee122] recv() and read() buffer length question
dank at eecs.berkeley.edu
Sun Sep 23 21:04:40 PDT 2007
Niels Joubert wrote:
> Hello all!
> I'm running into a conceptual problem with read and recv in terms of the
> buffer you pass it. If i understand sockets correctly, the chain of
> events is somthing like this:
> Server app calls send - > data goes to kernel buffer -> data gets
> transmitted -> data gets assembled into kernel buffer -> client calls
> read with a buffer to be filled up.
> So far we've been handing read and/or recv() a fixed length buffer. Recv
> then returns with the amount of bytes filled into this buffer. If the
> buffer you hand it is bigger than the amount of data in the kernel
> buffer, its all good. what is there is more data in the kernel than the
> buffer you handit can take? how do you know to read more data to get the
> whole request?
You call read() again. Also, if you are using select(), next time you
call it, it should return immediately, telling you that the socket is
ready to read from.
> For example, if the server is sending a 1 Mbyte file, and you have a
> little 2048 bytes big buffer in your client. you have to know to keep on
> reading 2048 bytes and doing something with it until there is no data
> left from the server. How do you do this? The only way i've found is to
> use non-blocking IO and watch the errno for a message saying that there
> is no data to be read.
You can use select() with a timeout of 0 (essentially nonblocking IO).
> Or should you purely rely on your own identifiers
> to mark the end of a transmission of something like a file?
That works too.
> ee122 mailing list
> ee122 at mailman.ICSI.Berkeley.EDU
More information about the ee122