Proxying accounting to create a 'tee'

[Arran Cudbard-Bell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 24/08/2009 13:56, Alan DeKok wrote:
> Arran Cudbard-Bell wrote:
>> No, that'll get you the timestamp of when the packet was read back into the server. The only way to calculate the original received timestamp is to write the original Acct-Delay-Time into a custom
>> attribute (say Acct-Delay-Time-Orig), subtract that from the current Acct-Delay-Time, then that from the current UNIX timestamp.
> 
>   The detail file reader creates/updates the Acct-Delay-Time based on
> how long the packet has been sitting in the "detail" file.  There's no
> need to update it manually.

I wasn't suggesting that. I was suggesting a way of getting the Packet-Original-Timestamp is a usable form.

>> Yeah it's a pretty common setup, we do it too. One thing you have to watch out for is  packets with fatal errors. Where the remote accounting server never acknowledged receipt of the packet, so it
>> gets stuck in an infinite loop in the proxying queue.
>>
>> I haven't figured out how to solve this properly with the current setup, so it'd be good to see some discussion on list about it.
> 
>   Hmm... it should continue sending a packet from the detail file until
> the upstream server has responded.  It shouldn't write packets to the
> detail file if they've been read from the detail file.
> 

It doesn't. But they're only removed from the detail file if the server actually responded. Some usernames are permenantly unroutable for accounting requests. i.e. their home accounting server just
doesn't accept the Accounting-Requests and never send Accounting-Responses.

Ideally there'd be a mechanism to remove Accounting-Requests after X number of attempts at proxying. At the moment were using a request expiry time based on the length of the period between the
request being received and it being proxied.

i.e 'This request has been in the Queue for X seconds, X seconds is longer than our expiry time, remove packet from queue'

This is a *horrible horrible* hacky work around, because if a bunch of requests are received around the same time, and one is 'unroutable' then all the packets received around that time will be dropped.

If you don't do this, then the unproxyable packet stays at the head of the queue and blocks all the requests behind it.

Arran
- -- 
Arran Cudbard-Bell <A.Cudbard-Bell at sussex.ac.uk>,
Systems Administrator (AAA),
Infrastructure Services (IT Services),
E1-1-08, Engineering 1, University Of Sussex, Brighton, BN1 9QT
DDI+FAX: +44 1273 873900 | INT: 3900
GPG: 86FF A285 1AA1 EE40 D228 7C2E 71A9 25BB 1E68 54A2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkqTtpsACgkQcaklux5oVKJxcgCbBqY/nEHORyplNym1jNSPOAtU
9VIAnRG64wVCOkGmLxPlF+zR5T3Ejt7y
=cIre
-----END PGP SIGNATURE-----