Hi Patrik,
As you are surely aware, we have discuessed this proposal offline
during the Munich meeting. There are a few changes to this
proposal. I'll send soon an update. I think we address a few things
you are mentioning.
On Tue, Dec 07, 2010 at 01:29:56PM +0200, Patrik Flykt wrote:
> On Tue, 2010-09-14 at 03:53 +0200, ext Marcel Holtmann wrote:
>
> > We need to serialize them on low throughput
> > connections.
>
> That may work more or less well. What are the low throughput
> connections, is 2G GPRS or ones GPRS subscription bandwidth parameters
> one of them? If so, can we properly obtain them?
>
> The next problem is if the low throughput connection can be maxed out by
> one application only. If yes, no problem, if not then we're wasting more
> power on waiting for applications finishing off their network updates.
>
> Ok, this is kinda premature worrying at this point, serialization is
> good in cases when we understand applications use of Session API better.
We concluded that we need to play a bit around with the serializing
idea. It is too early to realy understand the impacts of this idea.
> > The two new interface are Notification and Session of course. Creating a
> > new session doesn't mean that it will be ever connected during the
> > lifetime of an application. In theory it can happen that an application
> > request a session for a specific bearer and the required hardware is not
> > even attached to the system.
>
> If we know we can't hotplug the hardware in question, should we fail
> with an error instead?
I don't we should fail. Creating a session should always work. A
manual 'Connect' call can fail.
> > void Connect()
>
> > This method returns when the connection has been
> > established and it is online.
>
> This needs the D-Bus timeout to be properly set in the application,
> otherwise the application timeouts before ConnMan, which again is not
> bad but perhaps undesirable.
Sure, but nothing we can fix here.
> > void Disconnect()
>
> > This method indicates that the current session does
> > not need a connection anymore.
> >
> > In most cases this method returns right away without
> > any delays. However in some cases it might take a few
> > seconds before a connection can be terminated.
>
> ConnMan should not close the connection if there are other Sessions
> active for the same connection, right? I assume that in this case this
> method call returns immediately, if ConnMan closes the connection it
> will take a few seconds more? Or actually, ConnMan could return almost
> immediately anyway, and start closing the connection after that if it is
> not needed by other Session anymore (or after a timeout, yet another
> later optimization).
The connection is refcounted and only closed when there is no
application left wanting to be online. ConnMan will return immediatly.
> > boolean Priority [readwrite]
> >
> > This allows a session to mark itself as priority or
> > not. In general application are not allowed to make
> >
> > themselves more important than others.
>
> I would like to use this to inform ConnMan when an application really
> needs a connection "now" due to e.g. UI actions or whether the
> application merely hints that it could make use of a connection if there
> are no additional constraints. A constraint could be roaming in 3G which
> still costs a lot of money. For example an email application should set
> Priority to FALSE if it goes checking for email in the background and
> TRUE if the user clicks on the "Sync email now" button in the email UI.
> Thus timer based email checking/syncing would not be allowed when
> roaming in GPRS in order to avoid money loss added to the GPRS roaming
> bill and only the "Sync email now" button presses would force the
> connection on when roaming (with resulting money loss but that's what
> the user wanted).
We talked quite a bit about the Priority/Realtime setting. First, we
concluded that it should be labled as Realtime. The 'I'm more
important' will be removed and instead only the streaming idea
stays. So application just tellConnMan, 'please don't roam to another
network if possible'.
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.
If an application wants to be online it should call Connect or
Disconnect directly. No need to hide this behind this setting.
> > An application that calls the method to connect
> > a session is preferred over other sessions. This
> > priority value is more for application that wanna
> > push themselves up in the asychronization notification
> > queue once a bearer becomes online.
>
> That can be an effect of Priority as well.
>
> > For example a streaming session should set the
> > priority value. As soon as realtime data is involved
> > then this should be set. An email client should not
> > set this value.
> >
> > FIXME: Should this be renamed to Realtime?
>
> This part sounds like another equally well needed setting to me. It's
> not clear to me how this combines with the ordering and importance
> described earlier.
I hope I address this above.
> > array{string} AllowedBearers [readwrite]
> >
> > A list of bearers that can be used for this session.
> > In general this list should be empty to indicate that
> > any bearer is acceptable.
>
> Would it be easier for the application with only a bearer type (WLAN,
> GPRS, WiMAX, etc) specified here? How does the average application
> developer decide which bearers he can use?
As we disscused this already on the mailing list, the bearer concept
will be a bit more flexible and not only allow technologies as bearer
names. So it will be possible to name a VPN setting, e.g. MY_SERVICE
which is provisined as a vpn tunnel. And of course, something like '*'
is allowed.
> > dict Proxy [readonly]
> >
> > Current proxy configuration. This settings is only
> > valid when online is true as well. Otherwise an
> > empty dictionary is reported.
>
> Should we keep proxy handling with libproxy and pacrunner?
With this an application only at the session object to get the all
needed information for displaying etc.
> > boolean StayConnected [readwrite]
> >
> > This disables the idle timeout for this session. There
> > is no guarantee and this should be used with care.
>
> 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.
> > uint32 PeriodicConnect [readwrite]
> >
> > Indicate that a periodic connection attempt every
> > n minutes should be made. The minutes value is a
> > suggestion when to connection. There is not guarantee
> > that it will be made of succeeds. A value of 0 disable
> > this feature.
> >
> > This feature is interesting for applications that
> > wanna check status on a regular interval. And instead
> > of the application waking up and trying to connect,
> > this can be centralized nicely and multiple wakeups
> > avoid in case no connection is available.
> >
> > An example application would be an email client that
> > wants to check for new emails every 10 minutes.
> >
> > On purpose the smallest setting is 1 minute here since
> > waking up more often and trying to set up a connection
> > seems rather pointless use case.
> >
> > If an interval step has passed this can be nicely
> > rescheduled when any connection matching the bearer
> > settings becomes available becomes available. Using
> > this feature it is also easy to avoid congestions.
>
> 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.
cheers,
daniel
_______________________________________________
connman mailing list
[email protected]
http://lists.connman.net/listinfo/connman
