On Jun 25, 2019, at 9:42 AM, wli...@bloomberg.net wrote:
>> I'm still thinking about a possible solution using a global queue and a
>> global
>> timer (and the timer just resuming queued transactions at pre-defined
>> internal), but to implement that:
>> 1. Is it ok to put/store a transacti
> I'm still thinking about a possible solution using a global queue and a
> global
> timer (and the timer just resuming queued transactions at pre-defined
> internal), but to implement that:
> 1. Is it ok to put/store a transaction in an external queue?
> 2. Is it safe to not call transaction.r
gt;>>>> Headers& headers = transaction.getClientRequest().getHeaders();
>>>>>>>>>> Headers::iterator ii = headers.find("Host");
>>>>>>>>>>
>>>>>>>>>> if (ii != headers.end()) {
>>>>>>&
> On Mon, Jun 24, 2019 at 7:28 PM Sudheer Vinukonda
> wrote:
> > @Weixi Li,
> >
> > The more I read about your use case, it seems like you could probably
> > directly leverage the rate limiting that ATS core already supports (unless
> > you’ve other custom requirements). You can configure the bel
>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> On Jun 24, 2019, at 13:12, Weixi Li (BLOOMBERG/ PRINCETON) <
>>>>>> wli...@bloomberg.net> wrote:
>>>>>>>>>
>>>
OOMBERG/ PRINCETON) <
>>>>> wli...@bloomberg.net> wrote:
>>>>>>>>
>>>>>>>> Hi Dk,
>>>>>>>>
>>>>>>>> Thanks a lot for the example. It is really inspiring. I have a
>&
t;>>>>>>
>>>>>>>> On Jun 24, 2019, at 1:12 PM, Leif Hedstrom wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> On Jun 24, 2019, at 13:12, Weixi Li (BLOOMBERG/ PRINCETON) <
>>>>> wli...@bloomberg.net> wrote:
>>>>>>>>
>>>>>>>> Hi Dk,
>>>>>>>>
>>>>>>>> Thanks a lot for the example. It is really inspiring. I have a
>>>>> question
t; question though: in case of "bucket->consume()" returning false, the
>> code
>>>> would return a 429 response. In our use-case, we don't want to deny the
>>>> client with a 429 (but want to queue the request instead). How to handle
>>>> the false
in itself? (That's
> why
> >> I was asking about queue and async timer).
> >>>>
> >>>> Oh do you want to stall the client, not deny? Depending on the plugin
> >> and the hook, you can probably just reschedule the HttpSM to come back
> on
> >> say 5
e to make sure they don’t stall fore ever though, and perhaps
>> have a priority such that older clients are given tokens before new ones.
>>>>
>>>> Should be doable, but definitely more complex.
>>>>
>>>> — Leif
>>>>&g
kens before new ones.
> >>
> >> Should be doable, but definitely more complex.
> >>
> >> — Leif
> >>>
> >>> Thanks,
> >>> Weixi
> >>>
> >>> From: dev@trafficserver.apache.org At: 06/24/19 01:28:40To:
e you normally would.
>> Have to make sure they don’t stall fore ever though, and perhaps have a
>> priority such that older clients are given tokens before new ones.
>>
>> Should be doable, but definitely more complex.
>>
>> — Leif
>>>
>>>
t;>
>> From: dev@trafficserver.apache.org At: 06/24/19 01:28:40To: Weixi Li
>> (BLOOMBERG/ PRINCETON ) , dev@trafficserver.apache.org
>> Subject: Re: Implementing Rate-limiting in forward proxy mode
>>
>> Not sure you need queues. Here's a sample imple
are given tokens before new ones.
Should be doable, but definitely more complex.
— Leif
>
> Thanks,
> Weixi
>
> From: dev@trafficserver.apache.org At: 06/24/19 01:28:40To: Weixi Li
> (BLOOMBERG/ PRINCETON ) , dev@trafficserver.apache.org
> Subject: Re: Implementing Rate-
g might be necessary (let me know if I'm
> wrong):
> > * A hook to TS_HTTP_SEND_REQUEST_HDR_HOOK
> > * A map of queues (one queue per rate-limited site)
> > * A map of async timers (one timer per queue)
> >
> > I will study the ATS code more to understand the event
7;m
> wrong):
> > * A hook to TS_HTTP_SEND_REQUEST_HDR_HOOK
> > * A map of queues (one queue per rate-limited site)
> > * A map of async timers (one timer per queue)
> >
> > I will study the ATS code more to understand the event and threading
> model
> > bett
let me know if I'm wrong. Thanks!
From: dev@trafficserver.apache.org At: 06/21/19 23:11:03To: Weixi Li
(BLOOMBERG/ PRINCETON ) , dev@trafficserver.apache.org
Subject: Re: Implementing Rate-limiting in forward proxy mode
Uhm! why async timers? You'd want to implement a leaky/token bucket per
sit
ATS code more to understand the event and threading
>> model
>>> better.
>>>
>>> Thank you all.
>>>
>>> From: dev@trafficserver.apache.org At: 06/21/19 19:52:44To:
>>> dev@trafficserver.apache.org
>>> Subject: Re: Implem
to understand the event and threading
> model
> > better.
> >
> > Thank you all.
> >
> > From: dev@trafficserver.apache.org At: 06/21/19 19:52:44To:
> > dev@trafficserver.apache.org
> > Subject: Re: Implementing Rate-limiting in forward proxy mode
gt;
> From: dev@trafficserver.apache.org At: 06/21/19 19:52:44To:
> dev@trafficserver.apache.org
> Subject: Re: Implementing Rate-limiting in forward proxy mode
>
> I have implemented rate-limit in my plugin using atscppapi. We are using
> ats in
> security context for mitigation. I
plementing Rate-limiting in forward proxy mode
I have implemented rate-limit in my plugin using atscppapi. We are using ats in
security context for mitigation. If the request matches certain criteria (ip,
method, host, uri and header values) then we apply rate-limit to that ip.
Dk.
> On Jun
I have implemented rate-limit in my plugin using atscppapi. We are using ats in
security context for mitigation. If the request matches certain criteria (ip,
method, host, uri and header values) then we apply rate-limit to that ip.
Dk.
> On Jun 21, 2019, at 3:15 PM, Leif Hedstrom wrote:
>
>
Additionally, fyi, there’s an indirect rate limiting support inbuilt into the
ATS core via limiting concurrent connections per origin.
Refer ‘proxy.config.http.per_server.connection.max’ and
‘proxy.config.http.per_server.connection.queue_size’.
You may want to check that out, and if it doesn’t
There is no need to fork the code to create a plugin:
https://docs.trafficserver.apache.org/en/8.0.x/developer-guide/plugins/getting-started/a-simple-plugin.en.html
Once it's working and tested, it would be appreciated if you would offer it
for addition in plugins/experimental under TS's Apache li
> On Jun 21, 2019, at 16:09, Weixi Li (BLOOMBERG/ PRINCETON)
> wrote:
>
> Hi team,
>
> We are experimenting with ATS in *forward* proxy mode. Our use-case requires
> a rate-limiting component that enforces rules based on the destination.
>
> For example:
>
> For all incoming requests tar
Hi team,
We are experimenting with ATS in *forward* proxy mode. Our use-case requires a
rate-limiting component that enforces rules based on the destination.
For example:
For all incoming requests targeting "www.cnn.com", we want to limit the
outgoing rate to be 10 requests per minute; for "w
27 matches
Mail list logo
