Re: [RFC v1 1/3] session: Update Session API
Hi Patrik, On 10/12/2011 10:29 AM, Patrik Flykt wrote: On Tue, 2011-10-11 at 15:33 +0200, Daniel Wagner wrote: The apps do not direclty communicate with the internet. This is done in the Job Dispatcher. Unfortunately I don't see the point with the Job Dispatcher in the picture. If the intention is to further process application messages, that's fine. But then the system better be prepared to be treated to have the Job Dispatcher as the sole source of outgoing traffic - i.e. it is acting as a much glorified proxy. In a proxy case I'd argue the Job Dispatcher is better equipped in setting up the sessions than the individual apps themselves, since the apps don't have the whole traffic pattern painted before them. And, as Jukka shouted over the table, couldn't the Job Dispatcher be the one mapping session based statistics to individual applications instead of ConnMan? After I had a discussion on with Marcel, Denis and Gustavo in person I have to agree, the Identifier is not really helping (read its a stupid idea). And there are other (better) ways to get the problem solved I want to solve. I am sorry if this has lead to very loud discussion in your office. My apology. When we meet I offer some beers for compensation (Munich style). Is that okay? Thanks that you took the time to have this constructive discussion. cheers, daniel ___ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
Re: [RFC v1 1/3] session: Update Session API
On Wed, 2011-10-12 at 15:38 +0200, Daniel Wagner wrote: I am sorry if this has lead to very loud discussion in your office. Nah, shouted was a too colorful expression, no voices raised, only heads up to see the other person over one's monitor. My apology. No apologies needed, since no harm done :-) The point of all the discussion is to bounce ideas back and forth to figure out a good solution for those involved. But beer is good, beer f2f even better! Enjoy! Cheers, Patrik ___ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
Re: [RFC v1 1/3] session: Update Session API
Hi Okay, let's implement the idle time out on a global level then, but keep the per Session IdleTimeout. Is that okay for everyone? If needed we can still change the implementation without the need to change the API. I would definitely prefer that. And let's make the global, bearer-based IdleTimeout prioritized over session's one. There many use case for it. why does anybody think this is a good idea. Please do not think about this from an engineering point of view. Take one step back and think from an application and user experience. Let me make this perfectly clear here. Application should only communicate via the Session API. So please do not try to solve an implementation problem with trying to introduce a new API for it. It is our problem to come up with an efficient implementation and hide the details as best as we can. Just defining an API in a way that makes the implementation simpler is never a good idea. Hum, you missed my point here. Anyway, afaik we agree on the same thing since you said later: A global configuration could always force a lower value. Step away from thinking that we will define and run a timeout for each session. That would be just waste. ;) That's exactly what I was trying to explain (see also the ConnMan's internal solution I proposed earlier that could use IDLETIMER iptables target, this is an internal grobal solution not a per-session one.) And yes, it's up to ConnMan to be smarter, not the API and therefore not the application. Too many experiences where a too uselessly flexible API was badly used by application developers. Now, the issue here is: what use-cases Daniel wants to solve? I personally see this idle timeout from a billing and power management point of view, and due to that: I don't see the need of having a per-session solution. With regards, Tomasz ___ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
Re: [RFC v1 1/3] session: Update Session API
Hi Marcel, On 10/10/2011 05:07 PM, Marcel Holtmann wrote: So coming to your question, the SessionId is used to get the correct configuration. BTW, for our use cases, the most interesting configuration part is the roaming one. So is an application allowed to use a roaming service or not. The application is still able to call Connect()/Disconnect() but it should care about the rest. So the whole configuration part is done under the hood. I personally think we should just use the D-Bus well known name for this part. Making the application give an extra magic cookie seems useless. For those proxy application (e.g. as the mentioned communication middle ware) it is very helpful. Otherwise the whole preconfiguration/provisioning stuff doesn't work and the proxy application has to talk to the configuration database itself. and what exactly is your point here? My point was that we can just use the well known name or if SCM_COMM gets accepted upstream even the programs name to identify it. So any provisioning plugin can do their job properly. Let me try to explain it again. ++ ++ ++ ++ | App 1 | | App 2 | | App 3 | | App 4 | ++ ++ ++ ++ | | | | | | | | AF_UNIX +-+ | Job Dispatcher | +-+ | | | | | | | | AF_INET --- Kernel The proxy thing I tried to explain looks like the picture above. The apps do not direclty communicate with the internet. This is done in the Job Dispatcher. So this middle thing is the owner of the sockets and also communicates through those sockets for the apps. What I'd like to solve is this simple problem, that if the Job Dispatcher creates for each application a session, ConnMan would just only see the Job Dispatcher instead the App 1-4. That is the thing the Identifier should solve. In addition of course the application has to do less work and also can not really fake it and assume a wrong identity. Protecting the SessionId from misuse by malicious application is a bit more work then just relying on some system features. If an application provides the wrong Identifer it just gets the default configuration (no connection for you?) with the enforcement plugin. It is just the handle for looking up a configuration setting. cheers, daniel ___ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
Re: [RFC v1 1/3] session: Update Session API
Hi, On 10/07/2011 04:54 PM, Marcel Holtmann wrote: About the idle timeout I'm not sure we'd need per-session disconnections. If the app does not want or remember to inform ConnMan that it's usage is over, a per-bearer idle timer does the job reasonably well. If the app in question already stopped sending/receiving data, it wouldn't anyway drain any transmission power. Thus ConnMan would easily just count the max of idle timeouts requested by all sessions (and its own view on max allowable) and use that for disconnections. It's also my opinion that IdleTimeout should not be per-session. It does not sound optimized. In Maemo, we were using IDLETIMER target on netfilter to do exactly that kind of job. See: http://kerneltrap.org/mailarchive/linux-netdev/2010/6/15/6279376/thread for more informations. The code has been accepted upstream, so there is no reason not to use it :) So such IdleTimeout should be configurable per-bearer in Manager directly, or something like that. It's imho the way to go: per-session means quite some code running per each sesssion for such timeout handling, when you can have only 1 callback waiting for sysfs notification and that's it if there is a timeout set. that is all an implementation detail on how this gets mapped to the bearer. The point here is to aggregate the idle timeout on a per session since that is all the application is suppose to care about. Nothing of this means that it will executed like this. Think about it from the application point of view. Every application has specific needs at its Internet/Intranet usage and that is what it is suppose to tell us here. Nothing more and nothing less. They are all suggestions towards ConnMan, but the final decision is up to ConnMan. I think the only question we need to ask ourselves is if IdleTimeout is really useful as an application characteristic. Or if it might be enough to just say StayConnected = true/false. I think an IdleTimeout per Session makes sense. It should map to a Service and not to a bearer, BTW. If you have for example a VPN tunnel over a cellular link and the application is only interested in idle timeout in the tunnel. Well, we could of course express this with a global IdleTimeout and then only measure the traffic for the top most Service (e.g. VPN tunnel). I'm still not convinced this is a good idea. What about PeriodicConnect then? One could argue let's do it the same way, one global setting for all application. The admin has just to figure it out the right value. The Session API is there to let application configure at _runtime_. cheers, daniel ___ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
Re: [RFC v1 1/3] session: Update Session API
Hi Daniel, On 10/10/2011 11:13 AM, Daniel Wagner wrote: Hi, I think an IdleTimeout per Session makes sense. It should map to a Service and not to a bearer, BTW. If you have for example a VPN tunnel over a cellular link and the application is only interested in idle timeout in the tunnel. Hmm, perhaps I am not understand the use cases well enough but this session idle timer seems a bit over engineered solution. Lets imagine two scenarios: 1. Each session has an idle timer which closes the session if there are no packets sent during the session. If all the sessions are closed, the network connection is closed also. 2. Each session has no idle timer but a global bearer specific timer is in use. When there is no network traffic in the bearer, the bearer is taken down (like wlan0) so all the sessions using that bearer will be closed. The end result is the same but the 2. is much easier to implement (netfilter has already code for bearer specific idle timer and it was used in maemo). Also in 2. the network connection (like wireless or cellular one) is taken down faster which could help with power consumption and billing. Well, we could of course express this with a global IdleTimeout and then only measure the traffic for the top most Service (e.g. VPN tunnel). I'm still not convinced this is a good idea. What about PeriodicConnect then? One could argue let's do it the same way, one global setting for all application. The admin has just to figure it out the right value. The Session API is there to let application configure at _runtime_. Each app can have its own PeriodicConnect value. Connman would then just get the smallest value and create a connect when necessary. It would be great if we could arrange f2f mini summit to discuss complex issues like these. cheers, daniel Cheers, Jukka ___ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
Re: [RFC v1 1/3] session: Update Session API
Hi Jukka, On 10/10/2011 10:45 AM, Jukka Rissanen wrote: I think an IdleTimeout per Session makes sense. It should map to a Service and not to a bearer, BTW. If you have for example a VPN tunnel over a cellular link and the application is only interested in idle timeout in the tunnel. Hmm, perhaps I am not understand the use cases well enough but this session idle timer seems a bit over engineered solution. Lets imagine two scenarios: 1. Each session has an idle timer which closes the session if there are no packets sent during the session. If all the sessions are closed, the network connection is closed also. 2. Each session has no idle timer but a global bearer specific timer is in use. When there is no network traffic in the bearer, the bearer is taken down (like wlan0) so all the sessions using that bearer will be closed. The end result is the same but the 2. is much easier to implement (netfilter has already code for bearer specific idle timer and it was used in maemo). Also in 2. the network connection (like wireless or cellular one) is taken down faster which could help with power consumption and billing. Okay, let's implement the idle time out on a global level then, but keep the per Session IdleTimeout. Is that okay for everyone? If needed we can still change the implementation without the need to change the API. Well, we could of course express this with a global IdleTimeout and then only measure the traffic for the top most Service (e.g. VPN tunnel). I'm still not convinced this is a good idea. What about PeriodicConnect then? One could argue let's do it the same way, one global setting for all application. The admin has just to figure it out the right value. The Session API is there to let application configure at _runtime_. Each app can have its own PeriodicConnect value. Connman would then just get the smallest value and create a connect when necessary. It would be great if we could arrange f2f mini summit to discuss complex issues like these. Good idea. Who is attending the LinuxCon Europe conference? cheers, daniel ___ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
Re: [RFC v1 1/3] session: Update Session API
Hi, The end result is the same but the 2. is much easier to implement (netfilter has already code for bearer specific idle timer and it was used in maemo). Also in 2. the network connection (like wireless or cellular one) is taken down faster which could help with power consumption and billing. Okay, let's implement the idle time out on a global level then, but keep the per Session IdleTimeout. Is that okay for everyone? If needed we can still change the implementation without the need to change the API. I would definitely prefer that. And let's make the global, bearer-based IdleTimeout prioritized over session's one. There many use case for it. Tomasz ___ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
Re: [RFC v1 1/3] session: Update Session API
On Mon, 2011-10-10 at 11:11 +0200, Daniel Wagner wrote: Okay, let's implement the idle time out on a global level then, but keep the per Session IdleTimeout. Is that okay for everyone? Did you mean the value is readable from the per-session IdleTimeout attribute? For setting the value of IdleTimeout, the application would need more administrative powers than normal. The timeout value may need to be adjusted by input from power management and GSM/3G roaming status. Otherwise a 3rd party application could erroneously set the idle timer to 1h or more regardless of the device roaming status. Cheers, Patrik ___ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
Re: [RFC v1 1/3] session: Update Session API
On 10/10/2011 11:31 AM, Patrik Flykt wrote: On Mon, 2011-10-10 at 11:11 +0200, Daniel Wagner wrote: Okay, let's implement the idle time out on a global level then, but keep the per Session IdleTimeout. Is that okay for everyone? Did you mean the value is readable from the per-session IdleTimeout attribute? Yes. For setting the value of IdleTimeout, the application would need more administrative powers than normal. The timeout value may need to be adjusted by input from power management and GSM/3G roaming status. Otherwise a 3rd party application could erroneously set the idle timer to 1h or more regardless of the device roaming status. And that's where the provisioning and enforcement comes into play. cheers, daniel ___ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
Re: [RFC v1 1/3] session: Update Session API
Hi Daniel, So coming to your question, the SessionId is used to get the correct configuration. BTW, for our use cases, the most interesting configuration part is the roaming one. So is an application allowed to use a roaming service or not. The application is still able to call Connect()/Disconnect() but it should care about the rest. So the whole configuration part is done under the hood. I personally think we should just use the D-Bus well known name for this part. Making the application give an extra magic cookie seems useless. For those proxy application (e.g. as the mentioned communication middle ware) it is very helpful. Otherwise the whole preconfiguration/provisioning stuff doesn't work and the proxy application has to talk to the configuration database itself. and what exactly is your point here? My point was that we can just use the well known name or if SCM_COMM gets accepted upstream even the programs name to identify it. So any provisioning plugin can do their job properly. In addition of course the application has to do less work and also can not really fake it and assume a wrong identity. Protecting the SessionId from misuse by malicious application is a bit more work then just relying on some system features. Regards Marcel ___ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
Re: [RFC v1 1/3] session: Update Session API
Hi Tomasz, The end result is the same but the 2. is much easier to implement (netfilter has already code for bearer specific idle timer and it was used in maemo). Also in 2. the network connection (like wireless or cellular one) is taken down faster which could help with power consumption and billing. Okay, let's implement the idle time out on a global level then, but keep the per Session IdleTimeout. Is that okay for everyone? If needed we can still change the implementation without the need to change the API. I would definitely prefer that. And let's make the global, bearer-based IdleTimeout prioritized over session's one. There many use case for it. why does anybody think this is a good idea. Please do not think about this from an engineering point of view. Take one step back and think from an application and user experience. Let me make this perfectly clear here. Application should only communicate via the Session API. So please do not try to solve an implementation problem with trying to introduce a new API for it. It is our problem to come up with an efficient implementation and hide the details as best as we can. Just defining an API in a way that makes the implementation simpler is never a good idea. Regards Marcel ___ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
Re: [RFC v1 1/3] session: Update Session API
Hi Patrik, Okay, let's implement the idle time out on a global level then, but keep the per Session IdleTimeout. Is that okay for everyone? Did you mean the value is readable from the per-session IdleTimeout attribute? For setting the value of IdleTimeout, the application would need more administrative powers than normal. The timeout value may need to be adjusted by input from power management and GSM/3G roaming status. Otherwise a 3rd party application could erroneously set the idle timer to 1h or more regardless of the device roaming status. as I said, this is and will always be just a hint. A global configuration could always force a lower value. And for the roaming policies, that becomes a bit more trickier once we dig into this. And only a few countries charge (or count your budget) against the minutes. For most roaming charges it counts by the KB, so the time argument is kinda mood. However yes, the roaming policies need to be a bit more smart. Here again it is our problem to solve this internally and not bother the application with details. If ConnMan thinks the IdleTimeout that has been set by application makes no sense, it just overwrites it. Regards Marcel ___ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
Re: [RFC v1 1/3] session: Update Session API
Hi,
Here some questions about the Session API proposal. I admit don't get
the whole picture, and I'm missing all of your use cases. However, I
would not want to add any more complexity into ConnMan than what is
necessary.
On Thu, 2011-10-06 at 18:46 +0200, Daniel Wagner wrote:
+ string SessionId [readwrite]
+
+ Applications which want to get a preconfigured
+ session can pass in a ID with Manager.CreateSession().
Preconfigured session? If applications don't know anything about
sessions, would it be better to just go with free ride and let someone
else do the connecting and disconnecting?
+ This ID is used to retrieve all settings from the
+ configuration plugin.
Shouldn't session properties be a part of the application configuration,
be it that they could be read from a platform wide settings repository?
+ array{string, dict} BearerSettings [readwrite]
+
+ In case that an application needs to define settings
+ depending on the bearer, BearerSettings allows to
+ overwrite the sessions global settings.
+
+ For example the PeriodicConnect value might be different
+ for wifi and cellular bearer type, the application can
+ overwrite the session global PeriodicConnect here.
Why not having two sessions?
+Configuration and Provisioning of Sessions
+==
+
+There are two ways how an application can configure a session.
+
+The first one is to pass in all settings as a dictionary to
+Manager.CreateSession(). This is useful for an application who wants to
+maintain and store its own settings. Or after creating the session with
+Manager.CreateSession() write the settings one after the other.
Ok.
+For applications which do not want to care of maintaining and storing
+settings ConnMan supports a configuration plugin.
I don't think this should happen. Are we suddely low on disk space or
what? Why isn't free ride useful, if the application doesnt' want to
maintain any settings at all? It would be much easier on ConnMan that
applications would use global session preferences than to have ConnMan
acting as a configuration database.
+PeriodicConnect and IdleTimeout
+---
+
+If an application wants to go online periodically (e.g. check for new
+mails) then the application should use PeriodicConnect instead of
+calling Session.Connect() periodically. There is no need for the
+application to maintain timers. ConnMan is also able to try to combine
+several PeriodicConnect calls into one. Applications can not rely on a
+very precise periodic connect. Apart of merging periodic connect
+timeouts there is also the problme that no service might be available
+at that point and ConnMan will defer the connect call.
That I agree on.
+For example in one use case there are two cellular uplinks A and B
+available.
Unless you modify Session API to be able to specify individual services,
this already works by requesting a cellular bearer. Either A or B would
then be connected. If Session API is modified to use individual
services, then the app better be sure what it wants from services A and
B! If it doesn't, it goes back to square one and requests a bearer type.
+The BearerSettings allow to overwrite the session settings. The
+session settings could be considered as the common configuration among
+all bearers and the BearerSetting allow to overwrite certain settings.
Hmm. I could be wrong, but this somehow looks like sub-sessions inside
sessions. I'm not sure it'll make ConnMan simpler to maintain.
+There is no good way to identify an application.
D-Bus IDs? What would the use case be for identifying an application?
+For use cases where an
+application is acting as a proxy for other applications it needs a way
+to tell which configuration should be looked up.
What would such an use case be in real life?
My experience with OSSO/Maemo application connectivity was that it just
got simpler as time passed. In the end the applications did not want and
would not handle anything complex. All they needed was a bearer type and
whether they got connected or not. In Maemo there was no reason given
either (much to the dismay of some apps, IMHO) since connectivity errors
needing user input were transparently handled and global connectivity
was indicated in the status area. I've never seen anyone implementing
apps to want anything else than the simplest connectivity experience
possible.
About the idle timeout I'm not sure we'd need per-session
disconnections. If the app does not want or remember to inform ConnMan
that it's usage is over, a per-bearer idle timer does the job reasonably
well. If the app in question already stopped sending/receiving data, it
wouldn't anyway drain any transmission
Re: [RFC v1 1/3] session: Update Session API
Hi Patrik
Thanks for taking time reading my proposal.
On 10/07/2011 11:32 AM, Patrik Flykt wrote:
Here some questions about the Session API proposal. I admit don't get
the whole picture, and I'm missing all of your use cases.
I feared I failed to explain it good enough. Hopefully I can clarify
some things.
However, I
would not want to add any more complexity into ConnMan than what is
necessary.
I absolutely agree. So my proposal tries to only to add stuff which is
really needed.
On Thu, 2011-10-06 at 18:46 +0200, Daniel Wagner wrote:
+string SessionId [readwrite]
+
+Applications which want to get a preconfigured
+session can pass in a ID with Manager.CreateSession().
Preconfigured session? If applications don't know anything about
sessions, would it be better to just go with free ride and let someone
else do the connecting and disconnecting?
There are a few reasons behind why ConnMan should also support
preconfiguration and provisioning and not only rely on the applications.
The following reasoning is based on the IVI use cases. We have an
architecture in mind for supporting them. Let me try to explain it.
We have a central database for (all sorts of) configurations. This
configuration might change at anytime. Furthermore, we want to enforce
those configuration on applications. The idea behind this is that if we
would have 3rd party application we don't have really control over them
we still can make sure they don't go too wild.
The way the configuration is set to the session is not the killer
argument for having ConnMan to do it. The main argument for is how you
want to enforce these settings. There are two ways to do it.
First one is we would introduce a proxy between ConnMan and any
application which intercepts the Session API calls. We rather don't like
to do this, because you introduce a lot of unnecessary runtime
dependencies and also double the D-Bus communication.
Second one is ConnMan does this itself. This feature should be
implemented through a plugin.
I have discussed this with Marcel offline and he also suggested to move
this enforcement part into ConnMan.
So coming to your question, the SessionId is used to get the correct
configuration. BTW, for our use cases, the most interesting
configuration part is the roaming one. So is an application allowed to
use a roaming service or not. The application is still able to call
Connect()/Disconnect() but it should care about the rest. So the whole
configuration part is done under the hood.
+This ID is used to retrieve all settings from the
+configuration plugin.
Shouldn't session properties be a part of the application configuration,
be it that they could be read from a platform wide settings repository?
Yes there will be a platform wide setting repository (aka configuration
database). As I said the application could do but still we want to
enforce it. So we would have at least each session two accesses to the
repository. And also the application should then monitor changes on the
repository. This sounds rather simple but it is quite complicated. It
has much in common with the PACrunner.
For example imagine you drive with your car from Germany to Switzerland.
After passing the boarder you decide to use some web application (web
browser). The application requests a connection.
Following things have to happen:
- Connect to the internet using the build in modem (and SIM)
- Fetch the current configuration for Switzerland
- Update configuration database
- Update all sessions configuration
- If the application is allowed to use the current link through the
build in modem, set its session online
- If the application is allowed to go online but using a different path,
close the current link, and connecting the other online path
- If the application is not allowed to go online, stop here.
This looks very similar to PACrunner. When a service is connecting, we
stop the state machine at Connected, ask PACrunner to update its
configuration. When PACRunner is ready it triggers the service state
machine to go Online.
The same thing should be done for Sessions. So the application triggers
Session.Connect(), ConnMan tries to connect the build in modem and stops
the state machine in Connected. Then it triggers the configuration
update, waits for the update done event, evaluates the new situation and
then either selects a new service for the session or uses the build in
modem.
+array{string, dict} BearerSettings [readwrite]
+
+In case that an application needs to define settings
+depending on the bearer, BearerSettings allows to
+overwrite the sessions global settings.
+
+For example the PeriodicConnect value might be different
+for wifi and cellular bearer type, the application can
+overwrite
Re: [RFC v1 1/3] session: Update Session API
Hi Patrik, + + Applications which want to get a preconfigured + session can pass in a ID with Manager.CreateSession(). Preconfigured session? If applications don't know anything about sessions, would it be better to just go with free ride and let someone else do the connecting and disconnecting? + This ID is used to retrieve all settings from the + configuration plugin. Shouldn't session properties be a part of the application configuration, be it that they could be read from a platform wide settings repository? this sounds a bit fishy. Especially with the read-write support of this setting. Why would anybody change this later on? And btw. repeating Session in a property name is also bad if the interface already is related to this. So just Identifier or something else would be better. Regards Marcel ___ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
Re: [RFC v1 1/3] session: Update Session API
Hi Tomasz, About the idle timeout I'm not sure we'd need per-session disconnections. If the app does not want or remember to inform ConnMan that it's usage is over, a per-bearer idle timer does the job reasonably well. If the app in question already stopped sending/receiving data, it wouldn't anyway drain any transmission power. Thus ConnMan would easily just count the max of idle timeouts requested by all sessions (and its own view on max allowable) and use that for disconnections. It's also my opinion that IdleTimeout should not be per-session. It does not sound optimized. In Maemo, we were using IDLETIMER target on netfilter to do exactly that kind of job. See: http://kerneltrap.org/mailarchive/linux-netdev/2010/6/15/6279376/thread for more informations. The code has been accepted upstream, so there is no reason not to use it :) So such IdleTimeout should be configurable per-bearer in Manager directly, or something like that. It's imho the way to go: per-session means quite some code running per each sesssion for such timeout handling, when you can have only 1 callback waiting for sysfs notification and that's it if there is a timeout set. that is all an implementation detail on how this gets mapped to the bearer. The point here is to aggregate the idle timeout on a per session since that is all the application is suppose to care about. Nothing of this means that it will executed like this. Think about it from the application point of view. Every application has specific needs at its Internet/Intranet usage and that is what it is suppose to tell us here. Nothing more and nothing less. They are all suggestions towards ConnMan, but the final decision is up to ConnMan. I think the only question we need to ask ourselves is if IdleTimeout is really useful as an application characteristic. Or if it might be enough to just say StayConnected = true/false. Regards Marcel ___ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
Re: [RFC v1 1/3] session: Update Session API
Hi Daniel,
Here some questions about the Session API proposal. I admit don't get
the whole picture, and I'm missing all of your use cases.
I feared I failed to explain it good enough. Hopefully I can clarify
some things.
However, I
would not want to add any more complexity into ConnMan than what is
necessary.
I absolutely agree. So my proposal tries to only to add stuff which is
really needed.
I think it might be good even split updates for the documentation into
one or two per patch. That makes it easier to comment on these without
loosing the context.
On Thu, 2011-10-06 at 18:46 +0200, Daniel Wagner wrote:
+ string SessionId [readwrite]
+
+ Applications which want to get a preconfigured
+ session can pass in a ID with Manager.CreateSession().
Preconfigured session? If applications don't know anything about
sessions, would it be better to just go with free ride and let someone
else do the connecting and disconnecting?
There are a few reasons behind why ConnMan should also support
preconfiguration and provisioning and not only rely on the applications.
The following reasoning is based on the IVI use cases. We have an
architecture in mind for supporting them. Let me try to explain it.
We have a central database for (all sorts of) configurations. This
configuration might change at anytime. Furthermore, we want to enforce
those configuration on applications. The idea behind this is that if we
would have 3rd party application we don't have really control over them
we still can make sure they don't go too wild.
The way the configuration is set to the session is not the killer
argument for having ConnMan to do it. The main argument for is how you
want to enforce these settings. There are two ways to do it.
First one is we would introduce a proxy between ConnMan and any
application which intercepts the Session API calls. We rather don't like
to do this, because you introduce a lot of unnecessary runtime
dependencies and also double the D-Bus communication.
Second one is ConnMan does this itself. This feature should be
implemented through a plugin.
I have discussed this with Marcel offline and he also suggested to move
this enforcement part into ConnMan.
So coming to your question, the SessionId is used to get the correct
configuration. BTW, for our use cases, the most interesting
configuration part is the roaming one. So is an application allowed to
use a roaming service or not. The application is still able to call
Connect()/Disconnect() but it should care about the rest. So the whole
configuration part is done under the hood.
I personally think we should just use the D-Bus well known name for this
part. Making the application give an extra magic cookie seems useless.
Or if we get thinks like SCM_COMM (see Lennart's LKML post), then even
the unique name with extra RPM magic to identify the policies.
+ array{string, dict} BearerSettings [readwrite]
+
+ In case that an application needs to define settings
+ depending on the bearer, BearerSettings allows to
+ overwrite the sessions global settings.
+
+ For example the PeriodicConnect value might be different
+ for wifi and cellular bearer type, the application can
+ overwrite the session global PeriodicConnect here.
Why not having two sessions?
This was also my first question when I had some discussion with
colleagues of mine. So it is clear that with the current API we can not
really express some simple use cases, because some settings such as
Roaming is applied for all AllowedBearers. In my IVI world I face the
problem that I have 2 cellular modems for which the Roaming setting differs.
Yes, we have to add support the service names to the AllowedBearers but
more on this later.
So the only thing which differs it the Roaming setting you have to
create two sessions. And then you face the problem the application justs
wants to call Connect() and now which one should it call? Session 1 or
2? Of course we could add an ManagerSession API which combines sessions.
Then you would have to add a Priority for the Sessions.
I agree BearerSettings is introducing additional complexity but having
the other solution also add complexity. I really prefer more the
proposed solution.
Actually we might just come up with a better Roaming Policy setting.
I was thinking about that anyway. For example the pricing model
currently shifts so that none, national and international is no longer
enough. I think we also need europe and other magic values.
So maybe it is time that plugins can define certain roaming policies and
give them a well known name. We need to toy with that idea a little bit.
Until we get real global roaming flatrate options from the operators
this will stay a complicated topic.
[RFC v1 1/3] session: Update Session API
From: Daniel Wagner daniel.wag...@bmw-carit.de
---
doc/session-api.txt | 79 ++---
doc/session-overview.txt | 143 +-
2 files changed, 211 insertions(+), 11 deletions(-)
diff --git a/doc/session-api.txt b/doc/session-api.txt
index 3a0c9ca..d586856 100644
--- a/doc/session-api.txt
+++ b/doc/session-api.txt
@@ -90,20 +90,45 @@ Settingsstring Bearer [readonly]
for this session. Or an empty string if no bearer
is available.
- boolean Online [readonly]
+ string State [readonly]
- This indicates if the connection is online or
- offline.
+ This indicates the state of the session.
- This maps to the online service state. And it is
+ Valid states are offline, connecting,
+ online and suspended.
+
+ This maps to the service states. 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.
+ The offline state indicates that no services for
+ a given session are online. connecting is indicating
+ that the session has called Service.Connect()
+ and if this call is successful the next state
+ indicated is online. The application could
+ use the connecting state for starting to draw an
+ animation.
+
+ If the Service.Connect() is not successful
+ the next state will be offline. If the
+ application has started to draw an animation on
+ the connecting state it should stop drawing when
+ offline.
+
+ suspend state indicates the special case when a
+ GSM connection is used and a voice call is accepted.
+ GSM cannot handle data and voice connection at the
+ same time. suspend lets the application know that
+ the data link is suspended and therefore any IP
+ traffic is stalled. The application should also stop all
+ timeouts etc. during this period, because after
+ terminating the voice call the data link should recover
+ again without any IP changes.
+
+ In addition the notification sent upon a state change
+ might not happen right away. Notifications of
+ connecting and online state can be delayed based
+ on the speed of the bearer. This is done to avoid
+ congestion on bearers like cellular etc.
boolean Priority [readwrite]
@@ -294,3 +319,37 @@ Settings string Bearer [readonly]
this allows ConnMan to setup the firewall rules
that only traffic from the emergency application
are transmitted.
+
+ string SessionId [readwrite]
+
+ Applications which want to get a preconfigured
+ session can pass in a ID with Manager.CreateSession().
+ This ID is used to retrieve all settings from the
+ configuration plugin.
+
+ The application should treat this ID as a known secret.
+
+ If SessionId is changed after the session has been
+ created, all previous settings will be lost.
+
+ array{string, dict} BearerSettings [readwrite]
+
+ In case that an application needs to define settings
+ depending on the bearer, BearerSettings allows to
+ overwrite the sessions global settings.
+
+ For example the PeriodicConnect value might be different
+ for wifi and cellular bearer type, the application can
+ overwrite the session global PeriodicConnect here.
+
+ The application does not have to set all settings per
+ bearer. Only the ones which should overwrite the
+ sessions global settings.
+
+ boolean BearerAvailable [readonly]
+
+
