Hi Jukka, > > 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.
the implementation is exactly the same. The only difference is where the value of the timeout comes from. 1) the combination of all sessions define the timeout per interface and for 2) a somehow configured global one does it. Step away from thinking that we will define and run a timeout for each session. That would be just waste. The values that the application sets on the session configuration are just hints. The choice on how to interpret them are done by ConnMan and not the session. > > 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 is in the end exactly the same thing. It is just a hint value on when ConnMan should connect again. So even if an email application tells ConnMan to connect every 10 minutes with an idle timeout of 2 minutes. This does not mean that it will be woken up every 10 minutes. And even it it gets woken up around every 10 minutes, this does not mean that the connection went down in between. It might have just stayed up during this time. These parameters are ways for an application to express certain needs and we try to meet these needs, but not at all costs. You have to change you thinking here a little bit. The application is not in charge. It expresses wishes and tells ConnMan it desired connection behavior and then ConnMan will try to accommodate this. Regards Marcel _______________________________________________ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
