In this chapter, we are going to introduce some background knowledge you need.
It will help you to understand our system design clearly. Section2.1 is an introduction of some distributed architectures we are using in MMOG middleware today. Also it will give you a basic concept of what mechanism might be needed for fail-over and load distributing. In Section2.2, we introduce some important game data that appears commonly in MMOG middleware. The next section we are going to talk about a MMOG middleware named DOIT [2] which was developed by Distributed System Lab. of National Chiao Tung University. DOIT is a flexible, scalable, easy-to-use MMOG middleware. Section2.4 includes a standard specification about availability which is adopted by HAMS. Finally, we will give a discussion.
2.1. Common Network Architectures of MMOG middleware
There are many kinds of network architecture of MMOG middleware [3].
Following are some commonly network topologies in MMOG. Through this overview you will see the most common MMOG middleware architectures. One of the design goals of HASM is able to be applied in all these architectures.
2.1.1. Client – Server
This is the most popular network topology adopted by MMOG middleware today.
Clients connect to the game server and start to play. The number of game servers depends on the scalability of the MMOG. Each game server is responsible for different game logics, and usually the servers are separated by the geographic of the game world. Avatars move to different part of game world also migrate their connections to another server at the same time. Client-server architecture is used in
many games (Quake, EverQuest) because it is cheating avoidance and easy to maintain. However it may have the single point of failure and server overloaded if there is no other mechanism with it.
Figure 2-1 client-server network architecture
2.1.2. Client – Gateway – Server
Client-gateway-server architecture is actually an improvement of client-server. in client-server, players connect to the game server directly, because each server’s I/O connections is limited, there can not be too many avatars play in the same area of game world at the same time even though the server still underload. It is not a reasonable constraint because avatars people are gregariousness. In client-gateway-server architecture, clients connect to gateway instead of connecting to game server directly. It breaks the I/O connection limitation of each game server and improves the scalability of client-server architecture. However, introducing gateways does not solve single point of failure neither overloaded problem.
Figure 2-2 client-gateway-server network architecture
2.2. Important Game Data of MMOG Middleware
In section2.1, we know that modern MMOG are always hosted in a server cluster.
There are some important data includes in a game server. When we talk about availability, the most important part is game data protecting. The following will help you to understand the various game data types in MMOG.
The words region, cell or unit and are addressed in many papers related to MMOG or DVE (Distribute Virtual World). All of them represent pieces of game world. There are many approaches to divide the world such as in quadrangle or polygon. Even, there are many researches proposed dynamic partition algorithm in order to reach the most load balancing system.
Figure 2-3 Game world partition
Game logic is the largest part in a game. It indicates what will happen after each
action is created by an avatar. For example, an avatar may lose its health after he/she is hit by a NPC (non-player character) or learned new skill after the avatar use a skill book. These complicated game logics are maintained by many game servers and might be distributed into different servers just like game regions.
Avatars’ status information is very important data in the game servers. It represents the current state of an avatar such as healthy, skill, level and etc. Avatar’s status is updated after the result is calculated by server according to the game logic and avatar’s behavior.
2.3. DOIT
DOIT is a flexible, scalable, easy-to-use MMOG middleware which was developed by Distributed System Lab. of National Chiao Tung University. DOIT is based on client-gateway-server architecture and it divides the game world into
“Regions”. The architecture overview of DOIT is in Figure 2-4. The architecture and the design issues of DOIT did a great inspiration of this paper.
Region
In DOIT, the game world is divides into many regions. The Avatar connects to one gateway and be dispatched to the server which handles the region that this avatar logged out last time. As the avatar move to region that does not belongs to current server, it will be migrated to another game server and gateway will start to dispatch avatar’s message to new server.
Coordinator
Coordinator in DOIT is a command line interface that provides game maintainers some utilities such as region migration. Through coordinator, we can move regions form one server to another.
Figure 2-4 DOIT architecture
2.4. AIS (Application Interface Specification)
The Application Interface Specification (AIS) [4][5] is a standard for high availability middleware which is developed be Service Availability Forum (SA Forum). It provides many high availability standard APIs which will be widely used in our system.
This is originally defined for carrier-grade applications which are developed by vendors themselves, and not portable across different vendors’ implementations. The term high availability (HA) represents the services availability should up to a range near 99.999%, or simply imply the application down time should not large than 6 minutes in one year. There are some other requirements for carrier-grade applications in [6].
There are six services defined in AIS: Availability Management Framework , Cluster Membership Service, Checkpoint Service, Event Service, Message Service and Lock Service. We introduce three kinds of services that are useful in our solution.
Cluster Membership Service
The Cluster Membership Service provides membership information about the nodes in a cluster to the applications. A cluster is simply a set of nodes with unique identifier that are connected together by network. As nodes join and leave the cluster, cluster membership changes.
The Cluster Membership Service provides functions that allow applications to retrieve the membership information and monitor the changes in membership.
Checkpoint Service
The Checkpoint Service provides a facility for an application to preserve its state across hardware and software faults. If a node fails or restart, it can recover it’s state quickly by retrieving the checkpoint data.
Checkpoints are cluster-wide entities that are designated by unique names. A copy of the data stored in a checkpoint is called a checkpoint replica, which is typically stored in main memory rather than on disk for performance reasons. A given checkpoint may have several checkpoint replicas stored on different nodes in the cluster to protect it against node faults.
Event Service
The Event Service is a publish/subscribe multipoint-to-multipoint communication mechanism that is based on the concept of event channels, where a publisher communicates asynchronously with one or more subscribers over an event channel.
Multiple publishers and multiple subscribers can communicate over the same event channel, and publishers can also be subscribers on the same event channel.
Individual publishers and individual subscribers can communicate over multiple event channels.
The OPENAIS is an open source project to implement Application Interface Specification. OPENAIS began development by MontaVista Software in January 2002. It covers all services defined in AIS and another extends services named Evs.
OPENAIS uses TOTEM multicast network [7] for its communication protocol.
TOTEM first been proposed in [8] and be improved in many researches [9][10]. Also Efstration Thomopoulos measured the message latency of TOTEM in [11]. The recovery performance has been proven in our previous work [12], and the message latency is short even in large scale. TOTEM provides total ordering and reliable multicast and membership protocol which maintain all cluster nodes’ join and leave.
2.5. Discussion
In this chapter, we describe the most common architectures of MMOG today and the basic concept of what a MMOG looks like. We know that the MMOG middleware are usually operated in many game servers which are responsible for pieces of the game world. Avatars (clients) connect to the servers directly or through gateways and start to interact with other characters in the game world. There are many important data in the game server such as game regions, game logics and avatars’ status.
Protecting these game data helps us to relieve the damage from server failure. Game data migration could decrease the load in servers.
The Application Interface Specification defines many useful services to manage the application data and hardware resources. Its high efficient membership service and checkpoint service is useful in distributed system architecture. The open source implementation OPENAIS is a high performance and fully distributed middleware.
The membership service in OPENAIS has been proofed by our previous work. Many
developers are now trying to deploy their application on OPENAIS, so the OPENAIS develop group still keep working on this open source. The latest distribution 0.74 has become very stable and we think it should be useful in HAMS.