On Thu, Feb 17, 2011 at 12:57 AM, János Kiss <ffun...@gmail.com> 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 <jchim...@gmail.com> > >> On Wed, Feb 16, 2011 at 9:41 AM, Magnus <alpineblas...@googlemail.com>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 google-web-toolkit@googlegroups.com. >> To unsubscribe from this group, send email to >> google-web-toolkit+unsubscr...@googlegroups.com. >> 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 google-web-toolkit@googlegroups.com. > To unsubscribe from this group, send email to > google-web-toolkit+unsubscr...@googlegroups.com. > 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 google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
