From: Alan T. DeKok Date: Thu, 10 Aug 2017 09:21:02 +0000 (+0200) Subject: most recent notes X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=8b1fee0a85e2dd58a27e606b2f4fd37553b3bd14;p=thirdparty%2Ffreeradius-server.git most recent notes --- diff --git a/src/modules/rlm_radius/TODO.md b/src/modules/rlm_radius/TODO.md index 50cf0f77108..c594a450e08 100644 --- a/src/modules/rlm_radius/TODO.md +++ b/src/modules/rlm_radius/TODO.md @@ -1,18 +1,5 @@ # rlm_radius -## daemon mode bugs - -in daemon mode, it doesn't seem to send the reply until IRT has passed??? - -channel.c is suppressing the worker signal... - -but it works in debug mode which is only 1 thread... -so there is some weird threading interaction issue... - -- add debug / fprintf output in rlm_radius_udp to see WTF is going on... - -- it's like the response packet is ignored? - ## Multiple connections We probably don't want to load-balance across connections via @@ -22,60 +9,43 @@ just use the "most lively" connection. Which should do automatic load-balancing. i.e. if it JUST responded to us, it's probably ready to take another packet. -The "full" connections should be on a *separate* heap, or maybe a -`fr_dlist_t`. The extract / insert connection work needs to be done -in it's own function, because it's mostly magic, and needs to be done -in multiple places. - -We need to track: - -* connection state: connecting, live, full, zombie, dead -* connecting = trying, but not yet open -* live connections which have IDs available -* live connections which are "full" - * either no more IDs, or we've seen EWOULDBLOCK - * these don't have packets sent to them -* zombie connections - * these don't have packets sent to them - * they have Status-Server checks done - * they are moved to "live" if we get 3 responses to Status-Server - * they are moved to "live" if we get a response to a previously proxied request -* dead connections are closed - -We need some more configuration options: - - # per-connection limits - connection { - # this is a per-thread limit. Oops. - max_connections - connect_timeout - reconnect_delay - idle_timeout - - # as per 3.0 - # no response_window, that's handled by IRT, MRC, MRD, MRT. - # no "response_timeouts, either. - # instead, we just immediately go to zombie on MRT. - zombie_period - - # response_window && response_timeouts are for synchronous - # proxying... - revive_interval - } - - # return RLM_MODULE_USERLOCK if we're sitting on too many packets - # note that this is a per-thread limit. Sorry about that. - max_packets = 65536 +We don't want "revive_interval", as (unlike v3) outgoing sockets are +connected. When a connection fails, we rely on the underlying +connection state machine to try re-opening the connection. + +... but only if we don't have Status-Server pings +(i.e. application-layer watchdog). If we have that, then + + +The `rlm_radius` module should not have an idea as to the status of +the server, across multiple connections. i.e. each connection is +handled separately. That is because especially for TCP, one +connection can be dropped by a firewall, but another one can be fine. +So it should just treat each connection independently. + +### What works + +Connection states are: + +* opening - connecting to the other end +* active - available for new requests +* full - no more IDs available on this connection +* zombie - has received MRC / MRT / MRD timeouts + * TODO: we should start pinging as soon as a connection is zombie + +### Limits + +* limit the maximum number of proxied packets +* limit the maximum number of outgoing connections + +Both will likely require atomic variables in rlm_radius.c + +### Status Checks status_checks { - type = Status-Server # or NONE + type = Status-Server # mrt, irt, mrc taken from another section, as per Access-Request, etc. - num_answers_to_alive - # check_interval and check_timeout are no longer relevant - # we just use MRT, IRT, etc. if the response doesn't come - # by the time we're sending the next packet, it's a timeout. - # update the Status-Server packet here??? # probably no need for a separate virtual server... # i.e. no policies @@ -87,30 +57,6 @@ We need some more configuration options: } } -The `rlm_radius` module should not have an idea as to the status of -the server, across multiple connections. i.e. each connection is -handled separately. That is because especially for TCP, one -connection can be dropped by a firewall, but another one can be fine. -So it should just treat each connection independently. - -The module should also track the state of multiple connections: - -* connecting (all connections are connecting) -* live (one or more connection is live) -* full (all connections are full) - * this should probably just return to the connecting state, - * unless it hits max_connections -* zombie (all connections are zombie) -* dead (all connections are dead) - * this should probably just return it to the connecting state. - -## Connection status management - -Mark a connection live / dead / zombie based on packet retransmission -timers. Do Status-Server checks as necessary. - -## status_check - add status_check = Status-Server or Access-Request, ala old code The main issue here is the ID allocation... If this is set, then we @@ -124,6 +70,8 @@ Accounting-Request. ## synchronous proxying +much lower priority, as it requires other changes to the core + ala v3. All retransmissions started by the client. This requires a "signal" handler to be added when the module calls @@ -152,3 +100,10 @@ which means "no tracking", as that will likely be the common case. * Check on packet lifetime timers in network side? i.e. cleanup_delay, Double-check that they work... + +* double-check ENABLE_SKIPS in src/lib/io/channel.c + +We should move to a "must_signal" approach, as with the network side +The worker should suppress signals if it sees that the ACKs from the +other end haven't caught up to it's sent packets. Otherwise, it must +signal.