And since each game is developed solely by a company or team, sharing ... With the development of Internet and game industry, MOGs become more and more popular .... provide a set of APIs (Application Program Interfaces) for developers.
An Architecture of Game Grid Based on Resource Router Yu Wang, Enhua Tan, Wei Li, Zhiwei Xu Institute of Computing Technology of CAS Beijing China, 100080 {wangyu, tanenhua}@software.ict.ac.cn, {liwei, zxu}@ict.ac.cn
Abstract. Current MOGs (Multiplayer Online Games) have many drawbacks for their conventional architecture, such as bottlenecks, poor scalability and redundant data. And since each game is developed solely by a company or team, sharing resources among different games is extremely difficult. The aim of grid computing is to fulfill the fully sharing of distributed resources, and we borrow the idea of grid to solve the above problems of MOGs. In this paper, we analyze traditional architecture’s characteristic and propose an architecture of Game Grid based on the technology of Resource Router [1]; other key issues such as the scalability and load-balancing are also presented; a prototype called VEGA [2] Game Grid is introduced and evaluated.
1. Introduction With the development of Internet and game industry, MOGs become more and more popular with Internet users. There have been many online games that support hundreds or thousands players at the same time. As a typical network application, MOGs have many problems in their function and capability for their architecture. Conventional online game’s design usually uses one of the two models: Client/Server or Peer-to-Peer model. In the former model, each client sends the game state update information to a server he has connected and then receives corresponding message from the server. Then the server becomes a critical medium between game players, it will unavoidably be a bottleneck which affects all players’ game performance, even worse it may result in the collapse of the whole game world. In the Peer-to-Peer model [3], each player sends updates to the other players directly, which provides optimal response time to the players. But a pure Peer-to-Peer model is difficult to scale and has no authoritative control to game resources. There is a mirrored-server model [5, 6] which is wildly used in current MOGs, it is a compromise between Client/Server and Peer-to-Peer model, in this model, every player connects to a server closed to him, and a lot of servers perform the same functions as one single server [4]. In fact, in this model the problem mentioned in the forepart still exists. Furthermore, current MOGs have a same problem that they are always developed by a
given company or team and have not provided an entry for other developers. This kind of enclosed game maintenance will inevitably restrain the development of the whole online game industry. The architecture of Game Grid based on Resource Router presented in this paper retains many merits of both models, and resolves some problems which traditional models have. The paper is organized as follows: in section 2, we will discuss some related work, including the other games’ architecture and implementation. Then in section 3, our architecture’s design will be shown in detail, section 4 will explains how this architecture is implemented in a grid environment, and in section 5 we will analysis the benefits of our architecture. Finally, we will talk about some future work of this architecture’s application and give conclusions.
2. Related work Our work is mainly motivated and influenced by two aspects: one is current MOGs architecture’s characteristics [7, 8], the other is the advantages of using Resource Router. These two aspects are also our work’s foundation.
(a) Client/Server
(b) Peer-to-Peer
(c) Mirrored-server
Fig. 1. Traditional models
To some extent, the architecture this paper presents is a mixture of Client/Server and Peer-to-Peer architecture. In pure Client/Server architecture, players send message only to a centralized server; the server computes game state and then issues updates. As shown in Figure 1 (a), we can learn that the server is an authoritative control of the whole game world, and is also a single point of failure in rush hour. The real game companies often have several servers deployed in different place, but still cannot avoid bottleneck, and the players are constrained to playing with players on the same server because every server is independent of the others. Figure 1 (b) shows us a Peer-to-Peer model, differ from Client/Server model, players send their message directly to other players. The most attractive advantage of this model is reduced latency, but it has poor scalability which makes it unfeasible to construct a massive multiplayer online game world using pure Peer-to-Peer model. In the mirrored-server model currently using, as shown in Figure 1 (c), we know that game server mirrors are topologically distributed across the Internet and clients connect to the closest mirror, we can also know that this model must deal with
multiple copies of the game states. Considering latency, scalability, consistency, and authoritative control, each of these three models has its own advantages and disadvantages. The other related work is the Resource Router; it is an important component in VEGA grid, its primary function is maintaining resource routing table, receiving resource request, transferring resource request by special routing algorithm, handling the register/unregister/update action of resources. We only concern how to use Resource Router here. In the following part of this paper, we will show the design of our architecture and will explain the role of Resource Router in detail.
3. Design
Fig. 2. VGG System Architecture
Our Game Grid architecture is a three-layer structure including Resource Router, Game Service Platform (GSP), and Client. The Figure 2 exhibits the organization of the three layers, and the following paragraphs will explain each layer’s role and function; the motivation of our design will also be explained.
3.1. Resource Router To satisfy the need of resource sharing and coordination in wide area, in this architecture we use Resource Router to fulfill the work of resource locating, for that the idea of Routing-Transferring method which Resource Router adopts is effective [1]. The Resource Router works as follows: the resource provider periodically updates its resource information to a router. The routers receive the provider’s resource information and maintain them in routing tables. When a router receives a resource request from a requestor, it checks routing tables to choose a route for this request and transfer it to another router or send back search result to the requestor. In our architecture, the GSP is both the resource provider and requestor. When a GSP registers to a Resource Router, it becomes a resource provider: it will update the information of its online game players to the Resource Router periodically. When a player wants to find some other players to play with, he can submit his search request to the GSP, the GSP will search its local database first, if there are no satisfied records, the GSP will send search request to the Resource Router as a resource requestor, then the Resource Routers works, at last, the requestor will be told which GSP is suitable to search available players next. In our design, we only take advantage of the Resource Router’s characteristics; its detailed mechanism is not concerned in this paper. 3.2. Game Service Platform Game Service Platform is a platform whose function is managing local game resource including game and player’s information, and handling various requests from clients and other GSPs. The request of players includes register, login, logout, select game, update player information, and search other players and so on. As shown in the Figure 2, every client has a connection with a GSP, and every GSP has a connection with Resource Router, and besides, each GSP can connect to the other GSPs directly when needed. When a player wants to play with other players, he connects to a GSP close to him to get other players’ state and address information through the connection with GSP. And then he can directly connects to other players to play game if the game’s start condition is satisfied, the message in a real game is transferred between players, which is a Peer-to-Peer interaction having no relevance with GSP, we will explain its design in detail in the client part. Moreover, through analyzing the game player’s common demands, we sum up some behavior which is necessary to user management and game control, and make GSP provide a set of APIs (Application Program Interfaces) for developers. This set of APIs is designed to the life cycle of an online game; it is a minimum set but adequately to support developing different type of games; so a game developer or team can use these APIs to develop his own game deployed on Game Grid. Table 1 shows a simple introduction about these APIs. Traditional game programs based on the Client/Server or Peer-to-Peer architecture can be deployed on Game Grid with a small quantity of modifications, it makes game sharing on the Internet easier than ever before.
Table 1. VGG interface brief description
API Name reg_newuser Login Choosegame refresh_userlist Search Invite Update Logout
Function Description Register to GSP User login game world Select a game to play Get the newest online user list Search other players in the whole game world Invite other players to play with Update a user’s game information Logout the game world
3.3. Game Client In the client layer, the primary issue is how the clients communicate with each other in the real game procedure. We adopt Peer-to-Peer communication in this layer’s design. Each client sends its game state updates to the other clients who are playing with him in a round of game and receives the other clients’ messages at the same time; we can regard the players in a round of game as a group, and their communication is a kind of group communication. Through analyzing the demands of client's network transmission and characteristics of the Peer-to-Peer communication, we have designed a set of APIs called group communication APIs which makes programming easier and concision.
4. Implementations We implement this architecture through a simple MOG called VGG (Vega Game Grid). The GSP and Resource Router are deployed together; on the client, we use the API offered by GSP to develop an online game GUI (Graphical User Interface). When a player runs the client program, he should first register a new id if he hasn’t one, and then he can login to an available GSP, select a game he wants to play, and then find other players to play game. In this procedure the client only interacts with one GSP, and we choose a TCP-based connection between client and GSP to ensure the message is reliable. Next is the real game procedure, we choose the Peer-to-Peer model to implement the game’s interaction. As shown in the Figure 3, when player A has got B’s address, he firstly sends invite message to B; when receiving B’s confirm message, A and B will start the game to play; when game is over, both clients will send game result to GSP to record the players’ scores. Whether to use TCP or UDP protocol in game message transmission is decided by real game: for a chess game, TCP will be better for its reliability and in-order-delivery;
and for a real-time strategy game UDP-based interaction will be more appropriate for its lower latency.
Fig. 3. A Scene of inviting other players before playing game
5. Evaluations In this section, we will give our analysis to show the architecture’s benefits. Our key issues considered in this part are GSP, scalability, and load balancing related. 5.1. Benefits of GSP Current game server or platform based on traditional model are always designed and implemented for one game or one same type of games and divide game resources by fixed server. Compared to them, our GSP can support global game resource sharing for the various games running on this platform according to our architecture design. We know that GSP handles client resource requests, when the network topology and resource distribution is definite, the Resource Router using SD-RT algorithm can find a resource finally [1]. To the game players, this architecture is single sign-on: once he logs in a GSP, the other game resources including games and other players are visible to him. The test result of our implementation can verify this advantage. In the test, three Resource Router which have several GSPs registered on them are deployed on our lab’s LAN, then we run some client programs on different PCs, here, each client represents a player, they login different GSP, each of them are visible to others and they can play with any online players freely. Furthermore, the GSP offers a set of APIs supporting different game developed by different programmers openly.
5.2. Scalability of the Architecture Scalability is an essential performance for MOG architecture. Traditional Client/Server architecture is a star topology; it has badly scalability for the server’s limitation in performance. As to the mirrored-server architecture, a lot of severs were deployed to do the same thing, but global data was copied to every server, when a new server node is added, the augmentation of the data’s quantity is too massive, which greatly affect the scalability of the whole system. Pure Peer-to-Peer architecture is not good in scalability for the reason that when quantity of clients increases the augmentation of connection between clients will mount up egregiously. The whole topology of our architecture is a mesh topology which is an easy-scale architecture inwardly, as shown in Figure 2, we can deploy a new GSP or a Resource Router optionally, it has no effects to others, client’s request is transferred to different GSP to handle, there has no a single point of failure. 5.3. Load-balancing To the question of load-balancing, we know it is unpractical to eliminate bottleneck absolutely for the limitation of the Internet environment, we can only try our best to reduce the possibility which makes a net node to be a bottleneck. In the traditional Client/Server model, all clients send their messages to the server, their messages include not only requests of finding other players but also game state updates in playing, therefore, the server must handles huge quantities of data from different clients in rush hour and becomes a bottleneck unavoidably for the limitation of the server’s capability and network bandwidth. Even though the mirrored-server model has many servers to handle clients’ messages, there is no difference to the bandwidth’s total consumption. So, we should consider that whether we can make the node which acts as a server handle fewer messages. Just as shown in anterior description of this paper, the architecture we present is better in resolving this problem. The GSP in the architecture acts as a server to a extent, the clients send only a part of messages to the GSP such as login, search user and so on, and when players are in game, the game state updates are sent directly to other players, the GSP is not responsible for computing and transmitting these game state updates which is a majority of data in client’s message set. So for the GSP, bandwidth is saved and load is reduced, the whole system will run more smoothly and can support more players online at the same time. Moreover, we take a mechanism to decrease burden of GSP: when there are too many clients to login the same GSP in the same time, the GSP can transfer a part of login request to another GSP. This mechanism can balance the load of GSP to a great extent.
6. Conclusions and Future work We have designed and implemented an architecture based on Resource Router for multiplayer game which can be deployed on both local and wide networks, and the simulate running of our program has verified the benefits over traditional architecture in platform, scalability and load-balancing aspects. This architecture is not restricted to the game only, and we believe that a great variety of other applications will be benefited by adopting this architecture. There are several aspects in which this architecture could be advanced. Despite we have reduced a majority of data handled by the GSP and taken a mechanism to balance load of GSP, the mechanism we take is somewhat too simple.We can do some research on how to detect the status about the whole system’s load and how to balance the load more efficiently. The security issue has not been concerned in this paper, we need to concern the problems such as user identity authentication, preventing cheating in the game progress and etc. We will do some research in these issues in the future.
References 1. Wei Li, Zhiwei Xu, Fangpeng Dong, Jun Zhang, “Grid Resource Discovery Based on a Routing-Transferring Method”, Proceedings of the 3rd International Workshop on Grid Computing, Baltimore, MD, 2002, pp. 145-156. 2. Zhiwei Xu, Wei Li, “The Research on VEGA grid Architecture”, Journal of Computer Research and Development, August, 2002, 39(8), pp.923-929 (in Chinese). 3. Benjamin H. Brinckerhoff. “Peer to Peer Multiplayer Games”, http://students.cec.wustl.edu/~cs333/calendar/peer2peer.ppt. 4. V. Ramakrishna, M. Robinson, K. Eustice and Peter Reiher, “An Active Self-Optimizing Multiplayer Gaming Architecture”, proceedings of the Fifth Annual International Workshop on Active Middleware Services (AMS 2003). 5. Eric Cronin, Burton Filstrup, Anthony Kurc, “A Distributed Multiplayer Game Server System”, UM EECS589 Course Project Report, http://www.eecs.umich.edu/~bfilsrtu/quakefinal.pdf, May 2001. 6. Eric Cronin, Burton Filstrup, “An Efficient Synchronization Mechanism for Mirrored game Architecture”, Proc. Of the first Workshop on Network and System Support for Games, pp. 67-73, 2002. 7. Jouni Smed, Timo Kaukoranta, Harri Hakonen, “A Review on Networking and Multiplayer Computer Games”. Turku Centre for Computer Science, TUCS Technical Report No 454, April 2002. 8. Jouni Smed, Timo Kaukoranta, Harri Hakonen, “Aspects Of Networking in Multiplayer Computer Games”, Proceedings of International Conference on Application and Development of Computer Games in the 21st Century, pp. 74-81, Hong Kong SAR, China, Nov. 2001. 9. “Butterfly.net: Powering Next-Generation Gaming with Computing On-Demand --An IDC e-business Case study”, http://www.butterfly.net/platform/technology/idc.pdf.
