The server is what's in common and must be the keeper of time. If you're worried about latency making timings inaccurate, there are much bigger potential problems with making the clients keep track of time. For example, assuming you have some unique token for that match on the URL, what happens if the user refreshes the browser?
Everything happens on the server at the time that the server is told about it. The server can then report current elapsed times, time stamps for certain actions, or anything else that you need to display to the user. On the client side, you can ask the server about the elapsed time and present a view that approximates a real-time clock that matches. These may drift due to latency or other factors, but can be synched periodically (when other actions happen, once per minute, or whatever is appropriate). Now, if that isn't accurate enough, you can start thinking about improving it by trying to measure latency or using other tricks. The important point is that reality resides on the server. The UI will eventually show an accurate picture of that reality. It should be pretty easy to make the view accurate to a few seconds. If that's not good enough, a little extra work (measuring latency) should get accuracy down to less than a second. I don't play chess enough to know, but I imagine that's good enough for this case. -Brian On Thu, Feb 17, 2011 at 10:10 AM, Jeff Chimene <[email protected]> wrote: > On Thu, Feb 17, 2011 at 12:57 AM, János Kiss <[email protected]> wrote: >> >> If the timers run only on the clients, it can be inconvenient if they >> are'nt synchronized. Both clients have a timer about the opponent, and when >> he or she makes a move, > > Isn't this a digital version of a chess clock? If so, the opponents clock > starts, and your clock stops when you trigger the clock's actuator, not "... > when he or she makes a move." Your clock stops and the opponents clock > starts when you end your move, not when you start. > >> >> you can see the timer counting 1:01, 1:02 > > Which uses a GWT animation technique. This would be the "guessed elapsed > time" I agree that there will be a latency here. That's the nature of the > network beast. I suppose you could advance the clock based on measured > latency, but you can correct for this on receipt of the opponent's actual > elapsed time. > >> >> and then get the message from the server the opponent made a move at 1:00, >> and the client have to correct the time. > > It's elapsed time, not wall time. If chess players cared about wall time, > then chess games via snail mail wouldn't be very much fun. > > Each player sends an elapsed time message to the server upon the digital > equivalent of the analog hit of their stop switch on the clock. The client > sends a message to the server that contains the actual elapsed time. I do > agree that a correction must be made on each player's clock for differences > in the opponent's actual vs. guessed elapsed time. The local display is > corrected upon receipt of an elapsed time message. > > >> >> Synchronize the time with the server can be made for example: >> 1. client sends a request to the server to get the server time, and >> records the sending time of the request (1:01.5) >> 2. the server sends back the server time (0:59.3) >> 3. the client gets the time and records the time of getting the response >> (1:03.1) >> Now the client can estimate the network latency by getting the difference >> of the 1. and 3. step and dividing by 2. (1:03.1-1:01.5) / 2 = 0:01.6 / 2 = >> 0:00.8 >> The latency has to be added to the server time sent by the server and you >> are ready. (0:59.3 + 0:00.8 = 1:00.1) >> This works if the server is not too busy and the response is generated >> immediately. >> Cheers >> Peter > > >> >> 2011/2/17 Jeff Chimene <[email protected]> >>> >>> On Wed, Feb 16, 2011 at 9:41 AM, Magnus <[email protected]> >>> wrote: >>>> >>>> Hi, >>>> >>>> my chess application needs time handling. >>>> >>>> As a general rule, all game related timing decisions are done on the >>>> server. For example, when a move is made, the move's time is >>>> determined and stored on the server. >>>> >>>> However, the client should have some visual feeling of a "running" >>>> clock, i. e. a clock that is update every second. >>>> >>>> How can I realize this? I need help especially for these questions: >>>> >>>> - How do I realize the running clock? Do I have to a timer every >>>> second, update the display and create a new timer? >>>> >>>> - As a starting point, the client receives some initial time value, e. >>>> g. when a game is loaded, the client receives the information that >>>> black has already spent 01:00 (1 hour). However, there is a little gap >>>> due to the RPC processing time. First, the server sends back the >>>> information "1 hour" to the client. Then, the client starts counting >>>> "01:01", "01:02", and so on. However, when the client starts counting, >>>> the time may already be at "01:03", depending on the bandwidth of the >>>> internet connection. Can one do something about this? >>> >>> Isn't this chess clock an elapsed time clock? In other words, the clock >>> doesn't sync with wall time, or with the server. It doesn't even have to >>> take time zone into consideration. The server should be recording elapsed >>> time per client. Why is the network transmission time even an issue? >>> >>> Cheers, >>> jec >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Google Web Toolkit" group. >>> To post to this group, send email to [email protected]. >>> To unsubscribe from this group, send email to >>> [email protected]. >>> For more options, visit this group at >>> http://groups.google.com/group/google-web-toolkit?hl=en. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Google Web Toolkit" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/google-web-toolkit?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "Google Web Toolkit" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/google-web-toolkit?hl=en. > -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
