[Arianne-general] structure of the message handling on the server

[Ulrich E. <Doo...@kn...>]

Hi folks,

I've been thinking a lot about what and how and this is what I came up wi=
th.=20
This already covers to some extent the actual implementation while other=20
parts are just theoretical.
One important thing to keep in mind is that I consider controlling multip=
le=20
characters via one connection, or controlling none, instead just doing=20
administrative tasks. Don't cry 'cheater alarm', there are good reasons a=
part=20
from not introducing anything new.=20
 One reason is that it doesn't work to simply limit the number of control=
led=20
characters since you could also open a second connection and accepting on=
ly=20
one connection per IP-add would suck if you're behind a gateway.
 The other reason is the idea of distributed servers. The distribution of=
=20
servers could then be only moving the AI to other servers while the actua=
l=20
world-management could stay on the core servers. However, this is an idea=
 to=20
keep in mind and not the point of my current concerns.

draft:

The plan consists of three objects, one being the (low-level)=20
sender/receiver, one the connection-manager and the third the controled=20
object(s).

The sender/receiver is responsible for sending and receiving messages, th=
at=20
is doing the dirty work. The only modification to the current design is t=
hat=20
I would give every connection one (or even two) threads. One could then u=
se=20
blocking system-calls on sockets, separate connections would be less pron=
e to=20
influence each other (DoS-attacks).=20
 Does anyone know if the implied context-switching is very expensive ? Th=
e=20
question is, whether steady polling is more expensive. I will carry this=20
problem to comp.programming.threads .

 The message is given to the next object, the connection-manager.=20
 Here, the first split in the message-routing takes place: commands to th=
e=20
character are routed to that, meta-messages (logins, logouts, version-che=
cks)=20
are directly handled. This connection-manager has a table of characters=20
controled by the connection and routes the messages accordingly.

 The character-object has an associated message-queue where these message=
s=20
are stored. There will be one thread that iterates over all active object=
s of=20
the map that tells the character-object to pop and execute one of these=20
commands.=20
 It also has an associated perception-queue where all perceptions that sh=
ould=20
be transmitted to the client are stored.
 Only one special feature is necessary here: a way to cancel currently qu=
eued=20
messages. There are different ways to implement this, having a filter on =
the=20
queue that filters messages for the queue (as opposed to messages for the=
=20
character) or sorting by priority. However, this is of little priority no=
w,=20
rather a todo for later.

One last thing remains: the server-socket to listen for new connections. =
An=20
easy way is to poll this after each turn of the active objects. Another=20
approach uses yet another thread or (not available on Mac afaik) a timer.

What's the difference to the current way it works? The current negotiatio=
n=20
takes a predescribed way, if either client or server strays from the path=
,=20
the connection will be terminated. This is unsatisfactory to me because i=
t is=20
rather unflexible.=20
 The above way will also open a way for remote maintainance, that is logi=
ng=20
in without playing for eg informing all players of a server-reboot, modif=
ying=20
the world (as a 'god') or querying statistical information.

A sample session:

(client tries to open a connection, server accepts)
client: give me the protocol-version
server: 0.1
(insufficient version -> client drops connection)
client: create player-object
(server creates the object, inserts it into the map)
server: ok, id=3D1
client: load player-object "Oomph the Brave"
(server looks up the player and loads the saved stats or changes the type=
=20
from auto-controlled to player-controlled)
server: ok, id=3D2
client: move 2 to xy
(server looks up object 2 and puts the command into obj2's cmd-queue)
client: move 5 to xy
(server looks up object 5, doesn't find it and ignores the request)
client: save object 1
(server saves the object or sets it to auto-controled)
client: what is the system-load
server: 5 of max 500 conections, CPU-load=3D12% ...
(client suddenly drops connection)
(server switches all remaining objects (obj 2) to auto-controlled state)


Note: For the time being, I will not implement features like switching=20
from/to auto-controlled state, saving/resuming, multiple controled object=
s.=20
My sole intention for mentioning these here is to show that they're possi=
ble=20
to implement with the described design.=20

Uli