On Wed, 2014-01-15 at 16:35 +0100, Daniel Wagner wrote:
> Hi Patrik,
>
> On 01/15/2014 12:09 PM, Patrik Flykt wrote:
> > On Tue, 2014-01-14 at 13:47 +0100, Daniel Wagner wrote:
> >> When a service is created it wont be announced that it exist via
> >> service_state_changed(), there is create state event. The same goes
> >> for the removal.
> >
> > Why does session care about each individual service?
>
> Here is what needs to work:
>
> AllowedBearers=wifi_6003089c5c40_4775657374576c616e_managed_psk
> FilterBearers=ethernet_0080c8383895_cable
>
> So the first one says, only and only pick the service. The second one
> says never ever use this one.
In order for this to work, it doesn't mean that the session should
recreate the service hash.
The only thing that is needed in the future is that the autoconnect
should be informed that ethernet_0080c8383895_cable is a less preferred
network for some sessions. Then again some other sessions do prefer
ethernet_0080c8383895_cable. So the autoconnect mechanism needs to be
smart when selecting particular services.
The thing that needs to be ensured when implementing 'FilterBearers' is
that if ethernet_0080c8383895_cable is the only ethernet around and the
ethernet type is requested by N >= 1 other sessions,
ethernet_0080c8383895_cable is going to be connected. Or if some
sessions have especially requested ethernet_0080c8383895_cable, the
service needs also to be connected.
For that particular session which has set
FilterBearers=ethernet_0080c8383895_cable, ethernet_0080c8383895_cable
is not announced and the session routing table is _not_ updated with the
details of this ethernet service. This needs to be handled in the
session code, as service.c autoconnect is there trying to balance
between the conflicting world views of the sessions.
I'd like to leave out the FilterBearers part from this patch set and
concentrate on the rest since the FilterBearers feature is somewhat
hairy requiring decisions with conflicting interest between various
sessions.
> Doing lazy has the side nice effect we wouldn't do any work if we get a
> WiFi scan results adding/removing a bunch of networks.
Yes. This would prevent ConnMan for doing the hash mapping twice for no
gain on every service addition and removal. Saves in code duplication,
memory and CPU cycles.
> The downside is
> whenever we trigger auto connect the service-session mapping has to be
> done.
The service "score table" needs to be kept somewhere. The cleanest
approach is to have as much session related code in session.c as
possible. Figuring out what to connect is currently as simple as
checking active_sessions[service->type], which can be wrapped into a
nice function and called from session.c.
> Anyway the reason why the service-session list into session.c is on your
> request[1]. After moving the code to session.c it looks much cleaner. So
> yes I agree with your last request.
That is fine. I don't see the need to recreate a service hash using add
and remove notifiers in session, though.
Cheers,
Patrik
_______________________________________________
connman mailing list
[email protected]
https://lists.connman.net/mailman/listinfo/connman
