Better for whom? I'm sure all mobile operating systems provide some access to time, with a least 'seconds' resolution. If an app deems this time source untrustworthy for some reason, I don't think the reasonable response is to make independent time requests from a volunteer-operated pool for public servers designed for host synchronization. Particularly on mobile, the compartmentalization of applications means that this 'better' time will only be accessible to one application, and many applications may have this 'better time' requirement. These developers should be lobbying Apple and Google for better time, if they need it, not making many millions of calls to the NTP pool. To make things worse, I'm fairly sure that Apple's 'no background tasks' policy means that an application can't *maintain* its sense of time, so it would not surprise me if it fires off NTP requests every time it is focused, further compounding the burden. Time is already available, and having every application query for its own time against a public resource doesn't seem very friendly. It certainly doesn't scale. If they are unsuccessful lobbying the OS, why not trust the time provided by the API calls they are surely doing to their own servers? Most HTTP responses include a timestamp; surely this is good enough for expiring Snaps. Or at least operate their own NTP infrastructure. I'm sure that Snap had no malicious intent and commend them for their quick and appropriate response once the issue was identified, but I don't think this behaviour is very defensible. I for one was not harmed by the ~10x increase in load and traffic on my NTP pool node, but the 100x increase if a handful of similar apps decided they 'need' more accurate time than the OS provides would be cause for concern, and I suspect a great many pool nodes would simply disappear, compounding the problem. Please make use of these and similar services as they are designed to be used, and as efficiently as possible, especially if you are responsible for millions of users / machines. In a similar vein, I've always been curious what the ratio Google sees of ICMP echo vs. DNS traffic to 8.8.8.8 is... Keenan On 2016-12-20 18:16, Tim Raphael wrote:
Exactly,
Also they’re across Android and iOS and getting parity of operations across those two OSs isn’t easy. Better to just embed what they need inside the app if it is specialised enough.
- Tim
On 21 Dec. 2016, at 10:13 am, Emille Blanc <emille@abccommunications.com> wrote:
Perhaps the host OS' to which snapchat caters, don't all have a devent ntp subststem available? I have vague recollections of some other software (I'm sure we all know which) implemented it's own malloc layer for every system it ran on, for less trivial reasons. ;)
________________________________________ From: NANOG [nanog-bounces@nanog.org] On Behalf Of Tim Raphael [raphael.timothy@gmail.com] Sent: Tuesday, December 20, 2016 5:34 PM To: Gary E. Miller Cc: nanog@nanog.org Subject: Re: Recent NTP pool traffic increase
This was my thought actually, Apple does offer some time services as part of the OS but it’s becoming common with larger / more popular apps to provide some of these services internally. Look at the FB app for example, there are a lot of “system” things they do themselves due to the ability to control specifics. Users don’t want to have to install a second “specialised app” for this either.
With regard to an ephemeral chat app requiring time sync, I can think of quite a few use cases and mechanisms in the app that might require time services.
- Tim
On 21 Dec. 2016, at 9:26 am, Gary E. Miller <gem@rellim.com> wrote:
Yo Valdis.Kletnieks@vt.edu!
On Tue, 20 Dec 2016 20:20:48 -0500 Valdis.Kletnieks@vt.edu wrote:
Mostly out of curiosity, what was the reason for the change in the Snapchat code, and what plans does Snap have for whatever reason the NTP change was put in place? From other comments in the thread, it sounds like the app was simply
On Tue, 20 Dec 2016 18:11:11 -0500, Peter Beckman said: linked against a broken version of a library.... But why is a chat app doing NTP at all? it should rely on the OS, or a specialized app, to keep local time accurate.
RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 gem@rellim.com Tel:+1 541 382 8588