so far as I know, single thread with "select" can work well when there are not too many users connected, but as players increases, "select" could eat out all the CPU usages.

My question is: in LPmud, how to accept 2000+ players in one world? It should be a distributed environment, but with what aspect to distribute them? area? function? Also, how to communicate with such a distributed system?

Of coz in different rooms. I just meant how to distribute the whole world.

If distributed with areas, well a driver contains some areas and all the functions that the world needed, and another driver may contains some other areas and also all the functions. Or else distributed with functions, a driver contains all the areas, a driver contains the combat system, a driver contains the team deamon, etc..which one is prefer? or there are some other solutions?

what do you mean with "select" ?

The "select()" function in C provides a simple way of handling several sockets at the same time, and is what you'll see in pretty much every C or C++ codebase.

The problem is that "justadot" seems to have confused it with a completely different issue altogether - that of distributed servers, in which the number of players is so large that the processing power of the mud has to be split over a number of different servers. For example, using this approach in 1999, a graphical mud called "Kingdom of the Winds" peaked at 12,263 simultaneous users in a single world.

However this really isn't something you should be worrying about - even the regular stock muds can handle several hundred players (I think Smaug has been tested with around 900 or so?), and if your mud is well designed it shouldn't be a major problem to change it later on. But right now, it's a bit like building a space shuttle to get to the shops at the end of the street. If you want to do it for the fun of it, then fair enough, but it's not going to have any practical use.

Well, the problem is, a single MudOS seems are not powerful enough to accept 2000+ players, since the interpreter of LPC eat large amounts of CPU usages.

As the matter of fact, a world running on one server or two are not very important, but how to assign each task to the threads that the world needed seems more significant.

In fact, my question is how to distribute the tasks, by area? or by functions?

LPC is indeed significantly more processor-intensive than most languages. However as you're never likely to reach 2000+ players online at once (nor even a fraction of that) outside of stress-testing purposes, I shall assume that this is more of a theoretical exercise. I shall therefore also assume that (1) you're not interested in compiling parts of the LPC code into C to speed it up, (2) you're not interested in writing the entire mud from scratch, in such a way as to be more suitable for handling such a large playerbase, and (3) you're not interested in just buying a more powerful processor.

Threads on a single cpu? In some cases they may result in better performance, by taking advantage of parallel execution paths. In other cases they may result in a worse performance, because of the additional task switching required. Overall, IMO, they're really not worthwhile except for specific tasks that might otherwise cause a bottleneck (eg dns lookups).

That's up to you. However there was some discussion about this on MUD-DEV a couple of years back, which you might find of interest:



Perhaps the easiest approach would be to effectively have a copy of the same mud running on several different servers, with each representing a different game world, and have those servers exchange essential data with each other. Thus players could travel between the game worlds, creating the image of a single "universe". This is not really a distributed server, although it achieves much the same result.

Hmm, this isn't really something I have spent too much time worying about but my initial thought would be to have a single program accepting and dealing with connections from users.

Multiple servers can then run identical copies of the mudlib each dealing with a section of the game world. The initial program would route the connection from the user to the appropriate section of the game world and then re-route it as required by the user running around.

A well designed world should automatically spread the players out fairly evenly as they will all want different things, but a 'user limit' on each section would probably be put in too.

Static data could be stored on a shared drive accessed by all the servers (would need some logic to prevent them overwriting each other, etc - but the information being passed around can be limitted to make that easier).

What I meant was that by designing your world well not everyone would want to be in the same block.

For example different races could all have different starting places (elven homeland, etc). That spreads out your initial logons.

You then distribute the areas people are going to want to visit - i.e. make sure that every area has something people will visit it for - but not enough that hundreds of people will want to be there at the same time.

This way people will want to spread themselves out rather than gathering the entire mud in one 'xp run' area.