tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject RE: Tomcat 3.3 - Cactus Issue
Date Fri, 08 Feb 2002 00:28:18 GMT
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.


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message