Linus Nordberg wrote:
> ** Timeouts
> When using libradsec in blocking mode, i.e. when the library does the
> dispatching by running the event loop for the user, the timeout
> handling works as described in this section.

  That's for *connection* timeouts.  For packet retransmissions, see the
following.

  For UDP:

http://www.ietf.org/rfc/rfc5080.txt

  See Section 2.2.1.

  For TCP:

http://tools.ietf.org/id/draft-dekok-radext-tcp-transport-01.txt

  I would rename the value "connection_timeout", to make it clear that
it's independent of other retransmission timers.  I would also separate
it from the send/receive sequence.

> Only one single timeout value is being used, configured using the
> `timeout' configuration option.  This value is used as the timeout
> value, in seconds, on each of the operations connect, write and read.
> One effect of this is that with a configured timeout value of T, a
> complete connect+send+receive sequence can take up to 3*T seconds to
> finish without the timeout firing.

  The connection timeout *must* be independent of all of the other
timers.  A send/receive sequence has it's own timer, defined by RFC 5080
(UDP) or RFC 3539 (TCP).

> When using libradsec in non-blocking mode the only connect timeout is
> in effecxt.  TODO: Explain why.

  The library should notify the application when a retransmission is
desired.

  Please don't invent new retransmission methods.  The RFCs already
define retransmission timers, which work very well in practice.

  See the FreeRADIUS code (src/main/event.c) for some ~20 lines of code
which implements the retransmission time calculations.

  Alan DeKok.