It's a limitation of HTTP/1.1. You need a connection for each HTTP request in flight. The rlm_rest module in v4 supports HTTP/2.0, so it can multiplex (run multiple requests over the same TCP connection simultaneously). The v4 module is also fully asynchronous, and uses a slab allocator for handles to minimise runtime memory allocations. It's about as good as it gets for a libcurl based implementation. On the commercial side (InkBridge), we've also integrated Netbox to do static IP assignment for our LDAP subscriber management API, it's very nice :) -Arran
On 10 Mar 2025, at 13:12, Brian Julin <BJulin@clarku.edu> wrote:
Michael Schwartzkopff wrote:
I jusst published a blog article how to use netbox as a backend for FreeRADIUS to lookup MAC addresses for MAC-bypass. It is a nice exercise of the use of the rest module of FreeRADIUS.
Nice... yes netbox is a pretty easy REST target. I'd encourage a test environment with it though as the netbox devs like to... change stuff... a lot.
Also, last time I looked at rlm_rest I was a bit concerned about the number of connections it seems to want to keep running. Maybe overly so... there isn't much of a guide about whether every thread really needs a connection or whatnot. Consolidated all transactions into an SQL database to eliminate races and batched them up from a single-connection REST script instead.
A linux box running netbox won't be bothered very much by this but with some appliances there's a pretty low limit on the number of REST connections allowed, so if you have a lot of services/servers trying to hit something over REST any extra connections can add up fast.
Maybe I misunderstand the way REST uses connections or maybe FR4 has improvements in sharing live connections between threads.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2