gafferongames
commented
2 years ago The connect token is meant to come from the backend, which is time synchronized with the server fleet. The intent is to only enable clients to connect with a valid (and current) connect token sent to them from your matchmaker backend, otherwise people can just get one connect token and use it over and over.
Overall, the intent of this system here is to only enable clients to connect to servers when the matchmaker has explicitly enabled that connection.
cheers
I have a question on the connection logic that deals with the server and client time stamps differing, and thus refusing the connect.
For example, in function netcode_read_packet( ) there is the following check:
uint64_t packet_connect_token_expire_timestamp = netcode_read_uint64( &buffer ); if ( packet_connect_token_expire_timestamp <= current_timestamp ) { netcode_printf(NETCODE_PRINT_LEVEL_INFO, "ignored connection request packet. connect token expired. expire_timestamp: %" PRIu64 ", current_timestamp: %" PRIu64 "\n", packet_connect_token_expire_timestamp, current_timestamp); return NULL; }This code above is in effect comparing the time of 2 different computers (server and client), and when they differ, the connection is refused. Note that the client time stamp 'packet_connect_token_expire_timestamp' includes the timeout period, of which we have set to a 10 seconds.
For example, we have some issues where the clients time is ahead of the servers time by about 20 seconds. So the client cannot connect. Both PCs run Windows 10, and both run the Windows Time service.
For now, we had to disable the check.
So, we were wondering what the intent was with the check ? Was there a specific problem that was solved ? Also, are there any plans to change this check ?