Server Architecture

Server clusters implement instances of the virtual world. There may be programmed differences between them (attacking other players might be allowed on one but not on another, for example), but these are generally minimal in form if not effect. The number of servers present in a cluster varies from implementation to implementation, but it’s usually around half a dozen or so. The number of clusters also varies, with more clusters being added as a product’s popularity increases (EverQuest hit 40 server clusters in 2000, averaging around 1,500 players simultaneously on each one at peak time).

Figure 2.2 shows how a server cluster is typically configured.

Figure 2.2 Server cluster architecture.

Individual clients are connected to individual sub-servers. Ideally, each sub-server does the same amount of work (which in practice means it handles the same number of players) as every other sub-server. Sub-servers have access to a shared character database ¹ that stores the persistent data relating to players’ characters on this server ². This may or may not be part of a systemwide accounts database for managing player access. For maintainability, a large-scale world generally maintains a separate database for environment data, which may be partitioned into a template database, a scripting language database, and an instantiation database (as described in Chapter 1).

Furthermore, whether these world/environment databases are shared (as shown here) or local to each sub-server depends on how load-balancing works. EverQuest’s zoning system, for example, can get away with having smaller environment databases that are controlled by individual sub-servers; only the character database needs to be shared with the other sub-servers, for when characters move between zones. This is paid for in other ways, of course, which we will discuss shortly.

The hardware implementation of a server cluster is as a bunch of PCs or beefier hardware (typically running some flavor of Unix) connected over a LAN.

Figure 2.2 shows the usual pathways between elements of the server, but in fact any sub-server can talk to any other sub-server should the need ³ arise.

Thus, passing players between sub-servers can be achieved either formally (through the databases) or informally (by direct negotiation between machines). Individual sub-servers may also be in contact with the user database, as shown in Fig. 2.1 (but not in Fig. 2.2, so as to prevent its suffering from dashed line death).

I should point out that academics are experimenting with other architectures, particularly the distributed kind much loved by Science Fiction (Idoru and Otherland both use it, for example). These, and those involving multicast, are not, however, likely to be used beyond academia due to the security and liability issues they raise.