Thank you very much for your comments. It's given me a bit more to think about.
I can see how using server time stamps wouldn't work due to latency but I'm not quite sure how to make client time stamps work on a practical level. Let's say for argument sake that the maximum a real person can detect inaccurate buzz order is a 10th of a second. Therefore, the objective is for client time stamps to be in sync within 1/10 second. Even if the mobile device clocks are sync'd with NTP, I don't see how they can be in sync to an accuracy of 1/10 second. After all, synchronisation to NTP will happen over the Internet which itself could suffer from latency. Perhaps using the Internet to determine first buzz is not realistic. I may need to think of another application for learning with App Engine. On Tuesday, January 5, 2016 at 8:20:09 PM UTC, Nicholas (Google Cloud Support) wrote: > > Thanks for the interesting question. > > For starters, you are correct. There will be network latency. Your > application will be deployed to the region of your choosing > <https://cloud.google.com/appengine/docs/python/console/#server-location> > and respond to requests from there. Any HTTP requests between users will > have to travel there and back, thus incurring this network latency. > Therefore, one cannot rely on the arrival time of the HTTP request (in this > case, buzzer) to determine the order. > > The time one should look for is the time at which the 'button' is pressed > which is best known by the client device. If your client is running in the > browser for instance, you could use Javascript's Date.now() > <https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Date/now> > function > and provide its result when sending the 'buzz' HTTP request to your > application. > > As noted from MDN: > >> The Date.now() method returns the number of milliseconds elapsed since 1 >> January 1970 00:00:00 UTC. > > > The downside here is that the user can manually change to time set on > their device to always be listed first. As far as I know, Date.now() gets > its time from the device time as I've found nothing to the contrary in the > EMCAScript-262 > spec about Javascript <http://www.ecma-international.org/ecma-262/6.0/>. > If the user were to set their device time manually to an hour before > everyone else, they will always register as the first buzzer. Barring this, > most modern devices automatically sync time with accurate time servers. > If your client is running on Android devices for example, you could use > calendarObject.getTimeInMillis > <http://developer.android.com/reference/java/util/Calendar.html#getTimeInMillis()>() > > to get the time in milliseconds and add the offset from calendarObject. > getTimeZone > <http://developer.android.com/reference/java/util/Calendar.html#getTimeZone()> > ().getOffset > <http://developer.android.com/reference/java/util/TimeZone.html#getOffset(long)>(calendarObject.getTimeInMillis()) > > to get the milliseconds since 1 January 1970 00:00:00 UTC. This again gives > the same vulnerability though as manually changing the device time will > affect these values. At least, with an application running on Android, you > can determine if the time has been manually set by checking the > Global.AUTO_TIME > <http://developer.android.com/reference/android/provider/Settings.Global.html#AUTO_TIME> > > property. > > Given the use case you described with family and friends, I'd say this may > be a simple and effective solution until someone is motivated enough to > find a way to cheat or if they manually set date and time on their device > for whatever reason. > > Cheers. > > > On Tuesday, January 5, 2016 at 8:36:41 AM UTC-5, Phil Johnstone wrote: >> >> I'm just starting out with getting up to speed with Google Apps Engine. A >> useful tool that I'd like to develop to help me learn (as well as being >> useful personally) is to create an app that will simulate a buzzer for a >> game show. Someone will setup a new game show (the manager for the group) >> and various other people will join the game (as contestants). Each >> contestant will then be able to buzz in and the fastest buzzer will be >> shown to the manager. The intention is for this to be used by people who >> are in the same room. They may be connected via the same WiFi or they could >> be connected via their own mobile network. >> >> My question is, what can I do to make it fair so the actual first buzz is >> shown on the manager as the first buzz. I'm worried that network latency >> may re-order the buzzes. I'm not worried about buzzes that are milliseconds >> apart, I'm only interested in ones where it is noticeable by a person that >> they are registering in a different order. >> >> I'm not looking to make it bullet proof from exploits as I'm not planning >> to make it public. I'm currently only going to use it for family and >> friends. >> >> TIA >> > -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at https://groups.google.com/group/google-appengine. To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/26acb89c-79b8-4263-a0e9-2b36a25c5134%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
