[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Limiting access to replay in 1.4

From: Jonathan Gilbert <o2w9gs702_at_sneakemail.com>
Date: 2006-04-19 03:05:56 CEST

At 07:37 PM 12/04/2006 +0200, Molle Bestefich wrote:
>> Why not let the server dynamically decide if rate limiting is required to
>> share access to itself among connections?
>
>Unless you can make it unusually bright, a problem with a completely
>automagic system is that it's too fair. Consider fx. a sudden blast
>of anonymous users that each get a fair (but extremely minimal) share
>of bandwidth. The developers would then get the same extremely
>minimal amount of bandwidth each. You really don't want to be that
>fair :-).

How about a sort of "lazy" resource limiter, one which only kicks in once a
client has reached a certain level of usage? That way, short queries always
run quickly because they finish before the limitations kick in. Someone
asking for all versions of the entire tree will get the first N
kilobytes/seconds of CPU time/kilobytes of memory at full speed, but then
when it becomes clear that the request isn't anywhere near finishing, the
limiter starts, well, limiting that particular person. Other people doing
short queries at the same time would be unaffected by the limitations.

This of course doesn't do anything to stem an intentional denial of service
attack (apart from forcing such a malicious person to make many short-lived
connections rather than just one long one -- if the number of connections
from each IP were itself rate-limited, that could potentially deal with
non-distributed DoS attacks), but rather prevents accidental requests from
blowing up the server and also allows legitimate long-running requests to
proceed at a lower speed without preventing anybody else from effectively
using the system.

I don't think something like this would be too complicated to implement,
though I could be wrong... :-)

Jonathan Gilbert

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Apr 19 03:12:14 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.