Update Scheme (feature request from nitrox)

• move current update-scheme and make it an option ala UseOldUpdateScheme^? yes/no.

idea of future update-scheme:

• remove todays user-settings (e.g. -c ##), but make them work if the above UseOldUpdateScheme^? option is set
• on fc startup check if dns is working (e.g. compare local time to timetag from dns, or maybe there is a method to definetively tell its working or not) -- LG says it already does
• if ttl is not as expected, revert to old http-method (lets say every 1 or 2 hours) -- LG says it already does
• take ttl from dns and use this value to let fc check for updates (currently 900) -- LG thinks that it's not really needed. Users can run freshclam as often as they like. We want to set an upper limit on the number of checks, not a lower limit! The current setup already implements this.
• if scripted updates do not work and fc is downloading cvd's instead of cdiff's, punish him with an extra time of e.g. 3600+ttl (3600+ttl gives you sort of more randomness) for next possible update

advantages

• clam-team gains back a certain control on when updates will happen (can control interval via dns)
• clam-team can set a longer interval when bigger updates / release of a new main is planned (setting ttl to 3600 would give you the control to handle the load on the mirrors not within 15 mins but in 60 mins) -- LG says this can be already done, we do not need to modify freshclam for this.
• ttl is more or less user-specific, or dns-server specific as it starts counting backwards from e.g. 900 after first request/answer to your dns - so its not hammering the mirrors all-at-once e.g. at full hours -- LG says this is how it currently works
• limit max ttl to e.g. 86400, if sth. goes terribly wrong on dns-configure (just to prevent fc falling asleep for weeks :))
• users are not really out-of-date on main-updates and a larger ttl interval, as most updates of main are simple copy&paste from daily -> main
• ...

cons.

• needs good dns-infrastructure -- LG says we have 7 dns servers
• carefull changes to ttl
• ensure that all dns-servers get updated ttl's
• much work
• ...

other suggestions (edwin)

• add randomness to update time (but keep minimum above TTL at all times) -- LG: why?
• recovery from unreachable network (if network was unreachable, how often should we check net reachability?)
• refuse very low TTL values
• keep statistics on the update interval, and update times, for local sysadmin's use -- LG: freshclam.log has got everything
• (mirrors could tell preference of update interval/available bandwidth based on load. Freshclam could then pick mirror with lowest update interval/load, highest bandwidth). [hard to implement, not many benefits.]

-- TorokEdwin - 12 Mar 2007

</center-->