>
>Checkpointing of calls is an excellent idea. I was going to suggest it
>myself but never got around to it. :-)
>
>The problem of the accounting log becoming congested with checkpoint
>records could be solved in a number of ways. Hmm. How about this:
Why have checkpoint records even go into the checkpoint log? I mean, I
suppose you can leave it optional to log them, but they're really only
needed if the portmaster crashes.
Just have the accounting daemon store them up. If it crashes and reboots,
it'll just get the next checkpoint packet that shows up. If it crashes
at the same time that the portmaster crashes, you've got some major
problems anyway -- the only way I can see that happening is via massive power
outage or something similarly disastrous.
>Instead of saving the newly arrived checkpoint record in the usual log,
>what if it were saved in a file in an in-progress directory, named after
>the session-id. A new checkpoint record would completely replace the old
>information. The checkpoint file would be unlinked when the stop record
>arrived.
Thats a decent idea too -- keep last checkpoints on disk, and have boot-up
process them into the accounting daemon/logs.
>If the associated terminal server rebooted (is there a bulletproof way to
>detect this? Other than snooping syslog UDP traffic.. :-) it's
>in-progress checkpoints would be logged as stop records and then unlinked.
Well, if you're messing with the radius accounting protocol, you include
logging system bootups to the accounting server in the modified protocol.
:-)
>Does this sound workable or is there something stupid here that I'm
>missing? Of course, convincing Livingston to add the checkpoint feature
>might not be easy. :-)
>
There's the stumbling block!
Eric Mehlhaff, mehlhaff@crl.com