gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] Re: RFC: arch protocol, smart server, and tla imple


From: Tom Lord
Subject: Re: [Gnu-arch-users] Re: RFC: arch protocol, smart server, and tla implementation prototypes
Date: Thu, 5 Feb 2004 15:27:29 -0800 (PST)

    > From: Chris Gray <address@hidden>

    > > Regarding the DoS attack -- I don't see any obvious new risk here
    > > unless you are imagining a poor smart-server implementation.

    > Well there's two possibilities that I see: either the server caches
    > all the summary deltas that it creates or it doesn't.  In the first
    > case, the attack makes archive size become something like O(n^2),
    > which could be bad.  On the other hand, all patching would then be
    > O(1), which would be nice.  If the server doesn't cache all the
    > summary deltas it creates, then there is surely some pattern of
    > requests that would make the server do nothing but create deltas all
    > day. 

Not necessarily.  The protocol we've been discussing doesn't require
the server to create every delta it's asked for.  It can instead reply
with a list of deltas that add up to what it was asked for.

A server could therefore reasonably decide to, for example:

~ only create deltas on power-of-two boundaries

or

~ don't create deltas at all when under heavy CPU-load -- just stream
  stuff out.

or

~ <countless other variations>

Such policies are ample to prevent, let's call them, accidental DoS
attacks where a popular server just thrashes wildly under an
idiosyncratic pattern of fair requests.   (And that property puts as
ahead of certain other protocols!)

No policy for any kind of server, of any kind, can, all by itself,
fend off a determined DoS attack in the general sense.


    > Just to compare with what I'm proposing, in a skiplist, you expect
    > that the archive size would grow at about an O(n log n) rate and that
    > patching would be O(log n).  On an archive with 1,000 patches, n log n
    > sounds a lot nicer to me than n^2.

Yeah, but you made up a stupid server implementation that would have
n^2 behavior and you're trying to use that to argue against the
protocols and architecture that would fail to prevent you from
implementing such a stupid server.   Can I have some more of that, but
pickled and on a cracker, please?

-t







reply via email to

[Prev in Thread] Current Thread [Next in Thread]