radius async support

[ionutrazvanionita]

This patch is trying to provide asynchronous authentification and accounting support for freeRADIUS client library. Since RADIUS is sometimes used in conjonction with tools that
process thousands of packets per second (like SIP proxies for example), asynchronous operations are needed to get rid, as much as possible, from any wait situation which can be fatal at such packets per second rates. Since RADIUS client does not provide such capabilities, we decided that the effort we could have put in developing these features would be far outweighed by the improvements that they could bring to us.
Our application provides a reactor which receives open file descriptors and resume functions, and calls the resume function when the socket is readable. So what we need from RADIUS library was to provide the socket just after the send operation and a resume function to be called when data can be received.
We split rc_aaa function in two rc_aaa_async and rc_aaa_receive so that we can put a reactor in the middle. In order to keep all the parameters we defined a struct called SEND_CONTEXT which contains everything needed for the resume function. Also the socket file descriptor ( sockfd ) is being held inside this structure. Blocking send and receive has been completely removed from the library. If one sends a packet to a server and it does not respond, it is the job of the upper layer application to do this, in order to avoid blocking the process from inside the library. If, by any reason, the server does not respond, the upper layer application can detect this and call the library function again with the SEND_CONTEXT structure that has been returned by the first call. Since we split the rc_aaa function we also needed to split rc_sendserver function. Also, all the parameters used by rc_send_server are being held in SEND_CONTEXT structure.
If rc_aaa_async function was successful, OK_RC and NOT NULL SEND_CONTEXT is returned to the user, else ERROR_RC is returned and NULL SEND_CONTEXT, since no destination responded to our send tries.
rc_aaa_async can also be called with a NOT NULL SEND_CONTEXT meaning that you want to try another destination, since the current one did not respond. The behaviour will be as above, but this time not all destinations shall be tried, only the ones after the current one.
In order to implement asynchronous receive, we needed to define a new return code to signal EWOULDBLOCK/EAGAIN errno’s. We called this return code READBLOCK_RC and it has the identification integer number 3. Else, if receive was successful, OK_RC and NULL SEND_CONTEXT is returned from the library.

From outside the library, rc_acct_async and rc_auth_async functions can be used to try send the message and rc_acct_resume and rc_auth_resume to resume receiving the server response RADIUS message.

[fxdupont]

If you are interested I have 2 bug fixes and a feature request about this PR.
(Please answer at [email protected])

[alandekok]

I'm interested in bug fixes and features. The best way to discuss this is to open a new PR and/or github issue

…

On Mar 5, 2018, at 12:11 PM, fxdupont ***@***.***> wrote: If you are interested I have 2 bug fixes and a feature request about this PR. (Please answer at ***@***.***) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[fxdupont]

I don't know (yet) how to pull a request or open an issue about a PR itself.
Testing a config with 2 acct servers and asynchronous support I got two problems:

• NULL adt_vp is deferred because it is not correctly cached in the context.
• once the first bug was fixed I ran in a second one where type (acct vs auth) was not cached in the context. IMHO you get this problem with at least two servers and different secrets between authentication and accounting services.

Both are in 6982454..7e1515b in https://github.com/fxdupont/freeradius-client.git fork iscdev branch.

The feature request (low priority as repeating a server config simulates it) is to add in the asynchronous support the retry (current code goes to the next server instead to retry the current one).