RE: DoS attack ?

[John C Klensin <klensin@jck.com>]

--On Friday, 07 December, 2001 07:33 +0100 Patrik Fältström
<paf@cisco.com> wrote:

>> So, just from that standpoint, it could be useful for the
>> protocol to support the notion of results set range (query)
>> as well as referral (response).
> 
> We have been through this when looking at other
> protocols....and I would urge you to learn from earlier
> mistakes (and successes).
> 
> (1) One practical path is to give in the protocol a way for
> the server to say "I'm sorry, but I will not do that operation
> you requested. Instead I did the following". This generic
> response can be "you only got 10 records even though the
> result set is larger".
> 
> (2) As soon as you do "paged results", you force the server to
> keep state. Depending on whether the protocol is stateful or
> stateless, it is harder or easier for the server to know when
> to remove the cached search. Further, as soon as you start
> doing pages results, you end up getting problems with sorting
> the result, handling of database changes between the two
> fetches (i.e. can the server re-issue the query for the second
> fetch, or do the server really have to cache the result set
> and return the second part at the second fetch) and million of
> other problems.
> 
> So, my suggestion is "don't go there".

I think, given this and what I wrote earlier, we are in violent
agreement.  I would only add, to both your comments and mine,
that keeping state in a distributed system -- one in which a
"first" query could reach one server and a subsequent one could
reach a second one-- is terribly complex technically.  While it
is, of course, possible to be sure that all queries in a
sequence go to the same server (e.g., by opening a TCP
connection for the query and keeping it open until the query is
completely satisfied) such things don't have very attractive
performance or scaling proper for high-demand,
frequent-repetition, short processes.

    john