# Guid collisions

I have a product that lets game developers create games. Inside of their games they are required to give all the elements of their games GUIDs. I've told them that they need to generate their guids using a specific mechanism, but they seem to think that it won't cause any issues. What I'm concerned about is GUID collisions between games.

Some developers just sequentially increment the last digit of their GUID, others zero out the last block and increment other parts, well others just pull together a random armada of numbers and letters for each one.

My argument is that by doing this it dramatically increases the risk of colliding with other games that are both following the standard, and those that don't.

Just as a heads up there are potentially hundreds of thousands of GUIDs involved here.

Am I right in thinking this, or is it really improbable that this will really happen?

-
What would be the consequence of a collision in GUIDs between two different games? – Donal Fellows Jun 17 '13 at 18:25
I think a better design would be to assign each Game a GUID yourself, then each "element" would have a guid and the combination of the two would be unique. – Rob Jun 17 '13 at 18:30
Monkeying with the GUID yourself will almost certainly increase the probability of a collision. Whether it's statistically significant or not is an open question, but why take the chance, when GUIDs are so easy to make programmatically? Is the probability non-zero of more than one developer choosing a GUID like 00000000-0000-0000-0000-000000000001 and incrementing it? – Robert Harvey Jun 17 '13 at 19:07
tell them to use a guid generation library that has been proven to be good – ratchet freak Jun 17 '13 at 19:24
@kelton52 The odds of random GUID collision is only true if you are generating the GUIDs randomly, and with a "fair" random number generation algorithm. If you aren't generating them randomly, or not fairly, then such odds are meaningless. If two people use the algorithm of "start at 0 and increment by 1) then the odds of collision are 100%. If they're all generating their GUIDs randomly, and with proper RNG, then that's a valid algorithm for generating GUIDs with (for most people) sufficiently low probability of collisions. – Servy Jun 17 '13 at 19:38

Since you're not in control of guid creation you need to expect that there will be a collision at some point (if there isn't one already) and you have to expect that there will be novice developers who don't see why starting at 1 and counting up is a problem.

To make it impossible you would have to issue all the guids yourself.

But, since people can access other people's objects purely by a single ID, you also have a big security hole waiting to be exploited and depending on how you choose to fix that, this problem will may wind up a moot point.

-
Yeah those were most of my thoughts as well. I was mostly looking for confirmation that doing that would actually statistically increase GUID Collisions. Maybe it would have been better to post in the math SE site? – kelton52 Jun 17 '13 at 20:02
@kelton52 Unless you know all of the algorithms people are using you won't be able to mathematically determine the probability of collisions. For example, if everyone starts at one position and increments it all comes down to whether or not they create more or less than the number of GUIDs between them and the next highest GUID used. If they need less it's 0%, if they need more it's 100%. – Servy Jun 17 '13 at 20:17
@servy That makes sense, didn't think about it that way. Thank you. – kelton52 Jun 17 '13 at 20:19

I've told them that they need to generate their guids using a specific mechanism

Are you in power? Reject code not using your mechanism.

If using the mechanism is a requirement then it's bad developers don't use it. But you might want to give them an easy implementation.

Btw. if your product lets' programmers create games why not let your product generate the guids?

-

There’s a couple of things to note.

You will have collisions. Even if they are mathematically improbable, they're still possible. And given Murphy’s Law, you will end up seeing the improbable become reality at the most inconvenient time, like when you're trying to final. If you're using any kind of hashing algorithm, you need to be aware that you will at some point have hash collision, and need a process to fix it. This is quite often just adding more, unique information into the hash.

If you're letting people generate their own hash’s ids. You’re in for a world of hurt. There needs to be one way of hashing data, and that way needs to provide enough "uniqueness" to minimize collisions. Either that or you use a centralized GUID factory that doles out unique GUIDs. Of course, there are various threading issues with this approach.

Although you could simply have a GUID factory per thread, and give each GUID factory a different starting point a few billion id's apart from each other. This can also be a handy way to work out which thread exploded.

The real answer to "which approach" you should take should come from how your resource system works. If you're using a centralized asynchronous resource system (and you should be), you can assign GUID's at that point. If you're creating random objects all over the shop in various threads, then you're going to have to go with one of the other options above.

-
... actually if they all use a guid algorithm that evenly creates random guids (like C#'s Guid.NewGuid), the chances of there being any collision at all within a timeframe anyone cares about are nil. That's basically the point of guids, that you don't need intercommunicating factories. – Tacroy Jun 19 '13 at 3:32
Depends on exactly how they are "randomly" generated. Hand generated Guid's will only be as unique as their original input data though. The call to Guid.NewGuid is a static call, which being data delivery only, should be threadsafe. But will probably stall. itd be interesting to see the mechanism behind the generation for that function. – Matt D Jun 19 '13 at 5:28
Please do not use 'hash ID' and 'GUID' interchangeably. Only certain types of GUID (namely UUID v3 and v5) are based on hashes, and they will only be unique if the inputs that produce them are unique, as is the case with any hash algorithm. A GUID generated with UUID v4 will have 122 bits of entropy. Writing code to catch cases of duplicates is a waste of time in this case. – jordanbtucker Jan 14 at 0:16