From: Aleksandar Mitev <shondll(a)yahoo.com>
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
> 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.
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(-)