[MUD-Dev] Re: TECH: Distributed Muds

[J C Lawrence]

On Wed, 18 Apr 2001 23:44:23 -0600 
bruce  <bruce at puremagic.com> wrote:
> J C Lawrence wrote:
>> On Wed, 18 Apr 2001 18:52:11 -0400 Derek Snider
>> <derek at idirect.com> wrote:
 
>> Or, given that you control the wire and everything else between
>> the two, to do your own protocol on top of IP (a fairly common
>> approach).

> Or move over to custom interconnect hardware and move to some sort
> of message passing system, like MPI.  

MPI, at the hardware level is pretty comoddity these days.  I
haven't checked into its support in the Open Source world lately,
but I know that as of 18 months ago there were several fairly active
projects to get variously interesting MPI sub-layers working/built.

(VA used to sell a fair few MPI clusters based on Dolphin hardware)

> But that assumes an amount of traffic within a cluster that I'm
> not sure I'd be comfortable with.  I'd be much happier not having
> that much data being shared. :)

Complexity theory strikes again.

The problem really isn't the traffic levels, or the data volume, but
the increased potential for catastrophe.  Once the system complexity
gets past a pretty damned small level, uless you are unusually
rigorous in your designs (and can reduce them to a functional
algebra), its bloody difficult to prove that there are no
deadlock/race/ping-pong conditions.  Test systems are simple.  High
transaction rate systems have an ability to expore the permutation
space in uncomfortable detail.

> But, if working with IP, one nice technique that isn't terribly
> well exploited in the mud community today is the use of multicast
> groups within a cluster.  

Eeeek.

> (Although, that might have something to do with the lack of any
> cluster-based mud codebases. :)

I tend to look at the problem space this way, when defining a
working set as contextual to a player:

  -- Working sets tend to be large

  -- A typical working set intersects with N other working sets,
  where N is often > 5.

  -- The rate of change of intersections of working sets is
  moderately high

  -- The rate of internal state changes to working sets, and in
  particular to items shared among multiple working sets, is high.

  -- The total set of working sets tends to make a continuous
  mesh.  Islands do occur, especially if enfoced via game
  mechanics (zones, deserts, geography etc), but in the general
  case isolated populations may be considered atypical.  

Note: Mechanical subdivision of the working set mesh (ala zones) is
a simple and obvious way of segmenting the problem space into more
manageable chunks, but in the general tends towards having one
humungous (technical term) working set of data continuously accessed
and modified by multiple simultaneous actors even if we use zones.
The more we try and mechnically divide the problem space, the more
players are going to want to form crowds and mobs and cities (eek!),
and other massively intersected pessimal sets.

I think in the end we're going to have to recognise the fact that
artificially segmenting the working set collision space (ala zones)
is an extremely artificial stopgap and just work work much longer.
Sure its convenient, especially in terms of time to market and
engineering effort, but w're getting close to the point where we'll
have to adandon that position.  Crowds are a fact of humanity.

So we're back to single image super computing.

> And there are other interesting techniques that don't require
> custom hardware for lessening the network latency within large
> clusters, without putting out the money for very large and
> expensive switches, like the work done at the University of
> Kentucky on 'Flat Neighborhood Networks as described at:

>   http://aggregate.org/FNN/

This is fascinating.  Neat.  Thanks.  

--
J C Lawrence                                       claw at kanga.nu
---------(*)                          http://www.kanga.nu/~claw/
--=| A man is as sane as he is dangerous to his environment |=--
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev