Arran Cudbard-Bell wrote:
Ok just the asynchronous nature of CoA requests... It's not really the servers job to process feedback from the various SNMP probes, IDS's , or track changes in the authorisation of users or their equipment.
Yes. That's what proxying is for.
I guess I can see very few usage cases for CoA where the server will actually make the decision to send a CoA request on it's own, so why not just use the client or client libraries ?
if user uses more than 2G of bandwidth, then kick them off. This is a valid decision for a server to make. Forking an external program means that it's independent of the server core, and is more difficult to integrate with SQL, etc.
How were you thinking of triggering CoA events? Didn't you say there were issues with an instance of the server being both a CoA proxy and a CoA generator ?
Yes. If you're going to proxy CoA requests, there's no need to *generate* a CoA request for the one you're proxying. On the other hand, if you're receiving an accounting request, it may make sense to generate a CoA request.
Have to wait for vendor support *grumble*.
Let me know when you get your trapeze kit so we can compare notes :)
Will do. Alan DeKok.