Alan Williamson wrote:
> This is great information and thank you for getting back to me so quick.
>
> I have some more questions, which i will send under a different email.
>
> For the moment:
>
> This method for the header doesn't seem to work:
>
> ByteBufferInputStream.setDefaultReadTimeout( 5 );
>
> If i set that, then open a telnet to the port, it will sit and wait for
> input for 30 seconds. So not sure what that value is actually doing.
>
> Is it meant to be in seconds or milliseconds?
Milliseconds. Hum look like a bug to me. Let me take a look on my side
as well. This is supposed to work :-) :-)
Thanks
-- Jeanfrancois
>
> thanks
>
> Jeanfrancois Arcand wrote:
>>> ___ Question #2 ___
>>>
>>> Running a large blog site you see a whole manner of nasty clients
>>> trying to really mess with you. One of things we see a lot of, is
>>> clients that will attempt a subtle DoS attack. They basically drip
>>> feed bytes to the server in such a speed as not to trip up any of the
>>> SO_TIMEOUT alarms. So one character a second for example, could tie
>>> up a connection for minutes. It doesn't take a lot of effort to
>>> really consume a server connections waiting.
>>>
>>> We've taken the approach, that if the complete HTTP header is not
>>> received within X seconds (5 we have found to be acceptable) then we
>>> deny this client from going on any further.
>>>
>>> Again, how would one manage this with Grizzly?
>>
>> This is simple. Just set (this is a static method):
>>
>> com.sun.grizzly.util.ByteBufferInputStream.setDefaultReadTimeout(//Timeout).
>> By default it is set to 30 seconds. This method tell Grizzly to wait
>> //timeout// seconds before considering it is a DoS when reading bytes.
>> This apply to both headers and body.
>
>