tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vincent Massol" <vmas...@octo.com>
Subject RE: Tomcat 3.3 - Cactus Issue
Date Fri, 08 Feb 2002 09:41:57 GMT
Ok. Thanks Costin. What I'll keep in mind is that it is complex ... ;-)
-Vincent

> -----Original Message-----
> From: costinm@covalent.net [mailto:costinm@covalent.net]
> Sent: 08 February 2002 00:28
> To: Tomcat Developers List
> Subject: RE: Tomcat 3.3 - Cactus Issue
> 
> 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:tomcat-dev-
> unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:tomcat-dev-
> help@jakarta.apache.org>
> 




--
To unsubscribe, e-mail:   <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>


Mime
View raw message