Hi,
Today we had a discussion on IRC about Session API related topics such as
identification, configuration and enforcement. As it seems I did a bad
job trying to explain what I am trying to solve. So let me have another
attempt.
The main use case behind is to able to control the amount of traffic
each application is allowed to generate. In the end it comes down to
costs. Traffic means costs. Before going to the use case let's have
some 'preconditions'.
There are two ways how a session could be configured. The first
is that the application does it own its own. Surely a valid
way. A second way is to have a global configuration database
and the a session is configured automatically during creation.
This has the benefit that ConnMan has to option to enforce
the settings. So for explaining the use case I assume we have
such a configuration database and ConnMan does the auto
configuration of the session (e.g. sets the AllowedBearers).
Another side condition is that the database is only allowed
to be updated using the build-in modem (see below).
Another precondition is that there several instances of a
binary, e.g. a browser: one instance access the manufacture's
portal side and the other the free internet. These two instances
should be distinguished.
Furthermore, there are different uplinks available. A build-in
modem (with a SIM the manufacturer is paying for), wifi device
and a customer's phone (e.g. BT PAN).
An updated configuration database is maintain by the car
manufacturer in the internet.
Probably I have forgotten some details but hopefully you
get the general idea. So here we go the use case:
- The application wants online connectivity and ask
the connection manager for an uplink. The connection
manager checks if the application is allowed to do
so and establishes a connection.
Yes that is pretty simple though the configuration database
has to be up to date. If it is not, the update should
be triggered in front. I have tried to put that into
following sequence diagrams. I am pretty sure I got things
wrong and there are many things missing in the diagram.
Note, these diagrams are not though to be a design
proposal. They should only explain what should happen when.
So no hard words please :)
+-----------------+ +-----------+ +-------+
+------------------+
| Application | | Session | |ConnMan| |
Configuration DB |
+-------+---------+ +------+----+ +---+---+
+---------+--------+
| | | |
| CreateSession() | |
+-------------------------------------->+----+ |
| | | | IdentifyApp() |
| | |
| | <-----+ |
| | | GetConfigForApp() |
| | +-------------------------->
| | | |
| | CreateSession(with Config) |
| |<-------------+ |
| | | |
| CreateSession(): return session path| |
<--------------------------------------+ |
| | | |
| | | |
+-----------------+ +-----------+ +-------+ +---------+
+-------------+
| Application | | Session | |ConnMan| | Session |
| Config DB |
+-------+---------+ +------+----+ +---+---+ +-----+---+
+-------+-----+
| | | |
|
| | | |
|
| Connect() | | |
|
|---------------------->| | |
|
| +-----+ | |
|
| | |SelectService() |
|
| |<----+ | |
|
| | |
getUpdatedSettings() |
|
+-------------------------------------------------------->|
| | | |
|
| | | |
Connect() |
| | |
+-----+<---------------------+
| | | | |
|
| | | SelectService() |
|
| | | +---->|
|
| | | ServiceConnect()|
|
| | |<------------------+
|
| | | |
|
| | | Service.Online |
|
| | |+----------------->|
Session.Online |
| | |
+--------------------->+-----+
| | | |
| |
| | | |
UpdateDB() |
| | | |
| |
| | | |
Disconnect() |<----+
| | |
|<---------------------+
| | | getUpdateSettings(): return
settings |
|
|<--------------------------------------------------------+
| | | |
|
| |+---+ | |
|
| | |ReSelectService() |
|
| | | | |
|
| |<---+ | |
|
| | Service.Connect() |
|
| +------------->| |
|
| | | |
|
| | Service.Online() |
|
| Online |<-------------+ |
|
<-----------------------+ | |
|
| | | |
|
| | | |
|
| | | |
|
Some final remarks: Traffic accounting should be done, application instances
should be uniquely identified and the access should be enforced. These are the
things I would like to solve. Let's have some more discussions on this tomorrow.
cheers,
daniel
_______________________________________________
connman mailing list
[email protected]
http://lists.connman.net/listinfo/connman
