[Home] [Groups] - Message: [Prev in Group] [Next in Group]
30776: Re: [MUD-Dev] Distributed State Systems
[Full Header] [Plain Text]
From: Alex Arnon <alex.arnon@gmail.com>
Newsgroups: nu.kanga.list.mud-dev
Date: Sun, 5 Sep 2004 11:43:04 +0300
References: [1] [2] [3] <-newest
Organization: Kanga.Nu
On Fri, 3 Sep 2004 00:58:08 -0400, Michael Tindal
<mtindal@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.
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.
_______________________________________________
MUD-Dev mailing list
MUD-Dev@kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev