[DGD] DGD/MP & OpenMosix revisited?

[Ragnar Lonn]

On Mon, 9 Feb 2004, Felix A. Croes wrote:

> > one, Lineage, has over 4 million paying subscribers?  A community-built
> > MMORPG could be something really cool, I'm pretty sure of that.
> So are you talking about MUDs, or about MMORPGs?

A MUD can be said to be an MMORPG, really. I'm talking about a 3D RPG
game with the (user-)extendability of a modern MUD. I'm talking about
Linden Labs' game "Second Life" (http://www.secondlife.com) but better.
(Second Life might have been great, they were thinking along the right
 lines, but I don't think it will be. Not in this incarnation at least.
 It's mostly a fancy chat world right now).

About clusters and small/cheap vs large/expensive machines I only
know that when it comes to price/performance, you can never beat
a solution that clusters many inexpensive machines, as opposed to
setting up a single, large server. Most systems today that require
*serious* transaction performance are moving to run on many
inexpensive computers. ISPs do it for their large systems, for
instance. A mail system that has to handle several hundred thousand
up to a couple of million users is usually clustered, one way or
the other. When I say "clustered" it can mean that the service is
just divided over several servers, where one server takes care
of the mailboxes of e.g. 50,000 users. You might be able to buy some kind
of monster computer with the I/O capacity to handle a couple of million
users but the cost would be a lot higher and because of the specialized
hardware - and often software too - the cost of support, upgrades and
maintenance will be very high. I talk to ISP operations staff every
day and they all maintain large numbers of servers and don't seem very
interested in moving to larger but fewer machines. The largest swedish
ISP, Telia, with a few million Internet customers, has several thousand
Unix servers (and probably about as many running Windows).

You're right, of course, that it's more work maintaining a large
server farm than a single giant computer but the hardware failure rate
isn't that high and most (ISPs) running large services sleep better
at night knowing that if there is a hardware failure, at most 50,000
users out of 2 million will be affected. That's just 5% of the user
base. If they have a single large machine and something goes wrong, there
may be 2 million people screaming at them to fix their sh*t and that can
be pretty unnerving (I have tried it with just 20,000 or so users
and that really sucked).

About software upgrades and maintenance, it is important to have a
system that allows you to take a server offline for upgrades without
disrupting service to the users. It is more work to keep many servers
up to date, yes, but by using identical hardware you can automate
the process to a large extent and in the case of a gigantic server,
you have no choice but to take down the whole server when you need
to do an OS upgrade, because you can't afford to have an extra
gigantic server as backup. That would mean you need 100% surplus
capacity in order to never have any downtime and that is just too
expensive. Even if the clustered system does NOT allow you to
temporarily move users to another server, it is still much nicer
in an OS upgrade situation than the single-server system as you know
only a certain amount of users will be affected and can prepare the
support department for all the calls that will come.

> MUDs are like databases.  The ultra-fast, ultra-large, ultra-reliable
> databases don't run on a network of cheap hardware.

Well this is where I respectfully have to disagree. Are you saying
that Google is slow, small or unreliable? ;)

I think that to get really good performance and be able to host really
large amounts of data, there is no other way than using many servers.
Perhaps some such systems today suffer from software immaturity while
single-server systems have been refined for decades and are often more
stable but is that a reason to avoid multiple-server systems?  If it
really is the only way we'd do better to learn how to do it right!

> Geir Harald Hansen created a distributed MUD using DGD.  You can find
> his thesis paper here:
>
>     http://www.stud.ifi.uio.no/~geirhans/thesis.pdf

Aha! Thanks, I'll look into it!

> > Wouldn't it be nice to do away with "shards" and similar workarounds
> > and have a truly expandable game for once?
>
> Agreed!
>

Finally something we agree upon ;)

Cheers,

  /Ragnar

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