Re: implementing delay...

Willy Tarreau wrote:
> Hi Andrew,
>
> On Sun, Aug 02, 2009 at 03:53:56AM +0200, Andrew Azarov wrote:
>
>> Hi,
>>
>> Is there a way to delay a connection for some time?
>>
>
> Depending how you want your delay to be used, you might be able
> to use it with TCP rules, something like this :
>
> acl acl_to_delay <something>
> tcp-request content accept if !acl_to_delay
> tcp-request content accept if WAIT_END
>
>
>> I've done a clone of tarpit (with bindings and reqidelay), but it
>> doesn't want to work
>>
>> if (txn->flags & TX_CLDELAY) {
>> /* wipe the request out so that we can drop the
>> connection early
>> * if the client closes first.
>> */
>> buffer_write_dis(req);
>> req->analysers |= AN_REQ_HTTP_DELAY;
>> req->analyse_exp = tick_add_ifset(now_ms,
>> s->be->timeout.delay);
>> if (!req->analyse_exp)
>> req->analyse_exp = tick_add(now_ms, 0);
>> }
>> int http_process_delay(struct session *s, struct buffer *req)
>> {
>> struct http_txn *txn = &s->txn;
>> if ((req->flags & (BF_SHUTR|BF_READ_ERROR)) == 0 &&
>> !tick_is_expired(req->analyse_exp, now_ms))
>>
>
>
> You have to add that before return because process_session()
> will enable it first :
>
> buffer_write_dis(req);
>
>
>> return 0;
>> if (req->flags != BF_READ_ERROR)
>> buffer_write_ena(req);
>> return 1;
>>
>
> And here since the delay is expired, you have to remove your
> analyser :
>
> req->analysers &= ~AN_REQ_HTTP_DELAY;
>
>
>> return 0;
>> }
>> Upon match it doesn't delay, it just waits until 503 error...
>>
>
> Probably because of the missing flush of the analyser bit (I think).
>
>
>> Seems like I've done it wrong somewhere with buffer_write_dis|ena(req)?
>>
>
> In part :-)
>
> Also, I suggest that you do that with 1.4-dev1, you may find it
> much easier and you will be able to duplicate code from smaller
> functions. Also one of the advantages is that multiple analysers
> may be enabled at once.
>
> Regards,
> Willy
>
>
>

Hi Willy,

I've done everything you suggested, now upon the match it gives right away 400 error (passes through the request processing further)... Maybe I should loop inside function to check for the tick? (or maybe shouldn't because it might block?)

Also is 1.4-dev1 stable enough for production? We are kicking ddos bots with haproxy (and very successfully), just that haproxy doesn't have rate limit per ip and delay per request and cookie management (redirecting request, setting and keeping random cookie in memory for 1 ip for X time) with bouncing of if cookie is ! . Thought I'd start implementing from the least problematic :) however the arch of this program is complex so I need some time to analyse it, and I don't have that time unfortunately.

BRG,
Andrew Received on 2009/08/02 16:07