Andrej <[email protected]> writes: > On 26 October 2011 04:48, Bjørn Mork <[email protected]> wrote: >>> If the server is too slow to process requests, the kernel will throw >>> away the UDP packets. This happens when the server is slow... whether >>> it's threaded or not. > >> But then the client won't get the acks and retransmit. If I understood >> correctly, then the problem is the packets *are* acked but not logged. > > Maybe my whole understanding of UDP is flawed, I thought the whole > point of using UDP instead of TCP is not to have ACKS and retransmits?
Not nessarily. The point is that UDP leaves that up to the application. For RADIUS accounting this is described in http://tools.ietf.org/html/rfc2866#section-2 <quote> It is recommended that the client continue attempting to send the Accounting-Request packet until it receives an acknowledgement, using some form of backoff. If no response is returned within a length of time, the request is re- sent a number of times. The client can also forward requests to an alternate server or servers in the event that the primary server is down or unreachable. An alternate server can be used either after a number of tries to the primary server fail, or in a round-robin fashion. Retry and fallback algorithms are the topic of current research and are not specified in detail in this document. </quote> I don't know if all clients follow this recommendation, but a lot of them do. Bjørn - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
