tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Hanik - Dev Lists <devli...@hanik.com>
Subject Re: Tomcat Comet Model, DOS example
Date Sat, 17 Jun 2006 15:23:53 GMT
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


Mime
View raw message