[MUD-Dev] Re: TECH: Distributed Muds

[Vincent Archer]

According to J C Lawrence:
<EdNote: Ahem, missing second level attribution>

>> From the many years of server administration I've been involved
>> with, servers generally run at an average of 80-95% idle.
 
> This is especially true for those peoblem spaces where the cost of
> failure in the pessimal cases is sufficiently extreme.  A simple

But it also depends on your investment capabilities. If the cost you
incur from these setups is high, and what your customers pay you isn't
enough, then you have to make do, or shrink your margins a lot.

Most servers remain idle because, typically, these servers are doing
QR tasks. That is, they get queries, send back a reply, then go back
to idleness. A server for a game world is never idle, specially in a
modelled (3D) world. Not only players are constantly moving (thus
requiring distribution of updates), but you also have MOBs using CPU
cycles for their AI.

Most servers also have their CPU usage scale linearly with the number
of users at any given time, since each user in common server tasks is
highly independent from the action of others. Not so in a simulated
world; the CPU has to scale somewhere between O(N) and O(N^2), since
each action by a player must potentially be at least reported to all
other players, and may impact them.

If your server is at 90% idle when you have 100 players, don't think
it means you'll be able to support 1000 players at peak time :)

>> I'm not too clear on that UO's model is/was, only what a good
>> working model would be.  The above model allows you to take
>> advantage of a large TCP Window between the network servers and the
>> zone servers.
 
> 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).

It depends. When you have a switched LAN, and the only communication
between two boxes is a single connection, TCP is very efficient. In
practice, there are two types of messaging that can occur between a
front-end system and world simulations: one-to-one communication
(world simulation updating the front-end world state), and one-to-many
communications (like, for example, when a player says something in
guildchat, potentially all players may need that message).

The latter benefits from using a non-TCP system. I had a look at a
reliable multicast protocol from CISCO, but it's not yet finished.

--
Vincent Archer                                         Email: archer at nevrax.com

Nevrax France.                              Off on the yellow brick road we go!
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev