Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <44941E89.7080303@hanik.com>
Date: Sat, 17 Jun 2006 10:23:53 -0500
From: Filip Hanik - Dev Lists <devlists@hanik.com>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: Tomcat Developers List <dev@tomcat.apache.org>
Subject: Re: Tomcat Comet Model, DOS example
References: <44933E5B.1080903@hanik.com>
 <449340FD.9090207@apache.org>	 <44934503.2090803@hanik.com>
 <4493472C.4090304@apache.org>	 <44934936.9000906@hanik.com>
 <96e4b5230606161751j6c7c1f9el3d55659c45238bd9@mail.gmail.com>
 <44935BFA.9020000@hanik.com> <4493A589.4030704@apache.org>
In-Reply-To: <4493A589.4030704@apache.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Remy Maucherat wrote:
> Filip Hanik - Dev Lists wrote:
>> I agree, chunked would be the way to go for a communication.
>>
>> I reverted my fix, however, now TC6 has a DOS possibility, by 
>> following these steps
>>
>> 1. Override CometServlet.read, always return true (you wanna serve N 
>> client requests, and you don't know how many its gonna send, so this 
>> is not unreasonable)
>
> I fail to see why doing that is reasonable: you're getting an event to 
> read data, so you have to read it even if you're not going to use it 
> (as in NIO).
yes, and since I am receiving the read event, I'm expecting data, no 
data was available, so I return true to wait for it become available.
Tomcat fails to deliver the data, even though it issues a read(req,resp) 
event.
Two solutions
1. Deliver the data (my reverted checkin)
2. Read the socket, discard the data, never call read

> Right now I'm not hot about reading the data first in the container: 
> if done, it should be in InputBuffer, 
yes, that is how I suggested it to be done. The AprBuffer was reading 
the socket data in my checkin.

> but could mean automagically discarding data, which could become a 
> very sneaky problem if the user doesn't code the right way but is 
> interested in the data.
yes, I prefer delivering the data. option 1
>
> There are still some serious problems though, starting with the 
> current C2B and B2C converters which use far too much memory. I would 
> like to use the NIO converters instead, but they want to use 
> ByteBuffer and CharBuffer.
yes, and ByteBuffer and CharBuffer have historically been slower than 
byte[] and char[], not sure if that is still the case.
>
> Rémy
so where do we stand, you cool now? can I go back and work on my 
checkin, improve it, and continue working on the Comet feature?

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


-- 


Filip Hanik

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