Recent changes

[Alan DeKok]

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