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

Reply via email to