There are many researches and articles related to the issues of availability of MMOG. In this chapter, we are going to introduce you some representative approaches. These approaches can briefly be divided into two kinds. Section3.1 is some algorithm base solutions of availability. They proposed algorithms to solve the load distributing problem. The other kind of approach is architecture based. We introduce you three kinds of architectures which have the ability to solve failure or overloaded problems. They mainly get these advantages from the architecture they design but will not propose any algorithm in the availability issues.
3.1. Load Distributing Technology
In [13], they proposed a global load sharing algorithm called DLS which have the capability to distribute the load to all servers through recursively dispatching their load to neighbor server. These solutions may invoke many of network transfer in one time and might cause network burst. There is another similar algorithm proposed by Kyngmin Lee and Dongman Lee in [14].
Figure 3-1 is an example of the algorithm. While a server S00 found that it is overloaded, it first sent to its neighbor server S10, S11, S12 and S13. Each neighbor will recursively execute the sharing algorithm until the S00 is underload or there is no other server to share. This time complexity of this algorithm depends on how many servers are there in the cluster.
Another kind of load distributing strategy is local load distributing. In [15], Dugki Min provided a local load sharing algorithm which just distributes the load to neighbor server. It reduces the network traffic through the execution but can not distribute the load to all servers once.
Figure 3-1 Global Load Sharing Algorithm in [13]
3.2. Peer To Peer MMOG
Peer-to-peer is a newly technology comparing with client-server architecture.
The main idea of P2P is let the clients maintain their own game logic calculation and state copy. Often, P2P games are based on fully connected overlay network which has no central server and. Generally, in P2P, the players’ status change should be sent to other peers so they can update there “scene” synchronously. The most well known advantage of P2P architecture is robustness. There is no single point of failure and overloaded in P2P games because clients are responsible for their own calculation and even one of them crashes, it does not affect others. Moreover, we can easily recover the failed data from other peers when the failed client reboots again. However, since interactions and accounting information are not verified by any server, cheating is possible. And also, each client’s status change should be sent to all other clients, it cause heavy network overhead and complicated consistency issue in P2P. There are
few P2P MMOG game, the representative of them is MiMaze [16] [17]. Also, some researches about p2p game cheating problem [18].
3.3. Mirror Game Server
In [19] is architecture of MMOG middleware called Mirror Game Server. Mirror Game Server is actually an improvement of client-server architecture. In client-server architecture, each game server is responsible for one part of game world. But in mirror game server, there is a group of game servers that serve clients connected to the same part of game world. Duplicating each server to a group has some advantages, such as load balancing and fault resisting. However, since clients distributed in the server group are related to the same game world, each status update should be sent to all servers in the group. This cause complicated consistency issue between the servers ([20], [21]) and also increase the network traffic load. Moreover, because the availability relies on the number of the “mirrors” (game servers in the same group), we may add too many servers to one group that is not necessary and waste the hardware resource.
Figure 3-2 Mirror Game Server Architecture
Figure 3-2 shows the architecture of mirror game server. The servers belong to the same mirror ({A,B,C} {D,E}) are replications of each other. Clients connected the nearest game server and begin to play the MMOG. The game data information is totally synchronized in each server belongs in the same group. While server A crashed, both server B and C can take over the clients which were connecting with A.
3.4. DOIT Coordinator
Another approach to solve the overloaded problem was proposed in [2] DOIT by adding a central controller named Coordinator as Figure 2-4. Because coordinator is a central control technology, while the coordinator fails, there is no way to balance to load. Moreover, it only provides region migrate, game developers can not move other game object by coordinator.
3.5. Summary
Above are some researches in availability issues of MMOG middleware. All of them had big contributions. Unfortunately, many of them have their weakness. Our solution takes their good concept and fixes the drawback.
In HAMS, we hope that there is no central controller so we can overcome the single point of failure. Second, HAMS is aimed to the widely used server architecture of MMOG middleware which means it must be easily to management and difficult to cheat. Under this consideration, the p2p and mirror server architecture are both not proper for HAMS. Eventually, HAMS hopes to provide more efficient solution in both fail-recovery and load sharing and also a flexible interface for MMOG middleware developers.