I was responsible for multiple RADIUS services used by millions of people every day. The existing software is slow to build with, difficult to scale and expensive. I couldn't let it go.
Step one was building the platform to run it on and make it sustainable as a business. Step two is implementing protocols like RADIUS that lack a separated compute/storage model but should really have one.
I chose C# because I know it, and build native single-file executables using AoT.
Sort of uncurious about your implementation, but very curious regarding your trauma. I have found a lot of the OSS options for RADIUS suck in specific ways. Never had to scale it however.
The two are linked. Need to change the configuration of a fleet? That's going to be restarting every instance of the process. Update an extension model? Same. Load balance? You'll need one that understand RADIUS or clients will suffer because of incorrect session affinity. Client with dramatically different loads? Better put them on different clusters. Somebody had a power outage? Better have 10x capacity on hot standby for the load.
And on and on.
A stateless compute model with separation between the packet handling and the authentication logic solves pretty-much all of it.
I was responsible for multiple RADIUS services used by millions of people every day. The existing software is slow to build with, difficult to scale and expensive. I couldn't let it go.
Step one was building the platform to run it on and make it sustainable as a business. Step two is implementing protocols like RADIUS that lack a separated compute/storage model but should really have one.
I chose C# because I know it, and build native single-file executables using AoT.