RE: connections_timeout_idle

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 01:15 PM 3/23/2003, Howard Chu wrote:
>> -----Original Message-----
>> From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
>
>> This is where poll(2) interface is a bit better than the
>> select(2) interface.   We never switched to the poll(2)
>> because of uncertainty with how well operating systems
>> deal with poll(2) threading issues.
>>
>> Anyways, I suggest that we don't stop reading from a write
>> blocked descriptor.  Instead we should defer processing of
>> operations when the descriptor is write blocked.  And, to
>> prevent DoS, we should have some sane limit on the number
>> of concurrent requests a client can post (likely a low
>> limit for anonymous clients and a higher one for authenticated
>> clients).
>
>When said "sane limit" is reached, can we then just throw away incoming
>requests?

no, but we can drop the connection.

>We have no means of imposing flow control on the client. The
>current patch stops reading and processing requests when there are
>maxthreads/2 outstanding requests on a session. The scenario that raises this
>issue submits thousands of requests before the output blocks. The problem
>with continuing to read the requests is that we burn a lot of CPU resources,
>and in this situation will wind up queueing thousands of requests while
>waiting for the output to drain.
>
>The advantage of not reading is that TCP itself will eventually impose flow
>control on the client, so we don't burn CPU resources in the meantime.

The problem here is that we cannot expect the client to be
well behaved... we need to drain the input stream or get pissed.

>Without the limit of maxthreads/2, we actually process thousands of requests
>before writes get blocked, but by the time the output buffer blocks with the
>thousands of replies we've still got a large number of requests executing.

Sounds like we should rate limit operations.  That is, only allow
a small number of operations to be outstanding (regardless of
write blocking).  And upon write block, don't allow any new
operations to be initiated.