Hi,
On Tue, 2010-12-07 at 15:50 +0100, ext Daniel Wagner wrote:
> For telling ConnMan 'I'm a very importat application' we have
> introduced the EmergencyCall setting. Only _one_ application is
> allowed to write it (e.g. protected by policykit rules). If this
> application decides that an emergency call should happen than ConnMan
> will block all connection but the one of ecall application. This is
> done via a unique session marker which ConnMan will give to each
> application. This marker can then be used for SO_MARK. ConnMan will
> update the iptables to pass only traffic from the ecall application.
As discussed yesterday on IRC, for ordinary applications we would need
an indication for connections that are started by the applications
themselves. This means e.g. email downloading, checking or fetching OS
updates, etc. non-interactive bulk traffic.
When roaming abroad with GPRS (or at home by paying per MB), it quickly
becomes very expensive if such bulk downloading happens over GPRS. Thus
from the handset point of view we definitely want an indication of a
"lower priority" network connection attempt that need not be always
allowed by ConnMan. I suspect I would want such a feature for IVI as
well, I don't want my car kit go downloading MBs of data while driving
on the Autobahn. I'd prefer "lower priority" or some similar named
entity here, as it would be difficult to say "lots of data" or "frequent
connections" in the apps, since they would not necessarily know the
first one. Likewise, if some new reason appears, all apps would need to
be updated to set that flag as well. Thus it would be easier to have an
abstraction level of "low importance" or "lower priority" as above.
This will require applications to help out with their share, and the
apps still have to be trusted to get the details mostly right. For Qt
Bearer or other connectivity library purposes, the default setting would
be to have the "low priority" flag on by default in order to minimize
problems.
The enforcement mechanism can be the same as your emergency call with a
different marker.
> With this an application only at the session object to get the all
> needed information for displaying etc.
True.
> > Same guarantees given for StayConnected could be given here.
>
> I don't understand what you mean here. We just found out that it needs
> clarification what is supposed to happen in case where the system is
> not online yet.
Just that the same explanation seemed to fit this part as well. Probably
some clarification needed, though.
> > > uint32 PeriodicConnect [readwrite]
> > Hmm, I think this part should preferably be handled by ConnMan only.
>
> What do you mean with this? The periodic update is to inform the
> 'connection scheduler' in ConnMan to when to go online. So this only
> handled by ConnMan.
>
> > Any numbers supplied could be taken in as hints, but could this part
> > be considered an optimization when we get real apps using the
> > Session API?
>
> Yes, that's what is supposed to be.
Yes, that's what I meant. I'll check RFC v0 as well.
Cheers,
Patrik
_______________________________________________
connman mailing list
[email protected]
http://lists.connman.net/listinfo/connman
