On Tue, 2014-01-07 at 14:29 -0800, Andrew LeCain wrote:
> I agree that really all we need is the next major event (T1 or T2
> expiring) The plugin is pretty simple and just chooses the earliest
> expiration to wake up. I included all of these statistics for
> completeness, but if you think it is better to only provide the next
> wakeup then that will make the plugin even simpler. However, we will
> also need some indication that it is okay to sleep. For example, when
> we send our renewal packet at T1 expiration, we need to keep the
> system awake for a while to wait for the timeout and and recalculate
> T1, set T2 timeout, etc.
Indeed. Only when the T1 or T2 lease reacquisition has happened, should
whatever system be notified with the new timeout.
> I would suggest then that we need two changes to the API:
>
>
> - void (*wakeup_changed) (struct connman_ipconfig *ipconfig); --
> notifier called whenever get_next_wakeup will return a valid sleep
> value. This will happen whenever we can safely enter sleep, such as a
> successful renew, successful rebind, or expired lease.
>
>
> - time_t connman_ipconfig_get_next_wakeup() -- added to ipconfig.h to
> provide the next wakeup time (min(T1, T1 retry, T2,
> lease_expiration);) Because of the accounting of T1 and T2 in gdhcp,
> it would be easiest to return an absolute time. If the time returned
> is in the past then assume we should remain awake until we get another
> wakeup_changed notifier event.
No ipconfig involvement here, please. Just something simple indicated in
a generic way after a new lease when the next time of an important event
will happen. Internal DHCP timers are not interesting to anyone.
Link-local is also of concern, with link-local the device needs to be
able to defend its autogenerated IP address. That situation must be
addressed too, and also the case with IPv6 with or without DHCP.
The other obvious catch is to figure out what needs to be done with more
than one service connecting at the same time, perhaps wait for all
connecting services? At that point let's hope the other network
technologies also can wake up the device, otherwise we have a guaranteed
weird situation with other devices knowing our IPv4 DHCP, IPv4
link-local, IPv6 or IPv6 DHCP address trying unsuccessfully to connect.
Yet another catch is how to wake up on IP packets destined to us via all
the other non-WiFi network technologies.
Cheers,
Patrik
_______________________________________________
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
