[ee122] recv() and read() buffer length question

[Daniel Killebrew]

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.

Daniel
> Thanks!
>
> -Niels
> _______________________________________________
> ee122 mailing list
> ee122 at mailman.ICSI.Berkeley.EDU
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122
>
>