[DGD] DGD/MP & OpenMosix revisited?
Felix A. Croes
felix at dworkin.nl
Mon Feb 9 17:02:34 CET 2004
Ragnar Lonn <prl at gatorhole.se> wrote:
> 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?
Oops, I didn't realize I had left in this question.
> 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.
>[...]
The interrelatedness of mail boxes is very low. Mail sent to one
mailbox doesn't affect other mailboxes. This happens to be a very
easily parallelizable problem. I don't know what page ranking
system Google uses, but I <do> know that if they use a large
number of small servers for their database, they are constrained
in their choice of algorithms.
In a MUD, the degree of interrelatedness is high.
> 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).
Sure, if your game is made up out of zones and one zone server
fails, then just that one zone becomes inaccessible. But if it
happens to be your chat server, or your game is made up out of a
number of servers with objects migrating between them, the entire
game is likely to be affected. Even if there is a backup server
with a fairly recent state copy, some objects will have disappeared
and others will have lost history, and players will be screaming at
you. And don't forget, distributed systems are complex and you can
expect a certain amount of trouble even without hardware failures.
In DGD/MP, my intention is to insulate the MUD programmer from the
underlying complexity by simulating single-threadedness. In a
distributed MUD that is going to be harder, and apparently
innocuous changes, part of a normal MUD code upgrade, may have
unforeseen effects.
A game can more easily recover from downtime than from 100 players
losing their sword of Uber Slaying due to a glitch.
> 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.
This is true for an infrastructure provider like an ISP but not, I think,
for a MUD. If you announce downtime in advance and keep it reasonably
short, players can accept it in good grace.
>[...]
> > > 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 ;)
For what it's worth, I think the consensus among MMORPG professionals
agrees with you. I just think that they are all wrong, and I have
staked the future of DGD/MP on it :)
Regards,
Dworkin
_________________________________________________________________
List config page: http://list.imaginary.com/mailman/listinfo/dgd
More information about the DGD
mailing list