i2p.i2p-bote icon indicating copy to clipboard operation
i2p.i2p-bote copied to clipboard

Randomize check interval (and maybe other cronjobs) (Trac #1360)

Open str4d opened this issue 7 years ago • 7 comments

trivial.

The intervall for automatic mail checking should be taken as a guideline, not as exact time. Rather should the exact checking time be more random, so to add more entropy.

Migrated from https://trac.i2p2.de/ticket/1360

{
    "status": "assigned", 
    "changetime": "2017-01-15T14:08:34", 
    "description": "trivial.\n\nThe intervall for automatic mail checking should be taken as a guideline, not as exact time. Rather should the exact checking time be more random, so to add more entropy.", 
    "reporter": "user", 
    "cc": "", 
    "resolution": "", 
    "_ts": "1484489314604199", 
    "component": "apps/plugins", 
    "summary": "I2P-Bote, randomize check interval (and maybe other cronjobs)", 
    "priority": "minor", 
    "keywords": "I2P-Bote privacy", 
    "version": "0.9.14.1", 
    "parents": "1359", 
    "time": "2014-08-26T09:34:36", 
    "milestone": "eventually", 
    "owner": "str4d", 
    "type": "enhancement"
}

str4d avatar Apr 16 '17 23:04 str4d

Trac update at 20140826T09:38:08:

  • user changed _comment0 from "to clarify: not a fixed intervall should be chosen at random, but the contrete time for each individual mail check be chosen randomly (uniform distribution)." to "1409046069493917"
  • user commented:

to clarify: not a fixed intervall should be chosen at random, but the concrete time for each individual mail check be chosen randomly (uniform distribution).

str4d avatar Apr 17 '17 00:04 str4d

Trac update at 20140826T09:50:45: user changed parents from "" to "1359"

str4d avatar Apr 17 '17 00:04 str4d

Trac update at 20150110T04:16:56:

  • str4d changed keywords from "" to "I2P-Bote privacy"
  • str4d changed milestone from "0.9.16" to ""

str4d avatar Apr 17 '17 00:04 str4d

Trac update at 20150205T04:26:01:

  • str4d commented:

A comment from [ticket:1450 rfree]:

( I offer small tip of 0.01 Bitcoin - so a beer at current prices - for who ever implements this, e.g. from https://blockchain.info/address/152fnfBqRjVMDvRa5LQ2upx9tJAeHnyqHC )

A few details about delay of "cronjobs" - especially the "check email" action: For each account, where T is the configured time of action, e.g. 10 minutes for "check email each 10 minutes": and L option: Sometimes pretend to be offline for up to .... hours to make others confused about when your computer is online.

  1. At start, job should delay random(T0 to T2)
  2. After running the check, job should schedule next run, to be randomly between time from now sleeptime = random(T0.5 to T1.5) if random(0..100) is < 30 then sleeptime += randomGauss(0 to L/5) if random(0..100) is < 10 then sleeptime += randomGauss(0 to L)

choose the scheduled time: ID.nextrun = now() + sleeptime

It is a good idea to look at the possibility of randomizing other cronjobs, if they are visibly tied to an identity.

  • str4d changed milestone from "" to "eventually"
  • str4d changed summary from "I2P-Bote, randomize check interval" to "I2P-Bote, randomize check interval (and maybe other cronjobs)"

str4d avatar Apr 17 '17 00:04 str4d

Trac update at 20150216T20:14:20:

  • user changed _comment0 from:

i'd like the option to manually set the intervall from which to draw the actual wait time randomly. But i also see the convenience of just putting one approximate time. So what about this compromise: for what abouve you call sleeptime, and previously was called checkintervall, either let the user specify an intervall [min,max] in the config files. in the UI, however, just prompt for one value T for check intervall and set min:=T*(1-x) and max:=T*(1+x). whether x should equal 0.5 or not is up to debate. Then casual user has it easy, and advanced user can adjust it to his likings without recompiling source. This calculation is only performed on saving this very setting from the ui. otherwise it only readys the two values from config and displays the mean average of them. Or always show two values in UI, then it could be average wait time and spread (x). Again default vlaue of x to be determined. unit distribution, not gauss. wrt the above mentioned L feature: I don't desperately need it. but if you do it, nice. should imho be off / set to 0 by default thought, in order not to delay things too much for users that expect some quicker workings. but then rather coose an offline duration and a "timezone" and simply gauß the period

to:

1426365611893046

  • user changed _comment1 from:

I'd like the option to manually set the intervall from which to draw the actual {{{waitTime}}} randomly. But I also see the convenience of just putting one approximate time. So what about this compromise: For what above you call sleeptime, and previously was called checkintervall, either let the user specify either an intervall [ {{{min}}},{{{max}}}] or one value {{{checkIntervall}}} for check intervall and a randomization/spread factor {{{factor}}}. Either way, you can transform them. (With user-set {{{min}}} and {{{max}}} values, you obtain {{{factor}}} from {{{factor := (max-min)/(max+min)}}} and {{{checkInterval := (max+min)/2}}} This calculation is only performed on saving this very setting from the ui. Otherwise it only reads the two needed values {{{checkIntervall}}} and {{{factor}}} from the config file.)

For determining the next check time you first obtain two values {{{helpFactor1}}} and {{{helpFactor2}}} of a Gaussian random variable centered around the randomization factor {{{factor}}} independently from one another, set {{{finalMin := (1-helpFactor1)*checkInterval}}} and {{{finalMax := (1+helpFactor2)*checkInterval}}} (both helpFactors can be discarded now) (Assert that {{{finalMin <= finalMax}}}) Then choose {{{waitTime}}} from a uniform distribution between {{{[finalMin, finalMax]}}}. (both values can be discarded now) Finally, you get the {{{scheduledTime = timeOfLastCheck + waitTime}}}.

This does not yet take the L option rfree mentions into account.

Heck, if you want, you can even provide both options and let the user choose which input method is more intuitive for him, giving the average and a randomization factor, or giving min and max.

And the very same calculations can be used to determine the exact wait time per relay which is sent to the respective Bote relay node.

Default vlaues to be determined.

wrt the above mentioned L feature: I don't desperately need it. but if you do it, nice. Should imho be off / set to 0 by default thought, in order not to delay things too much for users that expect some quicker workings. but then rather choose an offline duration and a "timezone" and simply gauß the period.

to:

1426365706654267

  • user commented:

I'd like the option to manually set the intervall from which to draw the actual waitTime randomly. But I also see the convenience of just putting one approximate time. So what about this compromise: For what above you call sleeptime, and previously was called checkintervall, either let the user specify either an intervall [ min,max] or one value checkIntervall for check intervall and a randomization/spread factor factor. Either way, you can transform them. (With user-set min and max values, you obtain factor from factor := (max-min)/(max+min) and checkInterval := (max+min)/2 This calculation is only performed on saving this very setting from the ui. Otherwise it only reads the two needed values checkIntervall and factor from the config file.)

For determining the next check time you first obtain two values helpFactor1 and helpFactor2 of a Gaussian random variable centered around the randomization factor factor independently from one another, set finalMin := (1-helpFactor1/100.0)*checkInterval and finalMax := (1+helpFactor2/100.0)*checkInterval (both helpFactors can be discarded now) (Assert that finalMin <= finalMax) Then choose waitTime from a uniform distribution between [finalMin, finalMax]. (both values can be discarded now) Finally, you get the scheduledTime = timeOfLastCheck + waitTime.

This does not yet take the L option rfree mentions into account.

Heck, if you want, you can even provide both options and let the user choose which input method is more intuitive for him, giving the average and a randomization factor, or giving min and max.

And the very same calculations can be used to determine the exact wait time per relay which is sent to the respective Bote relay node.

Default vlaues to be determined.

wrt the above mentioned L feature: I don't desperately need it. but if you do it, nice. Should imho be off / set to 0 by default thought, in order not to delay things too much for users that expect some quicker workings. but then rather choose an offline duration and a "timezone" and simply gauß the period.

str4d avatar Apr 17 '17 00:04 str4d

Trac update at 20150216T20:36:48: user commented:

just saw #40, yes, something like that is what I vaguely had in mind. But then the L thing here above is onbsolete, or what is it for? Or is the L independed of timezone just a ramdom "computer switched off"?

str4d avatar Apr 17 '17 00:04 str4d

Trac update at 20170115T14:08:34:

  • zzz changed owner from "HungryHobo" to "str4d"
  • zzz changed status from "new" to "assigned"

str4d avatar Apr 17 '17 00:04 str4d