hi.
im working on a project that the server side need to check that what task is done sooner by a player. assume something like a duel. as players have no interaction with each other, i want to use tcp. but i want to determine the winner based on server clock and rtt to check which one performed the task sooner.
is this right way of doing this and is it possible to get rtt of every single message?
i think it really depends on how you're intending to use rtt with your server clock value: are you going to average it ? or subtract it or run heuristics ?
in other words , what actual calculation have u got in mind for these 2 things ? u'll have to tell us a little bit more on your plan… (I'm guessing that you're trying to find a good way to balance input Vs results for both players, if not then u'll have to explain a bit more)
Until then ?
@ddlox for example you need to know which one pressed the button sooner.
playerOneTime= ServerClock-PlayerOneRequestRttInMiliseconds
// player two is the same and…
i need to know is it the standard way and are there any serverside solutions like grpc that give me the rtt for every single request?
i need to know for every request that what amount of time it takes to be delivered to the server.
The round trip time is the time it takes to go from the client to the server and back again - not just from the client to the server.
The time taken for a message to travel just from client to server (or server to client) is likely to be about half the round trip time, but not always.
For some rather complex reasons it's not usually possible to be certain about how long it took a message to travel across the network. If the client gives you an accurate and honest timestamp of when it was sent, and you have an accurate timer on the server, then you can know. But you can't necessarily guarantee the client's accuracy and honesty.
So, while for some operations it is fine to use half round-trip-time to estimate how long ago a client started an action, for game-critical functionality you usually want to handle this entirely in terms of the server-side time, because otherwise clients can lie about the time and cheat in your game.
ok now that i see how u intend to use those values, the answer is (respectfully): no, that's not good enough. Why? because let's say this game is played on LAN where it is reasonable to assume that rtt can be consistent for a given TCP connection (as u said that the game would be using TCP);
then if one player1's RTT is always approx 10ms and p2 is always approx 40ms, then player1 will always win, i'd wish i were player 1 ?;
..and playing on WAN is not going to be any better where winning will be based on whoever's random connection gives them the best rtt; that would not be fair play either;
the standard way that most sites do in this case is to check an amount of a user input data received within a time window:
for example, this is how the well known ebay site works ?:
With 6 or less seconds left (time window) to a closing auction, bids come in (user inputs) and the winner is the one who bid the highest (amount) before or during the closing time window (note: the winner is not the one who enters his/her bid the fastest)
so u could do something similar with yr rpc server:
this way when a user has clicked, the generated rpc will be queued (and this gives a fair chance to both players);
so u should only count inputs received in this t-window until when the queue is empty (this way the only clock that you will use is the server clock to govern both players and the server itself like ebay ? )
remember: such game should be about giving each player a fair chance to win not a random chance nor favouring grease ?
u could then make your game interesting with various modes:
Btw, network lag will always be an issue where it exists but at least u don't use it to decide in your calculations who loses or wins..
I hope that clears it a bit
have fun ?
There is no clock that is the same for two people across the network. Can't be done. Causality forbids it. The best you can do is Lamport clocks.
If you are not worried about cheating, then you can estimate clocks using one-half the round-trip time, and hope that nobody hacks their clients to report the wrong RTT at the critical moment, or wire up a network switch with an on/off switch to be able to use delay compensation to accurately shoot people who would otherwise bounce around (as seen in old FPS games.) But if you're not worried about cheating, you can just send the inputs from one player to the other player, and report “I did it before I saw the other player” from each player. Turns out, you will likely get into the case where player A did it before they saw player B, AND player B did it before they saw player A, and then what do you do?
Distributed systems are not like local systems. Don't pretend they are. Don't design like they are. You must embrace the time dilation, and design games that work well over a transmission medium with latency.
