[MUD-Dev] Distributed State Systems

[Alex Arnon]

On Fri, 3 Sep 2004 00:58:08 -0400, Michael Tindal
<mtindal at paradoxpoint.com> wrote:
> On Tuesday 31 August 2004 01:04 am, Davion Kalhen wrote:
> 
> > This is the first time I've posted on MUD-Dev but I've recieved it
> > for alittle while now. But why not use a signal handler and use a
> > style like Erwin's copyover? I've used it for alittle bit now and
> > it works nicely. But mostly your looking at a bad idea. Segment
> > Faults occure mostly when data is accessed outta bounds, if by
> > chance you happen to try to save that data while the MUD is going
> > down, nothing but bad juju there, and you'll wind up with loads of
> > currupt data. Like players titles being random ansi characters
> > :P. We don't need that!  All and all, I just don't think thier a
> > good idea if its because your mud crashes on a regular
> > basis. There's also problems with crashing while copyingover, but
> > there's easy fixes for that. But think about it, if it could be
> > done, wouldn't Micro$oft do it, so Windows never crashes? I don't
> > mean to bash your idea.
> 
> Im not saving data from a segfault, the nodes don't hold the data
> themselves, which is the point of the post.  Please, read the entire
> posting before replying.  I don't need copyover, I've already got
> that taken care of.  In case you had read, the data is being stored
> in an external location, and I did not mention trying to save the
> data is the particular node storing the data segfaulted.  Its meant
> to alleviate connection loss.
> 
> Mike Tindal
> 
> 
> _______________________________________________
> MUD-Dev mailing list
> MUD-Dev at kanga.nu
> https://www.kanga.nu/lists/listinfo/mud-dev
> 


Ah, so you mean that all operations go atomically through the DB? You
spoke of caching above. In the case you forego any form of caching,
you'll need to go through the DB for everything (and the server nodes
are simply used for connection/control thread aggregation), which
means that you'll be I/O (network) bound, and probably enjoy a severe
DB bottleneck. Otherwise, Davion's post is more than relevant -
whenever caching is used, some form of coherence protocol is necessary
(unless your application architecture is very very
read-only-oriented).
The solutions to this kind of problem (how do i make my application
scale to tens and hundreds of thousands of connections) are often
dependant on the kind of application you are trying to write. There
might be a central attribute to your application which will enable you
to share less information between nodes than you thought before, or a
certain type of inter-object dependency which you can use to your
advantage (e.g. there's lots of short-lived sharing, and you can make
the connections follow such a dependency to minimize that sharing).
In any case, if you're interested in inherently parallel systems, I
suggest you at least take a peek at Erlang (www.erlang.se). This is a
language and runtime which is used for distributed systems, mostly
telephony (but it's proven itself in the web services department as
well). I do not know if the language will suit your needs
(message-passing and pattern-matching based), but it might be just
what you were looking for. I believe it is not suitable for general
MUD implementation (which I personally see as necessarily OO), but for
other types of games it should be wonderful: robust, very fast,
excellent networking and protocol manipulation facilities, various DB
schemes built in, etc. I believe the concepts presented by the
Erlang/OTP developers might be interesting to you.