The problem of the accounting log becoming congested with checkpoint
records could be solved in a number of ways. Hmm. How about this:
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.
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.
The accounting server would have to clear out the in-progress directory
upon startup. This would prevent it from being able to recover from a
crash of it's own but would be needed as I can't think of any foolproof
way for the server to determine if the calls are still in progress or if
they've already ended. Besides, aren't the client's supposed to buffer
accounting data if the server goes away...?
The advantage of this is that it would be completely transparent to
whatever existing mechanisms are used to process the accounting log. The
penalty for a short checkpoint time would be network bandwidth and disk
accesses on the accounting server.
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. :-)