[MUD-Dev] distributed, _untrusted_ servers

[Oliver Jowett]

Something I've been thinking about recently, somewhat related to the
current load-balancing etc discussion: supporting "leaf" servers that
support groups of nearby clients and keep the bandwidth/latency needed to
the main game server down. The catch is that I want _users_ to run these
leaf servers - so they're "in the hands of the enemy".. 

This is really aimed at systems where the client protocol deals in terms
of game objects not raw text - in mud terms, more along the lines of a
graphical mud I suppose.

I started on a long detailed description of it but it became
incomprehensible at about line 200 :) so here's the cut-down version:

--

Topology: central, trusted, server or servers that maintain the official
game state. Clients can connect directly to these servers. Leaf servers,
not trusted, can also connect. Clients may connect to a nearby leaf server
that they trust instead of going direct to the central servers. Ideally
I'd like a situation where it's possible to hang 20-30 clients on a LAN
off a leaf server, and have that leaf server connect over a slow link
(modem etc) to the central server(s) - and have the game remain playable.

Clients connect to the leaf server and authenticate; the leaf server just
acts as a proxy, forwarding the authentication to the central servers. The
leaf server then gets sent all directly-visible information that its
clients can see (i.e. we're not giving out more info than we'd give each
client if it connected directly).

Game data is classified into three categories:

. local - all details are known by the leaf server, and the leaf server
  can assume the central server won't be unexpectedly modifying these
  details
. remote - some or all details are only known by the central servers
. dangerous - not really a type of data, but a set of states where "local"
  data might change unknown to the leaf server.

"remote" data will initially include everything about the gameworld that
the clients don't automatically have access to.

"dangerous" data is hard to explain clearly, but in essense it defines the
region of the game where the leaf server can be sure that it has all the
data it needs - and that another client connected elsewhere won't
interfere with it. For example, it would include a description of the
parts of the game map where there's no chance of another client modifying.

Defining dangerous data could get very complex, but it can be cut down by
noting that the only data that is potentially dangerous is data that can
be local, and then only making data that is performance-critical
potentially local.

Over time the set of dangerous data changes as events occur elsewhere in
the gameworld - the central server will regularly update the leaf server
with new dangerous regions.

---

How client requests are handled depends on what type of data they involve:

. If all data is local, the leaf server immediately performs the request.
  If the request has an effect on the game-world (i.e. it's not invalid or
  an information-request-only request) then it is also echoed to the
  central server.

. If any data referred to is remote, the appropriate bits of the request
  are forwarded to the central server and the response is _waited for_.

After each request (? - or just regularly?) the state of the data involved
is updated. Possibly remote data might change to being local - for
example, identifying an item must be remote to avoid leaf servers just
extracting the information directly without paying the in-game cost, but
once identified the item information might as well be local (assuming
there's no other reason for it to be remote).

If data has moved into a dangerous state it becomes remote (for example,
moving into a region near another client not handled by the leaf server)

The central server will be regularly firing updates to the data that the
leaf server has as the game world changes, as well. The degenerate case is
where there is a lot of activity going on in a particular area, no data is
local to the leaf server, and everything goes through the central servers
to maintain consistency.

In the "ideal" case, where you have no interaction between the leaf
server's clients and other clients, the leaf server should just be sending
information on what its clients are doing to the central server (to update
the overall game state), plus the occasional request that has to be
performed on the central servers itself.

--

Did that make _any_ sense to anyone? I know it's not very clear, but I'm
interested in feedback.

--
Oliver Jowett - icecube at ihug.co.nz - http://homepages.ihug.co.nz/~icecube/
KeyID: 1024/679D94C5  Fingerprint: CD94 5270 E2F4 339F 6A90 05C9 9DE4 EECC



_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev