TID: FMail-lnx64 2.1.0.18-B20170815
RFC-X-No-Archive: Yes
TZUTC: 0200
CHRS: UTF-8 2
PID: GED+LNX 1.1.5-b20161221
MSGID: 2:280/464 6076abca
REPLY: 1:153/7001 sTW6u3OA
Hi Maurice,

On 2021-04-13 21:15:41, you wrote to August Abolins:

 AA>> Is that a way to reduce the probability of collisions within a
 AA>> certain span of allotted time?

 MK> Good question.  I've heard of a few different methods for doing this none
 MK> of which I am currently deploying.  Mind you I take care of MSGIDs in the
 MK> creation of the MSG so the possiblity of collisions is near zero.  There
is
 MK> a way but if that happens then it is a signal that something is seriously
 MK> wrong on my system.  It has yet to happen.

 MK> Just for fun here is the output of 10 potential MSGID serailno's, the
first
 MK> column being unixtime 32-bit hex based, the second being the random 8
 MK> character [:alnum:] regex dealies;

 MK> 60760e0b kUBdI5RO
 MK> 60760e0b G5T1LBae
 MK> 60760e0b mFSS1Gxc
 MK> 60760e0b Daxpq9EE
 MK> 60760e0b XVCgstYj
 MK> 60760e0b uWuB7Jqj
 MK> 60760e0b J0qZbQIo
 MK> 60760e0b kGrnLcEZ
 MK> 60760e0b NQGnXOVM
 MK> 60760e0b kK7htVJO

 MK> Note that only one method produced zero collisions while the other
produced
 MK> nothing but collisions.  Based on this very simple test the random 8
 MK> character [:alnum:] regex thingies are obviously superior.

So your algorithm based on unixtime has a bug! It should take into account it
can be called multiple times within the same second. If you do that correctly,
it's superior to the random one...

Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
 * Origin: FMail development HQ (2:280/464)
SEEN-BY: 1/123 18/200 90/1 105/81 120/340 123/131 124/5016 129/305
SEEN-BY: 154/10 203/0 221/0 226/30 227/114 229/101 424 426 452 664
SEEN-BY: 229/700 1016 1017 240/1120 2100 5138 5411 5824 5832 5853
SEEN-BY: 249/206 317 400 280/464 5003 282/1038 288/100 292/8125 301/1
SEEN-BY: 310/31 317/3 320/219 322/757 342/200 396/45 423/120 460/58
SEEN-BY: 633/280 770/1 2454/119
PATH: 280/464 240/5832 229/426