[MUD-Dev] TECH: Distributed Muds

[John Buehler]

Kevin Littlejohn writes:
> "John Buehler" wrote

>> The thing that seems so incredibly odd to me is the insistence that
>> the world be partitioned for processing along geographic
>> boundaries.  I mentioned it in an earlier post and have been
>> holding my tongue here, but I'll just quickly mention it again.

>> Partition the world along skill lines, or perception lines, etc.
>> Look at the processing schema of the world that you're providing
>> and see what data and algorithms can be partitioned away.  Even
>> those data and algorithms that can't be *completely* partitioned
>> may be related to others along just a few, infrequently-touched
>> schema connections.  In that case, transferring data between those
>> partitions would be performed on an as-needed basis.

> My main problem with this is that the problem people are trying to
> solve with partitioning is invariably the huge amount of data needed
> over an entire world.  Maybe you can reshuffle your data such that
> one machine can hold all the collision detection data for a single
> world, another machine can hold everything related to blacksmithing
> for every entity, etc. - but I somehow doubt it.  Geographic
> break-ups allow you to do splits based on the range of perception of
> the player - I can be reasonably assured that everything I can
> see/interact with is on my server, as lagless as possible.
> Skill-based breakups would have my actions bouncing across multiple
> servers - which would seem to increase the complexity of my being
> logged in by including many more points of failure.

> But maybe I'm not seeing fully how this would work.

The idea is that we bring big, capable servers to bear on the biggest,
nastiest data and processing problems in the game world.  Collision
detection would certainly be way up there.  I can see some
quad-processor machines doing that and nothing else.  And that's the
appeal of the segmented approach: specialization.  That big machine is
doing one thing and one thing only.  It has all of its configuration,
code and data geared towards that one problem.  For all I know, the
code would occupy all of 10K of space and the four processors can be
brought to bear most effectively.  That, as opposed to diddling around
with blacksmithing, archery, inventory shuffling, etc.  Collision
detection now has no lines of discontinuity, which is certainly the
player expectation.  The frequency of character and object movement
can be observed and the problem can be carefully analyzed, largely in
isolation from other world activity.

Smaller machines are brought to bear on the systems that have lesser
processing requirements.  And those processing requirements can be
monitored because they are partitioned.

The idea of having character actions bouncing around between servers
doesn't bother me overmuch.  A client interacts with a server
installation whose structure is opaque to it.  So your client sends
all of its messages to one server that operates to get the messages to
the correct processor.

Certainly there are now more points of failure.  I get a degradation
for all players instead of a cessation of service for a certain
portion.  I don't know which is better.  Loss of the archery machine
in the middle of a large battle anywhere in the world would be bad.
Loss of a zone machine in the middle of a large battle in that zone
would be bad.

JB

_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev