reformstudios
commented
4 years ago Would prefixing the uuid with a user id prevent cross-user duplicates at least?
On Mon, May 18, 2020, 11:52 PM Quinn Bast notifications@github.com wrote:
When a new sub is generated it is assigned a unique ID so that game events are able to reference the correct sub ID when the event data gets parsed. However, the generation of this ID is based off the client's random number generator. Hopefully, you can see where this is going...
Because the IDs are generated for every sub, if a user attempts to launch a sub, but decides to cancel their launch, the ID for that sub would have been generated for the user trying to launch the sub but it wouldn't have been generated for anyone else. Thus the client who launched the sub and canceled is now out of sync.
Furthermore, two clients attempting to launch subs that cannot see each other will end up generating the same ID for their subs, causing two subs with the same ID to exist. Expected Behavior
The client should not get out of sync when a sub ID is generated, nor should two subs have the possibility of having the same ID get generated. Possible Solution
Maybe instead of using an ID field for the sub, a UUID could be used instead. This would be garunteed to be unique but would unfortunately take up more bandwidth to transfer the information.
However, it is important to note that the client cannot garunteed generate a unique ID unless the client knows about ALL of the player's game events (which provides the possibility for unlimited vision hacks). The only way to completely mitigate the possibility of duplicate IDs is to make the server generate the sub's ID. However, this would mean the server would need to be able to parse the gameEvent JSON. It also means that on every request to the server, the server would need to re-create the game simulation as well as parse ALL game events (even the events in the future), to ensure no generated sub has the ID that it generated. It would be much easier to just let the client assign the UUID.
!!! Important !!! When loading game events from the server, clients should throw out game events if a sub's ID collides with another sub. Discussion
We need to discuss if we thing UUIDs are reliable enough to avoid collisions or if we want the server to manage the IDs of subs within each game.
If the server relies on a client to generate the UUID of the sub, then there should be absolutely no way for a player to get another player's future events. If one client can see another player's future launches, they could schedule an earlier launch with the same UUID which would cause other clients to throw out the original sender's event. I don't think this is an issue as players should never be able to see another player's future events. If this is the case, I am OK with using client generated UUIDs as the chance of colliding UUIDs is near impossible.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Subterfuge-Revived/Remake-Core/issues/24, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABD4XQDVNSCSGZUVLAIRN6TRSG3WVANCNFSM4NEPMRBA .
LordSputnik
When a new sub is generated it is assigned a unique ID so that game events are able to reference the correct sub ID when the event data gets parsed. However, the generation of this ID is based off the client's random number generator. Hopefully, you can see where this is going...
Because the IDs are generated for every sub, if a user attempts to launch a sub, but decides to cancel their launch, the ID for that sub would have been generated for the user trying to launch the sub but it wouldn't have been generated for anyone else. Thus the client who launched the sub and canceled is now out of sync.
Furthermore, two clients attempting to launch subs that cannot see each other will end up generating the same ID for their subs, causing two subs with the same ID to exist.
Expected Behavior
The client should not get out of sync when a sub ID is generated, nor should two subs have the possibility of having the same ID get generated.
Possible Solution
Maybe instead of using an ID field for the sub, a UUID could be used instead. This would be garunteed to be unique but would unfortunately take up more bandwidth to transfer the information.
However, it is important to note that the client cannot garunteed generate a unique ID unless the client knows about ALL of the player's game events (which provides the possibility for unlimited vision hacks). The only way to completely mitigate the possibility of duplicate IDs is to make the server generate the sub's ID. However, this would mean the server would need to be able to parse the gameEvent JSON. It also means that on every request to the server, the server would need to re-create the game simulation as well as parse ALL game events (even the events in the future), to ensure no generated sub has the ID that it generated. It would be much easier to just let the client assign the UUID.
!!! Important !!! When loading game events from the server, clients should throw out game events if a sub's ID collides with another sub.
Discussion
We need to discuss if we thing UUIDs are reliable enough to avoid collisions or if we want the server to manage the IDs of subs within each game.
If the server relies on a client to generate the UUID of the sub, then there should be absolutely no way for a player to get another player's future events. If one client can see another player's future launches, they could schedule an earlier launch with the same UUID which would cause other clients to throw out the original sender's event. I don't think this is an issue as players should never be able to see another player's future events. If this is the case, I am OK with using client generated UUIDs as the chance of colliding UUIDs is near impossible.