Client latency performance and time synchronisation

[Phil Johnstone]

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

[Nicholas (Google Cloud Support)]

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 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() 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. 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() to get the time in milliseconds and add the offset from calendarObject.getTimeZone().getOffset(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 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.

[Brad Abrams]

I wrote an app with a similar idea.. Using Go on App Engine..  

https://play.google.com/store/apps/details?id=com.buzzin.myapplication

I ended up going with "first to the server wins" model because I didn't want to trust the the client time (too easy to hack)...  For use cases where everyone is on the same wifi network it works pretty well.

..brad

--
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-appengi...@googlegroups.com.
To post to this group, send email to google-a...@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/600275f4-84f7-4e30-98ef-af336b872c3f%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Phil Johnstone]

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.

[Nicholas (Google Cloud Support)]

For some very 'Hello world'-like examples, Udacity has a nice free course called Deploying Scalable App in Java that will walk you through building a conference-organizing application using some essential App Engine components. The sample code will sometimes require that you not look into the black box too much and accept what's working but with some study, one can get a good idea of what is actually happening. Hope this helps!

[Phil Johnstone]

That's great, thank you for the link :-)