From: Daniel Wagner <[email protected]> We are using the main service auto-connect algorithm, thus get rid of the old description. ---
Hi, Here is the documetion update which should also explain why having service->session list is a good thing. cheers, daniel doc/session-overview.txt | 79 ++++++++++++++++++------------------------------ 1 file changed, 29 insertions(+), 50 deletions(-) diff --git a/doc/session-overview.txt b/doc/session-overview.txt index 6de2ec7..3696212 100644 --- a/doc/session-overview.txt +++ b/doc/session-overview.txt @@ -5,56 +5,35 @@ Session API Connection management algorithm basics ====================================== -When a session is created, a sorted list of services is added to the -session. The services are filtered and sorted according AllowedBearers. - -There are two triggers which lead to evaluate the connect -algorithm: - - - Session.Connect() - - Offline - -Connect algorithm: - - Session.Connect() - | - +------+-------+ - +-----+ECall Session ?+-----+ - Yes| +--------------+ |No - | | - Connect to +--------------+ - first available +---+AvoidHandover?+---+ - Service | +--------------+ | - Yes| |No - +----------------+ | - +---+In service_list +---+ | - Yes| |and online? | |No | - | +----------------+ | | - | | | - Take that one Take first in - the service list - and try to connect - -Disconnect algorithm - - - Session.Disconnect() - -Disconnect algorithm: - - Session.Disconnect() - | - +--- Session.Change() - | -+-----------------+ Yes -|service not used +-------------+ -|by other session?| | -+------.----------+ | - |No | - | | - Service.Disconnect() Do nothing - -Session.Disconnect() will be blocked whenever a ongoing -emergency call is active. +The Session core uses the normal auto-connect algorithm for selecting +which services will be used. Earlier implementation did implement an +additional state machine for managing the sessions which turned out to +be complex and difficult to maintain. Using the normal auto-connect +algorithm also allows to use the Service API and the Session API at +the same time. + +Via the AllowedBearers a Session can filter which Service will be +considered when an application is asking to be connected. Only Session +which have AutoConnect set to true will be considered. + +One of the main use cases with Sessions is that the system will be +idle/offline if there is no application/user asking for a +connection. Obviously, the default behavior of ConnMan is always +trying to auto-connect one Service with AutoConnect set to true when +the system enters idle state. With SessionAutoConnectMode set to true +the auto-connect algorithm will only try to establish a connection +when there is an application asking for it. If there is no application +is asking for connectivity, auto-connect will disconnect Services with +no 'users'. + +The Session core exposes via an internal API each Session +configuration towards the Service core. Each service keeps track which +session is associated to it. For example, a Session sets +AllowedBearers to 'ethernet', then all Services with type Ethernet +will have a pointer to this Session. When a Ethernet Service goes +online it just needs to iterate over the list of Sessions associated +with it and notifies them. Also the auto-connect algorithm needs only to +look at the Session list if there is an user or not. Session States and Transitions -- 1.8.4.474.g128a96c _______________________________________________ connman mailing list [email protected] https://lists.connman.net/mailman/listinfo/connman
