Also add it to MeeGo-dev for feedback. :-)
-----Original Message-----
From: [email protected] [mailto:[email protected]] On
Behalf Of Marcel Holtmann
Sent: Tuesday, September 14, 2010 9:53 AM
To: [email protected]
Subject: RFC: Advanced session handling for applications
Hello everybody,
so while talking with various people about different application use
cases for various verticals it became clear that we need a bit more
advanced session handling.
We can not just have all applications going of crazy when ConnMan
signals online state. We need to serialize them on low throughput
connections. And also the case where we switch from one bearer to
another one needs to be signaled. And even the switching should happen
nicely serialized in a priority order.
Also we might have applications that only care about a specific bearer
being active and online. If not they will sleep. Waking them up on every
bearer change is rather pointless and wasteful.
There are many more examples where we need application specific session
handling and centralize all decisions inside ConnMan. And registered
application only get notified if something changed that is of their
interest.
I toyed with various approaches for a while now. The goal is to make it
simple for the application from an API and usage point of view, but also
ensure that is is 100% race free. And in addition that the load these
application cause on D-Bus message bus is limited. Some conditions might
cause a higher work, but others might decrease the wakeup of unrelated
applications.
Simple idea is that every application can create one (or even multiple)
session objects. These object are unique for the application that
creates them. At the same time the application has to give a
notification agent that ConnMan can use to inform about specific
changes.
+ object CreateSession(dict settings, object notifier)
+
+ Create a new session for the application. Every
+ application can create multiple session with
+ different settings. The settings are described
+ as part of the session interface.
+
+ The notifier allows asynchronous notification about
+ session specific changes. These changes can be
+ for online/offline state or IP address changes or
+ similar things the application is required to
+ handle.
+
+ Every application should at least create one session
+ to inform about its requirements and it purpose.
+
+ void DestroySession(object session)
+
+ Remove the previously created session. The notifier
+ will be informed via its release method.
+
+ If an application exits unexpectatly the session
+ will be automatically destroyed.
The above changes are for manager-api.txt and pretty simple straight
forward. They will replace RequestSession and ReleaseSession method
currently present.
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. Like a vendor bearer with a specific SIM
card or something alike.
This of course means that ConnMan first has to get support for vendor
specific bearer, but that seems to be an interesting feature anyway.
The notification agent is rather simple. It just will tell the
application when settings of the session have changed. The idea to do
this via an agent is to ensure it is race free and that only the
specific application gets woken up.
Service unique name
Interface org.moblin.connman.Notification
Object path freely definable
Methods void Release()
This method gets called when the service daemon
unregisters the session. A counter can use it to do
cleanup tasks. There is no need to unregister the
session, because when this method gets called it has
already been unregistered.
void Update(dict settings)
Sends an update of changed settings. Only settings
that are changed will be included.
Initially on every session creation this method is
called once to inform about the current settings.
Service org.moblin.connman
Interface org.moblin.connman.Session
Object path variable
Methods void Destroy()
Close the current session. This is similar to
DestroySession method on the manager interface. It
is just provided for convenience depending on how
the application wants to track the session.
void Connect()
If not connected, then attempt to connect this
session.
The usage of this method depends a little bit on
the model if the application. Some application
should not try to any session at all. They should
just monitor if it becomes online or gets back
offline.
Others might require an active connection right now.
So for example email notification should only check
for new emails when a connection is available. However
if the user presses the button for get email or wants
to send an email it should request to get online with
this method.
Depending on the bearer settings the current service
is used or a new service will be connected.
This method returns when the connection has been
established and it is online. Additionally an update
notification with the IP settings is sent.
It is also not guaranteed that a session stays online
after this method call. It can be take offline at any
time. This might happen because of idle timeouts or
other reasons.
It is safe to call this method multiple times. The
actual usage will be sorted out for the application.
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.
void Change(string name, variant value)
Change the value of a certain settings. Not all
settings can be changed. Normally this should not
be needed or an extra session should be created.
However in some cases it makes sense to change
a value and trigger different behavior.
A change of a setting will cause an update notification
to be sent. Some changes might cause the session to
be moved to offline state.
Settings string Bearer [readonly]
This indicates the current bearer that is used
for this session. Or an empty string if no bearer
is available.
boolean Online [readonly]
This indicates if the connection is online or
offline.
This maps to the online service state. And it is
only valid for the selected bearer configuration.
Otherwise it will be reported as offline even if
the global state would be online.
In addition the Online settings notification might
not happen right away. Notifications of online state
can be delayed based on the speed of the bearer. It
is done to avoid congestion on bearers like 3G etc.
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.
The priority handling is done internally by usage
and first come, first serve order. By default this
settings is of course false.
Internally there can be different priorities for
different application, but these are defined by a
configuration file and not via this interface.
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.
This actual priority order also depends on the
allowed bearers and other factors. This is setting
is just a little indicator of one application being
notified before another one.
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?
string Description [readonly]
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.
dict IPv4 [readonly]
Current IPv4 configuration. This settings is only
valid when online is true as well. Otherwise an
empty dictionary is reported.
dict IPv6 [readonly]
Current IPv6 configuration. This settings is only
valid when online is true as well. Otherwise an
empty dictionary is reported.
dict Proxy [readonly]
Current proxy configuration. This settings is only
valid when online is true as well. Otherwise an
empty dictionary is reported.
boolean AvoidHandover [readwrite]
By default this settings is false. It can be used
to indicate that a handover is currently not a good
idea. However no connection is guaranteed. So a
handover can happen anyway. This is just an indication
that the application would like to avoid it right now.
It is a bad idea to always enable this settings and
actually it will be reset after a while to avoid
congestion.
Main use case it for application that are currently
doing a specific tasks that it prefers to finish
before allowing handovers again. An example would
be sychronization.
Never the less application needs to be aware that
handovers can happen at any time even if this is
set to true.
boolean StayConnected [readwrite]
This disables the idle timeout for this session. There
is no guarantee and this should be used with care.
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.
Some of these session settings are obvious and others need a bit more
thinking about it. This is just an initial idea to cover as many
requirements as currently known.
Please comment as much as possible.
Regards
Marcel
_______________________________________________
connman mailing list
[email protected]
http://lists.connman.net/listinfo/connman
_______________________________________________
MeeGo-dev mailing list
[email protected]
http://lists.meego.com/listinfo/meego-dev
