[DGD] DGD/MP & OpenMosix revisited?

[Greg Lewis]

On Sun, Feb 08, 2004 at 10:11:33PM -0500, Stephen Schmidt wrote:
> Ragnar Lonn wrote:
> > I've been imagining a
> > system where you have an arbitrary number of game servers. Each server
> > maintains state for a number of game objects. You have an inter-server
> > call_other() function that lets an object on server A call a function in
> > an object on server B. Each game object resides on two servers but only
> > one server is authoritative - the other maintains as up to date a state
> > as possible for the object in case the first server goes down.
> 
> How are your servers going to connected to one another? If you
> are relying on some kind of Internet connection between two
> servers, couldn't this get awfully slow, waiting for requests
> to come back from a remote server? The advantage to the "shard"
> system isn't so much that it reduces storage, but that it
> reduces the need for interprocess communication.
> 
> If your servers are all in the same lab somewhere and can
> communicate at speeds resembling instant, then this might get
> more attractive. I'd still worry about getting a bottleneck
> at a server with some particularly frequently accessed object,
> however.

I would assume from the subject including "OpenMosix" and the body of
the message mentioning "clusters" a couple of time that Ragnar was
thinking of the servers all being in one or more racks connected with
high speed interconnects (at least GigE, or possibly Myrinet, Quadrics
or the like).

How well a mud fits into a transparent load distribution technology
like OpenMosix or bproc is interesting.  Something like MPI may also
be worthwhile examining, although I'm not familiar with it enough at
the moment to speculate.

The bottlenecking object type question would really come down to a
question of designing the mud for a clustered environment.  Basically,
don't design the mudlib around an object that will create such a
bottleneck.  This is quite similar in some respects to design of a
parallelisable program - you have to design it as such and shift your
paradigm from what you use when designing a program that will be executed
in a "serial" environment.

-- 
Greg Lewis                          Email   : glewis at eyesbeyond.com
Eyes Beyond                         Web     : http://www.eyesbeyond.com
Information Technology              FreeBSD : glewis at FreeBSD.org

_________________________________________________________________
List config page:  http://list.imaginary.com/mailman/listinfo/dgd