Child is hung (max_request)

[Arran Cudbard-Bell]

> On 24 Nov 2014, at 10:05, Iliya Peregoudov <iperegudov at cboss.ru> wrote:
> 
> On 24.11.2014 16:14, Alan DeKok wrote:
>> Iliya Peregoudov wrote:
>>> Your radius-diameter-translator module should listen RADIUS protocol on
>>> UDP/4013 port. Translator should implement RADIUS server (receive
>>> requests, send responses) and Diameter client (send requests, receive
>>> answers). Flow diagram is following:
>> 
>>   i.e. he needs to implement a RADIUS proxy.  Just like FreeRADIUS.
>> 
>>   Take it from me, that's a lot of work.  Anyone who asks for design
>> diagrams on how to implement a RADIUS server has about 5 years of
>> full-time work ahead of them.
> 
> There is nothing inherently sophisticated in the RADIUS protocol itself. Implementing a RADIUS-to-Diameter translator is not inherently harder than implementing anything-else-to-Diameter translator.
> 
> Topic starter has already implemented something-else-to-Diameter translator as a standalone process. To integrate it with RADIUS he has to implement RADIUS-to-something-else translator as a freeradius module, and this module does not work well.
> 
> The problem with freeradius is that it was not designed to be used as extensible protocol translator. One cannot write a freeradius module that will translate RADIUS to any other protocol in non-blocking manner because freeradius module interface is blocking. So mentioned earlier freeradius module *can not* work well.

Yep FreeRADIUS ends up being completely synchronous so you can only have max workers packets in flight
at the same time.

The protocol translator is the direction we want to take the project though. It ensures that FreeRADIUS
will continue to be useful even if the RADIUS protocol itself loses popularity.

Arran Cudbard-Bell <a.cudbardb at freeradius.org>
FreeRADIUS development team

FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2