On Wednesday 26 June 2013, Jan Kaluža wrote: > currently mod_unique_id uses apr_gethostname(...) and PID pair as a > base to generate unique ID. The way how it's implemented brings > some problems: > > 1. For IPv6-only hosts it uses low-order bits of IPv6 address as if > they were unique, which is wrong. > > 2. It relies on working DNS. It can happen that hostname does not > have the IP assigned during httpd start (for example during the > boot) and I think it is still valid use-case (without > mod_unique_id module loaded, httpd works well in this case). > > 3. It calls 1 second sleep to overcome possible usage of the same > PID after restart as the one used before the restart. > > If I'm right, we could fix the problems above by using > ap_random_insecure_bytes instead of "in_addr"/"pid" pair as a base > for unique ID generation. It would also make the code simpler. I > think the randomness generated by ap_random_insecure_bytes() is at > least the same as the one introduced by apr_gethostname() + pid > pair. > > The attached patch implements it by removing in_addr/pid fields > unique_id_rec struct and introduces new "root" field which is > initialized using ap_random_insecure_bytes() function and is used > as a base for unique IDs.
I agree in principle, but I would prefer the ID length to not increase that much. You replace 8 bytes ip+pid with 20 bytes "root", which means 16 bytes increase in base64 format. The unique id is also used as a request log id and having an additional 16 bytes of prefix in the error log (if one uses that feature) does not really appeal to me. But 20 bytes may be excessive, anyway: If one assumes 10000 servers over which the IDs needs to be unique, and uses a 8 byte "root" field, the probability for a collision is 3*10^(-12) if I did the math correctly. This still has to be multiplied with the number of restarts of the servers, so to be save we could use a 10 byte "root" field, giving a collision probability (per server restart) of 4*10^(-17), which should be ok.
