On Fri, 2014-09-26 at 10:32 +0100, Mathieu Trudel-Lapierre wrote:
> On Mon, Sep 22, 2014 at 5:21 PM, Thomas Haller <thal...@redhat.com> wrote:
> [...]
> >
> > the value priv->last_seen (together with nm_access_point_get_last_seen()
> > and nm_ap_set_last_seen()) are time stamps as returned by
> > nm_utils_get_monotonic_timestamp_s().
> >
> > Exposing these absolute values (without a reference point) to another
> > process is meaningless.
> 
> I disagree, maybe it's not meaningful to compare directly to boot
> time; but it's sufficient to compare values between themselves to
> figure out which networks are the newest.
> 
> That's currently what we're mostly interested in. I'm not sure if
> there would be other use cases; but the idea is especially to provide
> a way for applications to sort accesspoints by age and avoid using
> those that have been in scan results before, but not necessarily old
> enough or disappeared to be culled from the scan list just yet.
> 
> >
> >
> > Options:
> >
> >
> > 1) expose the timestamps to absolute times in seconds since 1970 (posix
> > time). Note that gint (with 32bit) is to short to represent that
> > property.
> >
> > Downside: timestamps are all wrong in case of resetting the clock.
> 
> As a note, I actually ported this patch to NM master, but it really
> has been tested on 0.9.8.8. I think we're at the point here where what
> happens is that the timestamps on 0.9.8.8 are actually still retrieved
> via time(NULL) initially, so this is basically what was achieved.
> 
> 
> > 2) expose time stamps to clock_gettime(CLOCK_BOOTTIME) or
> > clock_gettime(CLOCK_MONOTONIC).
> >
> > Downside: timestamps are only meaningful on the very same host. Its
> > quite uncommon to expose DBUS over the network, but I think we don't
> > want to restrict that.
> >
> > CLOCK_MONOTONIC is more commonly known then CLOCK_BOOTTIME, but has the
> > additional downside of being wrong after hibernate.
> 
> FWIW, I vote for this solution (CLOCK_BOOTTIME specifically); it seems
> an acceptable compromise that the values are only meaningful on the
> host, since the list of accesspoints is also going to be only
> meaningful on that host -- another might not see some, etc.
> 
> [...]
> 
> > Also note that priv->last_seen==0 means "never seen". Both for 1) and 2)
> > above, 0 can represent a valid value.
> >
> > Arguably for 1), We could define that 0 (1970-01-01T00:00:00) means
> > "never seen".
> > But maybe it would be better to map "never seen" to -1 -- thinking of
> > booting up a machine with drained CMOS battery that forgot the time
> > stamp and starts ticking at posix-time 0.
> 
> With CLOCK_BOOTTIME, wouldn't 0 also be a value unlikely enough that
> we can consider it "never seen"? Seems to me like even if
> NetworkManager started at 0; it's quite unlikely that by the time the
> system has gotten to start scanning it would still be at 0.
> 
> 
> I'll update the patch shortly to fix at least Nathanael's comment re:
> the wrong string; while we get to agree on exactly how the values
> should display.

Yes, at some point it may be useful to see the scan list over a network,
like with Cockpit.  So we can't preclude that use-case.

Even "since the Epoch" doesn't work, because the host and remote system
clocks might not be synchronized.  So we should really keep this to
arbitrary seconds-based units of some kind.  In the end, I think
CLOCK_BOOTTIME is probably the best, and we can also provide some kind
of WiFi.GetLastSeenNow() method that literally returns the value of
CLOCK_GETTIME, which then remote clients could match up with a system
clock and cache that difference to determine the actual age of the AP.
Thoughts?

Dan

_______________________________________________
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Reply via email to