On 01/16/2014 09:32 AM, Patrik Flykt wrote: > 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.
That is true. I went this direction because it looked to me as simplest approach for finding a service which should be connected. > 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. The auto connection algorithm doesn't not yet do anything with this additional information. > Then again some other sessions do prefer > ethernet_0080c8383895_cable. So the autoconnect mechanism needs to be > smart when selecting particular services. Yes, the algorithm is not smart yet but I have left this out on purpose. This is something for later. > 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. This is that is working. There is absolutely no matching in FilterBearers in this respect. You can look at it like a new bearer type. The same goes for the service identifier in the AllowedBearers. Bearer types and services names are considered the same in this version. We might want to have some smarter logic here later on. Note if you write something like AllowedBearers=ethernet_0080c8383895_cable ethernet would just mean if ethernet_0080c8383895_cable is around it would be prefered over any other ethernet device that is all. > 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 don't follow you here. There is no direct connection between FilterBearers and the routing table. FilterBearers says just tells auto_connect_service() no ethernet_0080c8383895_cable for the session. There is no special handling for FitlerBearers except that if auto_connect_service() decides to pick ethernet_0080c8383895_cable then the session with FilterBearers=ethernet_0080c8383895_cable just stays idle. No magic :) > 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. FilterBearers is crucial for some setups where we are unable to distinguish different devices/modems based on the bearer type only. The named services and filter bearers feature is necessary. The hairy decisions stuff can't be avoided, we need to face it. Now. >> 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. We will see how much cycles this will save. It depends on the work load. If auto connect is run seldom and at the same time we have a lot of wifi scan updates it is probably cheaper. On the other hand if we have auto connect running often then probably not. >> 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. And this is what my patches do. They translate the way to simple 'active_session[service->type]' into a service-session list. service.c just ask session.c 'hey, sessions.c do is there any connect request? And if yes, if I pick ethernet_0080c8383895_cable is any session interested in this?' >> 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. But you can't have both. Having service.c session agnostic and service.c knowing about session configuration. daniel _______________________________________________ connman mailing list [email protected] https://lists.connman.net/mailman/listinfo/connman
