LiteClient Rate Limiting
Purpose And Scope
LiteAPI providers may enforce rented-liteserver quotas such as a fixed number
of requests per second. The crate models these quotas as local throttling, not
as LiteAPI protocol messages. LiteClient can throttle one connection, and
LiteBalancer can throttle either every owned peer or the balancer’s total
outgoing request attempts.
Data Model
RequestRateLimit { rps, burst } defines a token bucket:
rpsis the steady-state refill rate in whole requests per second.burstis the maximum number of tokens and the number of immediate requests available after constructing the limiter.rps == 0andburst == 0are invalid.
The limiter has no wire format. It runs before a serialized LiteAPI request is
sent through liteServer.query.
Invariants And Edge Cases
- Throttling waits asynchronously instead of returning a rate-limit error.
- Default clients and balancers are unlimited.
- A cancelled wait does not consume a
waitMasterchainSeqnoprefix because the limiter is acquired beforeLiteClient::query_rawtakes the pending seqno. LiteBalancerglobal limiting counts actual attempts, including retries and eachsend_messagepeer attempt.- Per-peer limiting is independent per
LiteClient; it does not cap aggregate balancer throughput unless every peer has the same cap and peer selection is balanced.
Current Crate Mapping
src/liteclient/rate_limit.rsimplementsRequestRateLimit, validation, the asyncRateLimiter, and deterministic token-bucket tests.src/liteclient/client.rsstores an optional limiter and acquires it at the start ofquery_raw.src/liteclient/balancer.rsstores an optional global limiter and applies it in the sharedexecute_requestpath.src/cli/mod.rsmaps--rpsto per-liteserver limits and--global-rpsto balancer-wide attempt limits.
Missing Work
- Live validation against tonconsole-style rented liteserver credentials.
- Optional metrics for limiter wait time and throttled attempt counts.
- Broader integration tests for retry-heavy balancer flows.