Alan DeKok <[log in to unmask]> wrote
Tue, 01 Mar 2011 16:09:49 +0100:
| > 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.
Yes, thanks. I should have made clear that I'm being sloppy (and TCP
centric) here by talking about connection timeouts as if they are
something to consider at all times.
| 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.
Ok. There are other reasons for renaming and separating the three
timeouts as well. One is that these are low level timeouts needed for
servers and proxies while clients using the struct request object of
libradsec probably would like a single timeout spanning the whole
connect + send + receive sequence. The 'timeout' keyword in a 'server'
stanza should probably be reserved for such a high level timer.
| 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.
I haven't touched on retransmissions when on UDP yet. I should've made
that clear from the beginning. My hopes are that the library can handle
retransmission without the need for the application to know about it.
We'll see how this works out when I come to UDP.
|