On Thu, 7 Feb 2002, Vincent Massol wrote: > Last thing I'd like to confirm : When data is sent over a socket, it > will fill the socket buffer (at the client side) and then sending of > data will block until the server side reads from the socket buffer ? If
The first part - I'm not sure. I expect the TCP stack to be able to send some chunks of data without buffering and some with buffering. The BSD book has some nice pictures :-) The client may block until the server reads - TCP has flow control, but again it's hard to predict when does it happen ( but more likely for very large chunks of data ). > the server closes the socket and there is data in the socket buffer, on > the client side, the client socket will report an exception. Is that > correct ? The server can't know if there's data on the client's buffer. The whole thing is very complicated - I allways had doubts that I understand it, and explaining it corectly is beyond my ability. What I know for sure is that you _may_ get an exception ( on some OSes ) if there is data in the buffer of the side that is issuing the close(), so that's the first thing I check. If close() is 'clean', i.e. all data has been send/received - there's no exception. If an exception is generated, things are very intersting on some systems - it may be possible that you'll get it out-of-band, i.e. you'll be interrupted before reading the whole response, even if data was sent completely and received. That was another difficult bug, when the client saw only a partial response page - and was caused by the same problem, on OS where the ABORT is sent as soon as it is received ( which I think is the correct behavior ) and the read() will not continue to get available data. Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
