Overview
From the point of view of an X session manager, a session is a “state of the desktop” at a given time: a set of windows with their current content. More precisely, a session is the set of clients managing these windows or related to them and the information that allows these applications to restore the condition of these windows if required. The most recognizable effect of using a session manager is the possibility of logging out from an interactive session and then finding exactly the same windows in the same state when logging in again. For this to work, the session manager program stores the names of applications that are running at logout and starts them again at login. Moreover, for the state of the applications to be restored as well (which is needed to restore the content of windows), the applications must be able to save their state of execution upon request from the session manager and load it back when started again. In general, a session can be saved or loaded at any time, even if the user is not logging in or out. It is also possible to save a number of different sessions and loading one of them at user's choice. Sessions can also be specified by providing the list of applications that compose the session. As a result, the user has the possibility of saving a set of different sessions, either by storing the state of execution of the currently running applications or by explicitly listing the applications that compose a session. This way, the user can later decide to load a given session.XSMP Protocol
In order for a session to include the state of an application, the application must be able to store and load its current state when session manager request to do so (usually on user login or logout). A protocol named ''X Session Management Protocol'' (XSMP) specifies how applications and session managers interact. The XSMP message format is the same asThe Protocol
The XSMP is a subprotocol of the ''Inter-Client Exchange Protocol''. The client starts the protocol by connecting to the session manager. How the session manager is located on the network is system-dependent: in aSESSION_MANAGER
. Therefore, when a client is launched, its environment must contain this variable with an appropriate value.
Identifiers
The protocol takes into account two facts: # in order for a session to be restarted properly, not only the applications running in it must be restarted, but they must also be restarted in such a way they restore their previous state; # the same application may be running more than once in the same or different session. Different instances of the same application may be active at the same time in the same or in different sessions, and these instances most likely have different states of execution. For example, the user may have launched a text editor on file/etc/passwd
, then on file letter.txt
in the same session, and then on file todo.txt
in another session.
In order for the sessions to be restored properly, different instances of the same application must be recognized as different by the session manager. For this reason, the session manager chooses a unique identifier for each instance of each application. This way, the session manager is able to distinguish between the text editor that is running on /etc/passwd
and the text editor running on todo.txt
, even if they are two instances of the same program.
The identifiers must be unique. In particular, they must be unique across all sessions managed by the session manager: the identifier of the text editor running on /etc/passwd
is different not only from the same text editor running on letter.txt
but also different from the text editor running on todo.txt
in another session. The identifier of a client remains the same even if the session is shut down and restarted.
The main parts of the protocol
The main parts of the protocol of session management are: # the session manager chooses a unique identifier for every client # the session manager requests clients to save their state # a client specifies how it has to be started again in order for the state to be restored (e.g., theRestartCommand
, and contains the information on how the client has to be started again.
When the session manager requests a client to save its state, the application proceeds as follows:
# it saves its state in such a way that the states of two different instances can be distinguished; this can be obtained for example by saving the state in a file whose name contains its identifier
# it stores the specification of how it has to be started again in the RestartCommand
property; this property must contain the client identifier because:
## the application must retain its identifier when started again
## the identifier is needed to restore the state (for example, it is needed to find the file where its state is stored)
The session manager maintains other properties beside RestartCommand
. For example, a property specifies how to run the application if the session is destroyed.
Local and global state
When asking a client to save its state, the window manager can specify whether the local or global state (or both) has to be saved. The difference is whether the result of the save should be visible to the other applications or not. In the case of the text editor, saving the global state means saving the file normally, so that other applications can use the new version of the file. Saving the local state means that a local copy of the file has to be saved, so that other applications can see the file in its original version.An example
The following are the main steps in the interaction of a session manager with the hypothetical text editorxyz
when this application is started for the first time in a session, then the user logs out and then in again:
# the application connects to the session manager via the Inter-Client Exchange Protocol
# the application tells the session manager that this is the first time it is started, and therefore it has no previous identifier (and, therefore, no previous state)
# the session manager replies by sending the client its unique identifier, say 4324
;
# the session manager immediately asks the client to save its local state (only because the client has been started for the first time)
# the client stores the command line xyz -sid 4324
as the property RestartCommand
in the session manager (this is also system-dependent: in a .temp-4324
# when the user logs out, the session manager sends a message to all client notifying that they have to save their state
# the client 4324
complies again
# when all clients have communicated the session manager that their state is saved, the session manager shuts down the session
When the client is told to save its state, it may have the possibility of having a limited interaction with the user or not (for example, to ask the user if the edited file is to be saved). Anyway, the state is saved, it tells the session manager by sending an appropriate message).
When the session is started again, the following takes place:
# the session manager restarts the client 4324
by executing what is stored in the property RestartCommand
associated with the client 4324
# the application is therefore started as xyz -sid 4324
; this way, the application knows its identifier
# the application retrieves the state information from the file .temp-4324
# the application connects to the session manager specifying the identifier 4324
, so that the session manager knows that this is not a new client but an old one restarting
Client-managing sessions
According to the XSMP protocol, a session manager is an arbitrary program (server) that runs and controls the state of other applications. As a result, a client can itself be a session manager of other clients. For example, aImplementations
The X Window System includes a default session manager calledxsm
. Other session managers have been developed for specific KDE
is a default session manager of KDE Plasma 5 Desktop environment.Xfce
program is a default X Session Manager for Xfce based DEs. Xfce allows to create different sessions and choose them at startup.Gnome
is a default session manager for Gnome DE. Gnome has supported XSMP since v1.x. 2013 GNOME had intention to replace GNOME session manager XSMP with aSee also
*References
External links