[PATCH 0/3] Re: Propose patch for perpetual online check for connected services
by aleksandar@analyticsfire.com
From: Aleksandar Mitev <shondll(a)yahoo.com>
Hi,
Thanks for the lively discussion on this proposed change.
Taking into account all the notes and concerns I think I
came up with a balanced solution:
- regular online check is now governed by a compile time optio
rather than a runtime one in the configration file
- the proposed update to the state machine is disabled by default
leaving the current behaviour in place.
Btw, please advise on a better use of compile time defines (if you
happen to find the current implementation not suiatable) as there
are no usual #ifdef..#endif blocks in the project.
>On 9/4/19 5:22 PM, Slava Monich wrote:
>>> As of v1.37, when a service reaches the READY state, then the online
>>> check is started. If it succeeds, the a transition to ONLINE state
>>> happens. You are right in thinking that my proposed change will cause
>>> a downgrading to READY again, but you see, according to the state
>>> machine, another round of online checking will begin, possibly
>>> promoting the service back to ONLINE it it ever succeeds (ex. the
>>> Internet disruption was temporary). In general, this is a chance for
>>> any of the other services in READY state to take over.
>>
>> Are you sure that another service WILL actually take over when some
>> other service is stuck in the READY state? That's the key point.
>
>I agree. There are many small problems along the road.
>
Yes, it does happen in our use case (provided the number of failed
online checks is reached).
>> If such a handover doesn't happen then this transition back to READY is
>> useless. It will be just generating additional network traffic and
>> that's it.
>>
>> If handover does indeed happen then it's a major change of behavior and
>> must be configurable. We (Sailfish OS) consider READY as of the
>> "connected" states. We don't need and don't want to automatically switch
>> from WiFi to mobile data if WiFi gets stuck in the READY state. We still
>> consider it connected and let the user to turn it off and switch to
>> mobile data, if the user notices that it's not actually working.
>
>Okay, understood. If we going to mess with the current state machine we
>need to keep a compact mode. I suppose compile time would be good enough?
>
>>> Finally, if a failed online check is not reliable enough to determine
>>> Internet reachability, then it can be disabled altogether and replaced
>>> with a simple ping check (from a separate service) as in the case of
>>> mwan3 tool for Openwrt. However, in that case one will miss the
>>> checking of DNS working.
>>>
>>> Please share more details if you think I am missing smth here.
>>>
>>
>> Have you considered the VPN scenario? When VPN is connected, you may not
>> be able to run online check for the transport interface - it won't have
>> any routes to anything other than local subnet and the VPN server.
>
>Indeed, VPN can be pretty tricky. This needs a lot of testing.
>
>@Slava: I highly appreciate your feedback!
I haven't used connman with VPN, unfortunately for this is not a use case
in our application. So I believe there are a lot of other projects out there
that have similar setups to ours - simple in nework topology, but needing
a network manager trying its best to keep you connected. Those would really
only benefit from the proposed change.
Best,
Aleksandar
Aleksandar Mitev (3):
Added timeout to socket connections
Added logic to perform perpetual online checks
Defined a compile time config of perpetual online check
README | 10 ++++++
configure.ac | 6 ++++
gweb/gweb.c | 32 +++++++++++++++++++
src/service.c | 87 ++++++++++++++++++++++++++++++++++++++++++++++++---
4 files changed, 131 insertions(+), 4 deletions(-)
--
2.17.1