You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
So here's the changes I'm thinking packet-wise (let me know what you think): When a client hosts a game (packet 21), they will recieve back 21GameID with the GameID of their game. When they want to unregister a game they'll send 22GameID with their GameID to unregister (the tracker will check both the port/IP their sending from AND the GameID they send to makes sure that a host can only remove his own game. This should make it impossible for someone to spoof an IP/port to remove a game since they'd also have to know the GameID of the game to remove).
When the tracker recieves 22GameID, it will reply with 22-0, 22-1, or 22-2. 22-0 means the game unregistered succesfully. 22-1 means the GameID wasn't found (or didn't match the IP/Port), and 22-2 means the IP/Port wasn't found (or didn't match the GameID). (This could be simplified to just 22-1 for success and 22-0 for not-success if you'd rather).
When a client sends 26GameID to hole punch, if the GameID isn't found, it will recieve back 27GameID (the ID of the game they tried to hole punch).
Finally, if a host is updating a game, he will include the c=GameID key in the value string so that the tracker knows it should be updating. Otherwise, it will create a new game. (So for instance, if the tracker gets 21b=HEADER,z=BLOB, it will create a new game, but if it gets 21b=HEADER,c=GameID,z=BLOB it will update the game with GameID). This will also be double checked by both IP/Port AND GameID to prevent abuse.
The text was updated successfully, but these errors were encountered:
So here's the changes I'm thinking packet-wise (let me know what you think): When a client hosts a game (packet 21), they will recieve back 21GameID with the GameID of their game. When they want to unregister a game they'll send 22GameID with their GameID to unregister (the tracker will check both the port/IP their sending from AND the GameID they send to makes sure that a host can only remove his own game. This should make it impossible for someone to spoof an IP/port to remove a game since they'd also have to know the GameID of the game to remove).
When the tracker recieves 22GameID, it will reply with 22-0, 22-1, or 22-2. 22-0 means the game unregistered succesfully. 22-1 means the GameID wasn't found (or didn't match the IP/Port), and 22-2 means the IP/Port wasn't found (or didn't match the GameID). (This could be simplified to just 22-1 for success and 22-0 for not-success if you'd rather).
When a client sends 26GameID to hole punch, if the GameID isn't found, it will recieve back 27GameID (the ID of the game they tried to hole punch).
Finally, if a host is updating a game, he will include the c=GameID key in the value string so that the tracker knows it should be updating. Otherwise, it will create a new game. (So for instance, if the tracker gets 21b=HEADER,z=BLOB, it will create a new game, but if it gets 21b=HEADER,c=GameID,z=BLOB it will update the game with GameID). This will also be double checked by both IP/Port AND GameID to prevent abuse.
The text was updated successfully, but these errors were encountered: