Annikka/evennia
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions 1

Added Sphinx (reST-style) conversion of Evennia documentation to docs/. This is an auto-generated conversion directly from the Wiki, so it's not custom-written in any way (will also make it easy to update). You need Sphinx to compile the sources into fancy pages. Supporting sphinx is to make documentation easier to print and view offline. Currently no sphinx src-code viewing is activated by default, it gives too many spurious errors (the converters are in the repo though if you're interested in experimenting). So for offline autodocs, doxygen is still to recommend.

Browse source
This commit is contained in:
Griatch 2011-09-10 23:44:49 +02:00
parent 5a2b9e27a0
commit bd0079a39d
65 changed files with 9394 additions and 143 deletions
Download patch file Download diff file Expand all files Collapse all files

61
docs/sphinx/source/wiki/PortalAndServer.rst Normal file
View file

@ -0,0 +1,61 @@
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.