Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
en:dpi:bras_bng:radius_integration:radius_auth_fastpcrf_setup:pending_queue [2023/10/13 13:14] – removed - external edit (Unknown date) 127.0.0.1 | en:dpi:bras_bng:radius_integration:radius_auth_fastpcrf_setup:pending_queue [2024/12/05 14:53] (current) – elena.krasnobryzh | ||
---|---|---|---|
Line 1: | Line 1: | ||
+ | ====== Authorization Pending Queue ====== | ||
+ | {{indexmenu_n> | ||
+ | FastDPI sends authorization requests to the fastPCRF server, which, in turn, transmits these requests to the RADIUS server. The RADIUS server bandwidth is limited, so fastPCRF has an internal authorization request queue to smooth out peaks of requests. | ||
+ | |||
+ | The maximum number of requests to the RADIUS server is regulated by the fastpcrf.conf parameter '' | ||
+ | <code bash> | ||
+ | # 4 connections with 256 requests = 1024 simultaneous requests | ||
+ | radius_max_connect_count=4 | ||
+ | </ | ||
+ | |||
+ | If an authorization request comes from fastDPI and all connections to the RADIUS server are busy, the request is placed in the internal FIFO waiting queue. | ||
+ | When a response is received from the RADIUS server and the slot becomes free, fastPCRF extracts the pending request from the queue and sends it to the RADIUS server. | ||
+ | |||
+ | There are two fastpcrf.conf parameters that control queue behavior: | ||
+ | |||
+ | * '' | ||
+ | * '' | ||
+ | |||
+ | The authorization pending queue can also be managed by CLI commands '' |