Past trauma motivated 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.

▲

protocolture 7 hours ago | parent | next [-]

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.

	▲	mlhpdx 6 hours ago \| parent [-]
		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.

▲

MaKey 10 hours ago | parent | prev [-]

So you are looking to offer a managed RADIUS server once you've finished building the software?

	▲	mlhpdx 6 hours ago \| parent [-]
		Maybe. I'm thinking about options but haven't decided on anything yet.