mirror of
https://github.com/evennia/evennia.git
synced 2026-03-16 21:06:30 +01:00
61 lines
2.8 KiB
ReStructuredText
61 lines
2.8 KiB
ReStructuredText
Portal and Server layout
|
|
========================
|
|
|
|
Evennia consists of two processes, known as *Portal* and *Server*. They
|
|
can be controlled from inside the game or from the command line as
|
|
described `here <StartStopReload.html>`_.
|
|
|
|
https://2498159658166209538-a-1802744773732722657-s-sites.googlegroups.com/site/evenniaserver/file-cabinet/evennia*server*portal.png
|
|
|
|
As seen above, the Server and Portal are glued together via an AMP
|
|
(Asynchronous Messaging Protocol) connection. This allows the two
|
|
programs to communicate.
|
|
|
|
Portal and Server Sessions
|
|
--------------------------
|
|
|
|
*note: This is not really necessary to understand if you are new to
|
|
Evennia.*
|
|
|
|
New Player connections are listened for and handled by the Portal using
|
|
the `protocols <SessionProtocols.html>`_ it understands (such as telnet,
|
|
ssh, webclient etc). When a new connection is established, a *Portal
|
|
Session* is created on the Portal side. This session object looks
|
|
different depending on which protocol is used to connect, but all still
|
|
have a minimum set of attributes that are generic to all sessions.
|
|
|
|
These common properties are piped through AMP to the Server, who is now
|
|
informed a new connection has been established. On the Server side, a
|
|
*Server Session* object is created to represent this. There is only one
|
|
type of Server Session. It looks the same regardless of how the Player
|
|
connects, it leaves such details up to the Portal.
|
|
|
|
From now on, there is a one-to-one match between the Server Session on
|
|
one side and the Portal Session on the other. Data arriving to the
|
|
Portal Session is sent on to its mirror Server session and vice versa.
|
|
|
|
During certain situations, the portal- and server-side sessions are
|
|
"synced" with each other:
|
|
|
|
- The Player closes their client, killing the Portal Session. The
|
|
Portal syncs with the Server to make sure the corresponding Server
|
|
Session is also deleted.
|
|
- The Player quits from inside the game, killing the Server Session.
|
|
The Server then syncs with the Portal to make sure to close the
|
|
Portal connection cleanly.
|
|
- The Server is rebooted/reset/shutdown - The Server Sessions are then
|
|
copied over ("saved") to the Portal side. When the Server comes back
|
|
up, this data is returned by the Portal so the two are again in sync.
|
|
This way a Player's login status and other connection-critical things
|
|
can survive a server reboot (assuming the Portal is also not stopped,
|
|
obviously).
|
|
|
|
Sessionhandlers
|
|
---------------
|
|
|
|
Both the Portal and Server each have a *sessionhandler* to manage the
|
|
connections. These handlers contain all methods for relaying data across
|
|
the AMP bridge. All types of Sessions hold a reference to their
|
|
respective Sessionhandler (the property is called ``sessionhandler``) so
|
|
they can relay data. See `protocols <SessionProtocols.html>`_ for more
|
|
info on building new protocols.
|