Reason I don't like 2048 is, 34.13333 minutes, why why why.
Should it not be 2047 or 2049?  *cough*   What's going on is here, is
it should be 3600 - the maximum plausible runtime.  But I'm still not
thrilled changing the value there on it's own either.

rpki-client itself shold probably self-protect to cope with 'long runtime',
or lockups.

This framework is simple, and probably too simple.  In an large
userbase, I suspect it becomes likely someone will eventually hit a
multi-hour routing glitch, which will reuslt in multiple rpki-client
stuck doing DNS resolution (and failing DNS resolutions, so they end up
at different stages of syncronization) and partial downloads.  The cache
directory will be inconsistant.  Then I think the multiple processes
will all complete as a thundering horde.  The file generation is
designed to be atomic, but the parallel completion computation might be
a problem.

I think we should consider building some sort of self-watchdog mode
into the rpki-client frontend.

Reply via email to