System.Threading.RateLimiting for .NET: easy using of the vast capabilities.

SafeValue must use [property]=binding: All ever faced with a well-known problem for web servers rate limiting. One of the simple and efficient ways to handle a situation like this is the client's application's built-in rate limiting that avoids triggering web server's limitations. Also, the other resources like file and database servers may need the same behavior to avoid monopoly use. You may say that any tough developer will make their rate limiting apparatus in a blink of an eye but how many bugs you'll get in a second blink? So .NET decided to create the package System.Threading.RateLimiting is dedicated to defining a common rate-limiting framework that allows several rate-limiting options out of the box. For the implementation of all rate limiters, were defined the abstract base class is called simply and firmly RateLimiter. It provides a synchronous and asynchronous way and simantenously determines a count of available leases. RateLimitLease class provides the lease, or in other words, permission from the rate limiter to do work and returning to the pool as soon as a current task is completed. Here are the four ready-to-use built-in rate limiters which System.Threading.RateLimiting offers. ConcurrencyLimiter is the simplest. It allows using only a defined number of concurrent workers at one time. FixedWindowRateLimiter uses a simple timespan to reset the count and limits the number of requests for a given window of time. SlidingWindowRateLimiter does the same, but the time window is divided into N segments; each has a request counter. TokenBucketRateLimiter provides the ability when multiple leases are needed at once. It is inspired by the token bucket algorithm, which helps to match and organize the number of leases each worker wants with the available lease at each given moment. For the synchronous case, RateLimitLease is returned a failure flag when the rate limiter can't grant a lease request. For the asynchronous case, the picture is somewhat different. If the queue grows beyond a configurable limit, you may configure whether the newest or oldest request will be rejected. You should definitely do it because the workers may be rejected from the queue. Note that aggregated limiters do not support explicitly by this library. For this purpose, the developers recommend packages explicitly developed for ASP.NET Core, such as AspNetCoreRateLimit. (see http://g.co/ng/security#xss)