On 17 May 2016 at 15:10, André Warnier <a...@ice-sa.com> wrote: > On 17.05.2016 14:11, Vincent Veyron wrote: >> >> On Tue, 17 May 2016 10:16:43 +0200 >> André Warnier <a...@ice-sa.com> wrote: >>> >>> >>> I don't see above any signifiant difference in configuration between the >>> servers, apart >>> from the fact that the "faulty" server runs a 64-bit version of perl. >> >> >> Sorry : slightly digressive rant about the fact that every time I compare >> my configs, I find some subtle differences. Should be getting into config >> management tools, but that takes time too. >> >>> >>> Now I also found this : >>> http://rabexc.org/posts/randomizing-should-be-easy-right-oh >>> >>> I am not sure that I really understand this all the way down, but would >>> this not be a >>> suspect in a case where the behaviour seems different between one 64-bit >>> machine, and a >>> bunch of 32-bit ones ? >> >> >> Nope; same results on both types when running the script >> >>> >>> This being said, it still looks to me as if the current code is flawed on >>> *all* machines, >>> and *will* repeat keys quite often. It just depends again on the exact >>> sequence of >>> requests hitting a specific Apache, and the other parameters I mentioned >>> before. >>> I still believe that the fact that it does not *seem* to happen, is just >>> due to the >>> inherent randomness of these other factors on the production machines. >>> >> >> Well, I already posted a test with ab and 12 000 requests, so not sure >> about the 'quite often' part? >> >> This is on the faulty one : >> >> xxxx@arsene:~$ perl -le '%h=();for (1..10_000_000) {my $session_id = join >> "", map +(0..9,"a".."z","A".."Z")[rand(10+26*2)], >> 1..32;$h{$session_id}=1};$v=keys %h; print $v' >> 10000000 >> >> [SNIP] > And this "disorder" will tend to be larger, the more loaded is that server. > So over any given period of time, each child will tend to be at a different > stage in his rand() calls. And the risk of having the same key being > returned to 2 clients at about the same time, is relatively low. > But if the keys are stored somewhere in a persistent way, you are increasing > the risk greatly, because key #13 generated by a new child today, may > conflict with the key #13 generated by another child yesterday. > > (*) or start an additional child >
a very simple solution to this problem is to put the time in the string eg: my $token= pack "LC*", time, map int rand 256, 1..$number_of_bytes_in_token; then just hex encode or base64 encode the string. Doing it this way also probably massively faster (done right) than the approaches i have seen mentioned in this thread. pack is *fast*. Note the chance that two drand48 states are the same at the same time, is really really low if sranded properly. Essentially zero. Yves Yves -- perl -Mre=debug -e "/just|another|perl|hacker/"
