This module defines a generic session class. All connection instances (both on Portal and Server side) should inherit from this class.
This class represents a player’s session and is a template for both portal- and server-side sessions.
Each connection will see two session instances created:
A Portal session. This is customized for the respective connection protocols that Evennia supports, like Telnet, SSH etc. The Portal session must call init_session() as part of its initialization. The respective hook methods should be connected to the methods unique for the respective protocol so that there is a unified interface to Evennia.
A Server session. This is the same for all connected accounts, regardless of how they connect.
The Portal and Server have their own respective sessionhandlers. These are synced whenever new connections happen or the Server restarts etc, which means much of the same information must be stored in both places e.g. the portal can re-sync with the server when the server reboots.
init_session(protocol_key, address, sessionhandler)¶
Initialize the Session. This should be called by the protocol when a new session is established.
protocol_key (str) – By default, one of ‘telnet’, ‘telnet/ssl’, ‘ssh’, ‘webclient/websocket’ or ‘webclient/ajax’.
address (str) – Client address.
sessionhandler (SessionHandler) – Reference to the main sessionhandler instance.
Get all data relevant to sync the session.
syncdata (dict) – All syncdata values, based on the keys given by self._attrs_to_sync.
Takes a session dictionary, as created by get_sync_data, and loads it into the correct properties of the session.
sessdata (dict) – Session data dictionary.
Called after a session has been fully synced (including secondary operations such as setting self.account based on uid etc).
generic hook called from the outside to disconnect this session should be connected to the protocols actual disconnect mechanism.
reason (str) – Eventual text motivating the disconnect.
Generic hook for sending data out through the protocol. Server protocols can use this right away. Portal sessions should overload this to format/handle the outgoing data as needed.
- Keyword Arguments
kwargs (any) – Other data to the protocol.
Hook for protocols to send incoming data to the engine.
- Keyword Arguments
kwargs (any) – Other data from the protocol.