Hi,
On Mon, 2014-01-06 at 18:09 -0800, Andrew LeCain wrote:
>
> As mentioned in discussion of RFC "Publish DHCP statistics to dbus" on
> 10/31, we have a usecase that requires knowledge of dhcp statistics
> (specifically lease duration and lease time) to make power management
> decisions for the system. As suggested by Marcel, we've implemented
> this as a plugin, however there are a few changes to the core and api
> needed to expose this data to the plugin.
>
> Specifically, we need accessors to request the statistics about the
> lease and a notifier event to trigger every time the lease changes
> (renew, rebind, etc) I have implemented this as generically as
> possible to allow other plugins that need information about the lease
> to use this information as well.
Exposing DHCP data will not be necessary.
Your system wants to sleep as long as possible. Thus ConnMan needs to
inform the system of the next time when an event of importance takes
place. From the DHCP perspective, this is when ConnMan needs to get back
to the server to renew it's lease. Only the time of the next event needs
to be communicated, not the full spectrum of related data.
Start with the plugin itself. It surely communicates over D-Bus to the
rest of the system and is quite simple. As input for the D-Bus
communication the time of the event is needed, either absolute or
relative.
DHCP is one source of such information, but the individual DHCP timer
values are not. Starting off with an acquired lease, the system can
sleep until Renewing timeout T1 minus the time it takes to wake up from
whatever deep sleep the system is in. That computation is part of the
system and not any of ConnMan's concern, though.
If reacquiring a DHCP lease after waking up is successful, T1 gets
recomputed and the system can sleep until T1 again. If it didn't
reacquire the DHCP lease, either a newly recomputed T1 timeout, T2
timeout or expiry timeout is next. Thus the plugin needs to be informed
of the minimum time of these three events and report that over D-Bus.
Same thing if T2 timer hits, at that point T1 is of course cancelled. So
the full set of DHCP values is not needed, only the time of the next
event.
The other funny thing is that some fixes may be needed for all the T1,
T2 handling, at least the code does not take the T1 or T2 timeouts into
account.
So perhaps you could send the plugin first and then work backwards from
there to extracting the next timeout for any DHCP event?
Cheers,
Patrik
_______________________________________________
connman mailing list
[email protected]
https://lists.connman.net/mailman/listinfo/connman
