Why RADIUS and not DIAMETER, the successor?
replyWhat motivated you to start this and which language did you choose?
replyPast trauma motivated it.
replyI 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.
replyThe 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.
replyAnd on and on.
A stateless compute model with separation between the packet handling and the authentication logic solves pretty-much all of it.
So you are looking to offer a managed RADIUS server once you've finished building the software?
replyMaybe. I'm thinking about options but haven't decided on anything yet.
reply