Peter Nixon wrote:
There's also a Post-Proxy-Type Fail. It gets run when the server discovers that there are no live home servers for a request. This happens in the child thread when it's proxying, if all are dead. If the main thread receives a retransmit, and notices that all of the home servers are dead, it runs the request through Post-Proxy-Type Fail.... in a child thread.
I assume that this can be used to write an accounting detail file (to be sent later with radrelay) only when proxying fails... Cool stuff!!
I looked. Unfortunately, no. The detail module expects to log the reply from the proxy when it gets called in the post-proxy stage. That needs to be fixed. Also, the detail file reading code in the server core needs to be fixed in a number of ways. - track which packet has been sent where. i.e. 1k packets in the "detail" file, and the server dies before reaching the end. When it re-starts, does it just re-sent all of the 1k packets again? Or should it try to be smarter, and only re-send the ones that didn't get a reply? If so, how does it track the replies? - do not read the detail file until all other sockets have been processed, and all other internal queues are empty (i.e. queue of packets read from proxy sockets, auth/acct, etc.), and until there is at least one idle thread The detail file is already a queue. Reading packets from it, and adding them to a queue in the server core is sort of pointless. - add back pressure if more than N packets have been read from the detail file and are being processed, don't read more until we get a response. The code already has some support for this, but I'm not sure how well it works. It may do busy polling, which isn't nice. What it really needs is the ability to remove the detail file FD from the list of FD's passed to 'select', so that the file isn't looked at until the server knows it can process more packets. Then, select has to be poked (maybe via a pipe?) so that select returns, and can process more requests from the detail file - add retransmits from the detail file If there isn't a response in N seconds, update the request with Acct-Delay-Time, and send it again. The new event loop in the server core now guarantees that the detail_send() function gets called on successful packets, and on ones that don't get responses. That function can take care of marking the request as "to re-send". With a bit more work, it can also perhaps wake up the select() function... somehow. I'd also like to add file globbing to the detail file reader. It would be an easy way to have radrelay functionality for N detail files, with only one configuration entry. For that, it should open the files starting with the oldest mtime, I think. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog