Return-Path: Delivered-To: apmail-jakarta-tomcat-dev-archive@apache.org Received: (qmail 69145 invoked from network); 8 Feb 2002 09:42:22 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 8 Feb 2002 09:42:22 -0000 Received: (qmail 5673 invoked by uid 97); 8 Feb 2002 09:42:24 -0000 Delivered-To: qmlist-jakarta-archive-tomcat-dev@jakarta.apache.org Received: (qmail 5657 invoked by uid 97); 8 Feb 2002 09:42:24 -0000 Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Tomcat Developers List" Reply-To: "Tomcat Developers List" Delivered-To: mailing list tomcat-dev@jakarta.apache.org Received: (qmail 5646 invoked from network); 8 Feb 2002 09:42:23 -0000 From: "Vincent Massol" To: "'Tomcat Developers List'" Subject: RE: Tomcat 3.3 - Cactus Issue Date: Fri, 8 Feb 2002 09:41:57 -0000 Organization: OCTO Technology Message-ID: <003b01c1b084$dd0e0620$a5c8c8c8@octovma> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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: unsubscribe@jakarta.apache.org> > For additional commands, e-mail: help@jakarta.apache.org> > -- To unsubscribe, e-mail: For additional commands, e-mail: