4 ms·
Calling a PRNG is way easier than any of the alternatives. Coordinating sequences on a bunch of nodes so that nobody overlaps is a pain in the ass, and a point
by mmalone 11y ago
Calling a PRNG is way easier than any of the alternatives. Coordinating sequences on a bunch of nodes so that nobody overlaps is a pain in the ass, and a point of failure. Incorporating some notion of "machine ID" in the identifier makes it easier, but you still have to worry about multiple pieces of software on the same machine, for example. UUIDs are the a good solution, but you need a UUID library you trust, and they waste a lot of space / are overkill for many use cases.
All of that is sort of beside the point though. Pseudo-random sequences are useful for lots of things and the PRNG algorithm behind Math.random() is pretty crappy.
- 0x0 11y agoIf you don't want a machine ID to segment the counters: What if you use a PRNG to initially seed an incremental counter? I don't really see how that would that be weaker than using a PRNG for each value? Is it just that the obfuscated period and pattern of a PRNG makes it "feel" less likely to collide?
- Someone 11y agoIf you use a PRNG to seed an incremental counter on every node, and you get one collision, you are bound to get zillions of them. On the plus side, I think that means the risk that you get a collision is smaller. Also, using bare incrementing counters may be a bad idea for different reasons: it allows attackers to guess IDs of future messages. You can counteract that by hashing the IDs using a good cryptographic hash function, but that effectively turns your ID generating process into a PRNG.