------art_540_33256646.1193737473346
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 10/30/07, 7stud -- <bbxx789_05ss / yahoo.com> wrote:
>
>
> That's not what I'm seeing.  What I see is: read() blocks until it
> either receives the limit number of bytes or eof is encountered(when the
> server closes the socket).  In other words, read() does not return as
> soon as data is available if the amount of bytes read is less than the
> limit number of bytes.  On the other hand, recv() returns whatever it
> reads immediately.  Here is the code:


...snip...

So the way I see it:
>
> 1) If the amount of data sent by the server is less than the size limit
> specified in read(), read() will block until the server closes the
> socket.  Therefore, the server must close the socket.
>
> 2) If the amount of data sent by the server is more than the size limit
> specified in read(), and you just write:
>
> all_data  ead(1012)
> puts data
>
> then you aren't reading all the data. You just get the first 1012 bytes.



We know nothing about the protocol that the OP is using (because he hasn't
told us yet). It may not be realistic for the client to have an expectation
about how much data the server will send. #select may turn out to be the
best choice.

#read with no parameters works if the server closes the connection after
sending. But as a general rule, that's a bad server design (ideally, the
client should close the connection, for reasons relating to the TIME_WAIT
state).

------art_540_33256646.1193737473346--