>>>>> "Josh" == Josh Howlett <[log in to unmask]> writes:
>> > What's the sockets based solution?
>>
>> I can’t remember who suggested it, but the gist of it was that
>> FreeRADIUS could output attributes via a unix socket in a
>> documented format.
Josh> News to me, but this sounds like an interesting approach. I
Josh> have no idea about Python and the practicalities of using its
Josh> interpreter, but could we not have a Python process, building
Josh> on the existing integration work, that attaches to this socket
Josh> and processes requests as they arrive?
we could except that the socket does not yet exist.
So, the web world has worked with this disconnect between the app server
and the web server. It's necessary in part because web requests and
responses are relatively big and because you want to have a different
number of threads processing IO than you do interacting with CPU-bound
or database-bound tasks.
However getting things like wsgi, fastcgi, speedycgi, rack, etc
developed has been non-trivial.
And yes, that level of complexity is generally necessary for decoupling
app logic from web servers.
RADIUS doesn't seem to have the same factors arguing for the app server
split. The requests are small, the OS is going to do a relatively good
job of handling the IO on its own, there's already a good event loop for
splitting out the read/write cycle.
It's going to be tempting to come up with some relatively simple socket
approach. However, request multiplexing, multiple worker threads, etc,
etc are all required.
Eventually, when you get a solid socket protocol, solid libraries for
the app server side, and a solid implementation in the RADIUS server,
this will work well.
However, it's not obvious to me that path is shorter than clean
in-process interpreter bindings.
--Sam
|