not logged in | [Login]
The application layer is responsible for all protocol-specific processing. It is entirely unaware of any IO related issues. It exposes the following API.
*We may not need the
fr_application_t, as the unlang is cached in
CONF_SECTION, and the processing is entirely dependent on the
state machine, and the
The application layer (i.e. worker thread) receives messages from the transport layer (i.e. network thread) via the (message API)[message]. The process is reversed when sending messages.
CONF_SECTION * and returns a
fr_application_t *. It
defines the various things necessary in phase 1 bootstrap.
Note that the current server core can't deal with this. The listeners are created / parsed at awkward moments due to legacy design.
fr_application_t *, and returns
(0/-1). Compiles any necessary
REQUEST *, and prints debugging information about the
request, to the request debug context.
The function to call when processing a
REQUEST * and and
rlm_rcode_t. It presumes that there is an event list in
request->el. All events for the request are added to the event
Do we need to take an
fr_application_t here? Or instead of
process, do we have a
Last edited by Arran Cudbard-Bell, 2018-06-13 22:51:48
Sponsored by Network RADIUS