Design project

1. D E S I GN PROJ E C T 2
CLUSTERED PEER-TO-PEER
COMMUNICATION SYSTEM FOR
MULTIPLAYER ONLINE G AMES
Submitted by:
Shamma Al Marzooqi
Vimitha Manohar
Yomna Mahmoud Ibrahim Hassan

2. Design Proposal 2
1. Introduction
Who does not love to play a good game online? Online games are popular among all
the age groups especially multi-player online games. Playing games together with our
friends, sharing thoughts, sending them gifts and fighting with each other is always fun.
A game popularity increases by its user interface, response time and how interactive it is
with the players. A player plays a multi-player game which becomes popular, and after
some days when there are lots of players playing it. The player finds the game taking
long time to load and responds to the player requests. This will most probably led the
player to quit the game which will affect in turn the game popularity.
These games are based on centralized communication which has drawbacks via
scalability, handling peak-loads, latency and they need costly infrastructure. To improve
the efficiency and to overcome the drawbacks, we propose the use of a peer-to-peer
between clusters network, which is a mix between the normal peer-to-peer (between
servers, which we will call super peers) and the Client-Server (between each super-peer
and its clients) communication. Client submits queries to their super-peer and receives
the results from it. However, the super peers are also connected to each other as a pure
peer-peer network. This new design will make the system scale-up and down
dynamically with the number of players.
So the main objectives of the clustered P2P communication are:
1. To improve scalability by avoiding dependency on centralized points.
2. To eliminate the need for costly infrastructure by enabling direct communication
among clients.
3. Enabling resource aggregation.
In our system we utilize the memory and CPU cycles of peers to maintain the share game
system. We have addressed 4 potential problems to make this approach fully applicable
and practice:
Scalability – It should allow the number of players to grow and decrease with
same level of performance and updates without delay or any delay in the game.
Availability – Replicating the game state to improve availability. Once the peer
goes offline its state should become offline and replica invalid. Or maybe because
of high update frequency; maintaining large replicas becomes bottleneck for
performance.
Interactivity & Performance– Each players have their own state and updates, these
frequent updates must be propagated in a certain time constrain correctly and
efficiently.
Cost – Reducing the cost by using existing infrastructure and by eliminating or
distributing the maintenance cost
2

3. Reliability – Clustering is an efficient approach but still a super-peer becomes
single point of contact to the clients connected to it. If there is a server crash or
super server leaves, the entire client should not become temporarily inactive or
disconnect till a new super server is connected.
In this paper we discuss all the above aspects in detail. The primary contribution is on
the architecture and evaluation. We are presenting an architecture which is for massively
multiplayer games with peer-to-peer networking technology, and we also provide a detail
performance study on the cost reduction with respect to the client –server architecture.
The major concern for peer-to-peer gaming is cheat prevention; there are many
techniques to take care for them, it is a separate issue from the basic performance and
availability of such games. So, we want be discussing the security issues in detail, but we
will give an overview about security in peer-to-peer communication.
2. Design Description
2.1. Overview of the system
Our system is a clustered peer-to-peer system which manages the communication in
multiplayer online games between different servers and nodes (clients). There are
precisely two communications going on in the system which we will take care of. The
communication between the clients (online players) with their server (host of the game)
and then the communication among the different servers (hosts of the game). The
proposed clustered P2P system will overcome the limitation of the other existing system
and will enhance the scalability, latency and reliability of the online game
communication.
2.2. System Architecture
We are trying to make use of both peer-to-peer and client server architecture by
joining them together in one architecture. As shown in figure (1), each game region will
have its own server connected to set of clients. All the messages of the players would be
communicated through their local server, either to communicate in the same region or to
other region players.
The access control of the game sate is available at the central server. All the regional
servers direct to the central server to acquire access to its regional clients.
In the communication between different region players, the player will send the message
to its respective server, and then the servers communicate with each other and send the
message to the other player. Moreover, to provide a proper and reliable communication,
we will add a back-up server which is basically a replicate server imitating the same role
of the actual server.
By replacing the single central server with a group of connected servers, we can make the
system more scalable and overcome many possible bottlenecks of the central server.
Since the central server will gather all the players‟ data in the central structure, when the
number of players goes up, the server will become saturated. The total amount of data
3

4. Design Proposal 2
transferred over the network will be reduced in our distributed architecture. In the online
gaming industry this is of a huge importance due to the enormous popularity of online
games where the number of players is increasing rapidly every day.
Central Server
Client
Regional Server
Figure (1): Architecture of the clustered peer-to-peer system.
2.3. System requirements
Below are the main requirements in the clustered P2P system:
1) The system will operate effectively to manage the communication problem on
Massively Multiplayer online Games (MMGs)*.
2) The system will accept inputs from each game which include game related data
such as game functions and game state(s) variables.
3) The system will distribute the data among the different servers.
4) The system will accept inputs from each player, process it by the server he is
connected to. If the server is not available at that time, it lookup for the nearest
available server by using a lookup table.
5) The system will store all players‟ profiles and inventories between login sessions
in his nearest region server.
4

5. 6) The system should be able to send and receive messages between different
entities in the system architecture.
*Massively multiplayer online games (MMGs) distinguish themselves from other online games by allowing
thousands of players to share a single game world. Most existing MMGs are role-playing games (RPG) or real-time
strategy (RTS)/RPG hybrids. Typical examples of MMGs include EverQuest, Ultima Online, There.com, Star Wars
Galaxies, The Sims Online and Simcountry.
7) The system should be persistent in such a way that it will return to the player his
previously stored data. Also, it should update each player with the changes made
in the game even when his character is offline.
2.4. Design of the system
Distributing storage
A certain game will be hosted in one server, where the original game related-data and
users accounts are hosted. Duplication of the game will be hosted in the other requested
servers. Therefore, whenever a player requests a certain game, the server he is connected
to will take the responsibility of copying that game into his server. This will reduce the
traffic which might happen in the case of hosting the game in only one server. When the
player starts playing the game, a new session will be created and saved in his regional
server. If the server was full at that time, it will look through its lookup table for the
nearest server in which it can store the player‟s data. The lookup table follows the
shortest path algorithm. Each time a player sends a request to a server, the server checks
his lookup table to make sure that the path which was taken by the client is the shortest
path. If not, it should reallocate the client to his nearest available server for the next
request/round. The lookup table will contains the name of the node, the source and
destination address and the path. The system will take care of performing that technique
without going back to the player since we are targeting the design principle of hiding the
complexity from the users. Also, this storage distribution mechanism will achieve the
low memory cost we are aiming in our system. As known in most of the server‟s
architecture, the cost of memory storage in clustered servers is cheaper than one central
server.
Distributing state moves
The transmitted data between the players and the two kinds of server we have in our
design will get updated depending on the player changing state. For example, whenever
he gets more points or wins. We provide security in our design by using a central server
to control the access to the game state. In many games the player should be able to
acquire or control the state of the game. The central server should provide this control
5

6. Design Proposal 2
only to trusted entities which won‟t demonstrate abnormal behaviors. It should register
all the players in the game and monitor their actions to evict them in case of misbehaving
actions. We will utilize our P2P clustered architecture to accomplish scalability in
distributing games updates. The server will divide the game into different regions. Each
time a player makes a positional move, which occurs when a player moves in the game
without affecting game state, an update will be sent to his regional server. The server in
turns sends the move to the other players in his game region. On the other hand,
whenever the player performs a state-changing move, which changes the game state, the
move will be sent directly to the central server. If the central server accepts the state
change, it sends the results back to the player and updates the affected regional servers.
Example of state-changing move is when a player attacks another player or crosses
important boundary.
Figure (2): Distributing positional and State-Changing Moves
Distributing computation
Some online games like “second life” require the player to download some executable
file in their machine. This executable will contain images and animation libraries, where
the unchanged-state computations are performed. For instance, in second life this
6

7. executable will do the calculation of drawing and showing the characters in your system
instead of the server. Whereas, computations related to changing the player state such as
buying a new house will be performed on the server. This will distribute the computation
load to the different nodes in the game network, which will reduce the load on the server.
Nevertheless, since it is not always the case, in many other games like “Farmville” all the
computation load will be on the server.
When a request is sent from one entity to the other in the system architecture, it is been
queued up first in the server. Then, it processes the request in a sequence using roundrobin scheduling algorithm. We chose round-robin because it has been widely used in the
games communication and has proven its successes. Also, it is simple algorithm to
implement and illustrates a fast average response time which is a critical design objective
in our system. Thus, the server will iteratively chooses the first request in sequence,
processes it for a certain amount of time, let say each round may last for several hundred
milliseconds and finally put the output message in the outgoing queue. This queue will be
distributed later among all the related players and servers.
It is significantly important to point out that messages are sent between the servers in an
aggregation style. After each complete round the messages will be combined together
and sent once through the optical fiber between the communicated servers. This will
reduce the time spent in going back and forth between servers. Let consider two
examples of two players playing Second life. First example is between two players
communicating in the same game region. The request of the first player will go to his
regional server, it will check the destination address and realizes that it belong to the
same region and deliver it accordingly to the other player. The second example is
between players from different game region. The request will go first through the
regional server of the sender, it then checks the destination address and realizes by using
its lookup table that it belongs to other server. The server subsequently forwards the
message through peering with his neighbors to reach the destination server in the shortest
path. Finally, the destination server takes the responsibility to deliver the message to the
second player.
Obviously, the cost of the communication in the first example is less than the second.
When two players communicate in the same region, they reduce the path cost. Therefore,
our system divides the game into regions. Each will have a server and will demonstrate a
coherent relationship among the participants of the system.
7

8. Design Proposal 2
Synchronization between players/ and servers:
Figure (3): Distributing positional and State-Changing Moves
Fairness and responsiveness are measures to evaluate the performance of message
synchronization. In fair synchronization, event messages sent by participants are
processed in the exact order of the time the messages sent.
Figure (4): Distributing positional and State-Changing Moves
Game is divided into a set of functions, internal data and input user. When the server
receives an input from user, it checks if the user wants to create a new game session or
wants to join an existing session.
8

9. Let‟s see how the communication is initiated between a client and a server, first the
player signs in to his profile, if the player is going to start the game, create new session
with its properties, wait for other players to join and be ready, change state to game
started. If going to join, find a game with empty slots. Finding a session is when player
press (start game). Stating how many of the session slots are reserved for players who
join through invitation. If this number is equal to the number of session slots, the session
will accept only invited players.
Code of finding a session with an available slot:
public void FindSession()
{
// All sessions found
AvailableNetworkSessionCollection availableSessions;
// The session we'll join
AvailableNetworkSession availableSession = null;
availableSessions =
NetworkSession.Find(NetworkSessionType.SystemLink,maximumLocalPlayers,
null);
// Get a session with available gamer slots
foreach (AvailableNetworkSession curSession in
availableSessions)
{
int TotalSessionSlots = curSession.OpenPublicGamerSlots +
curSession.OpenPrivateGamerSlots;
if (TotalSessionSlots > curSession.CurrentGamerCount)
availableSession = curSession;
}
// If a session was found, connect to it
if (availableSession != null)
{
message = "Found an available session at host " +
availableSession.HostGamertag;
session = NetworkSession.Join(availableSession);
}
else
message = "No sessions found!";
}
Finding and Joining a Session Asynchronously
Coding for asynchronous session searching is an approach commonly used in games
because you usually don‟t want to freeze the game and the player options when searching
for available sessions. The basic idea for session finding and joining is the same as you
saw in the previous
IAsyncResult AsyncSessionFind = null;
public void AsyncFindSession()
9

10. Design Proposal 2
{
message = "Asynchronous search started!";
if (AsyncSessionFind == null){
AsyncSessionFind = NetworkSession.BeginFind(
NetworkSessionType.SystemLink, maximumLocalPlayers,
null, new AsyncCallback(session SessionFound), null);
}
}
//BeginFind receives the same parameters from the Find method
discussed in the previous
//section (session type, maximum number of players, and custom
session properties
public void session SessionFound(IAsyncResult result)
{
// All sessions found
AvailableNetworkSessionCollection availableSessions;
// The session we will join
AvailableNetworkSession availableSession = null;
if (AsyncSessionFind.IsCompleted)
{
availableSessions = NetworkSession.EndFind(result);
// Look for a session with available gamer slots
foreach (AvailableNetworkSession curSession in
availableSessions)
{
int TotalSessionSlots = curSession.OpenPublicGamerSlots
+ curSession.OpenPrivateGamerSlots;
if (TotalSessionSlots >
curSession.CurrentGamerCount)
availableSession = curSession;
}
// If a session was found, connect to it
if (availableSession != null)
{
message = "Found an available session at host" +
availableSession.HostGamertag;
session = NetworkSession.Join(availableSession);
}
}
}
This code excerpt is almost identical to your FindSession synchronous method; in fact,
only three lines are different:
1. The test to check the AsyncSessionFind.IsCompleted property to see if the
results are already available.
2. Using NetworkSession.EndFind (instead of NetworkSession.Find) to retrieve
the available sessions collection.
10

11. 3. The last line of the listing, where you simply reset the AsyncSessionFind
result variable.
Reliability and availability are two very significant design issues which will be
address in our system. To obtain the highest number of players in any game, it should
satisfy the user expected requirements. Players tend to leave the game very quickly if
they didn‟t get the expected outcome in the screen in a short time, or if the game
resources weren‟t available. To maintain the game popularity, the system should be able
to provide each player with his needed states and data quickly. Our system has additional
back-up server in each regional server with replicate data from the original server. If the
regional server crashes, this back-up server will act similarly to the original one. The
distributed architecture in the design will be robust since each regional server will be
independent and won‟t be affected a lot in case of other server‟s crashes. For example, if
a server in game distributed regions fails, it will use the backup server. If the latter server
crashes as will it will only affect the state of his region players. The other servers in the
system will lose communication with that server and will maintain the stored updates
from that server for a certain amount of time before deleting it. When the server is fixed,
the player initial data could be retrieved from the hosted server of the game.
3. Workload Description
Our system is targeting mainly multi-player online games. We discovered that most
of the Massively Multi-player online games (MMGs) are divided into three categories:
First Person Shooter (FPS), Role- playing games (RPG) and Real-time strategy games
(RTS). In this section we will explain briefly every category and what are the critical
aspects needed to be established concerning the networking for the game to run without
issues. For MMOGs, although the bandwidth requirement of each game client might be
small, the number of concurrent connections could be very large. For instance, the record
of 370,000 players online simultaneously (Ragnarok Online, Taiwan, 2004) implies that
at least 3.7 Gbps of bandwidth is required, assuming each client needs 10 Kbps on
average.
11

12. Design Proposal 2
Figure (5): amount of subscribers in different online games
 First Person Shooter games (FPS):
These are the games where the player takes the role of the "camera eye," meaning that the
screen to some extent represents a person's view of the world, examples for this genre of
games online are: Global Agenda , World War II Online & Planetside. These games,
although they don‟t require communication between different players, but they are very
popular that they consume a huge bandwidth on the network. Also, these games need to
be quickly responsive to the player‟s actions. This will put some boundaries on the
latency of the network, as it can‟t exceed a certain amount, after which the game will be
considered flawed. And in many FPS games, exact positioning and timing is required,
because, for example, a target must still be at the location where the player aimed in order
for the shot to hit.
12

13. Figure (6): A screenshot from “Doom”, a First Person Shooter Game on PC
 Role Playing Games (RPG):
These are the most famous and interactive type of MMGs. The Player in this game takes
the role of an adventurer. It consists of series of battles between multiple players; where
the progress of the game will be depend upon winning the different levels until the end of
the game. Examples of RPGs online are: Pirates of the Caribbean online, Hello Kitty
online and Gods War online. RPG and other adventure-oriented games do not require
participants to „„play‟‟ all the time. During a game, players can do anything at will: they
can carefully inspect their equipment; wait somewhere for friends or some event; or
simply leave their characters idle. Most of the companies design the multi-player RPG to
be browser-based to reduce the infrastructure cost and reuse an application that most of
the users have already installed on their machines (browser). And even though changing
the games‟ platform to be hosted online reduced the cost on the publishing companies
from the hardware aspect, but still it has heavy requirements on both the hosting server
and the networking. Although these games are not concerned with the latency as in the
FPS games, but they rely completely on the consistency on the messages transferred
between the players, and the persistency of the state of the game of each player (so when
the player logs off the game, the next time he logs on, he finds himself in the last state he
left the game in).
13

14. Design Proposal 2
Figure (7): a screen shot from “Age of Empires”, an RPG game.
 Real-Time Strategy Games (RTS):
Players often assume the role of a general, king, or other type of figurehead leading an
army into battle while maintaining the resources needed for such warfare. Player
manages a kingdom or civilization, growing it in space and power over time. Examples of
this type included Monopoly City Streets, Navy Field and Society. In the past, this type of
games didn‟t hold much popularity, but they started to spread more since the increase of
Social Networking websites. An example of one of these games is Farmville (Fig.8).
14

15. Figure(8): a screen shot from “Farmville”, RTS online game
RTSs has similar requirements to that of RPGs, although they may need more
responsiveness, as most of them are hosted on websites used mainly for fast
communication between people and not for gaming. We find that MMORPG and FPS
(First-Person Shooting) games are similar in that they both generate small packets and
require low bandwidths. In practice, the bandwidth requirement of MMORPGs is the
lower of the two due to less real-time game playing. Also we consider the irregularity,
which is unique to MMORPG traffic. The irregularity is due to the diversity of the
game‟s design so that the behavior of users can vary drastically, depending on the quest
at hand. In many RTS games, the positioning and timing is more forgiving because, for
instance, a command can be issued to attack a unit, regardless of its current location or its
direction and time of movement. So generally, RTS games have low latency
requirements, similar to that of web-browsing (in order of seconds).
15

16. Design Proposal 2
4. Workload Analysis
As we mentioned in the previous section, each workload has specific requirements.
To check what our game can achieve for each type of workload, we made the following
analysis. This analysis is based on the different resources used by the network system,
which are: latency, bandwidth and computation power. For this analysis, we chose a
game from each genre of games, where previous researchers reached numbers about the
usage of the network resources in each of them. The games we will be talking about are:
ShenZhou Online, a commercial, mid-sized RPG; Counter-Strike, a popular FPS online
game; and Warcraft III as a representation of RTS games.
The average per user upstream bandwidth usage for game traffic varies from 3 to 7 Kbps
(maximum from 10 to 50 Kbps) in different markets. (approximately1% or less) who are
actively playing network games. As network games gain more popularity, this number is
going to increase. Unfortunately, the bandwidth usage would definitely put an upper limit
to the number of users that can be playing simultaneously and experience the service
quality required, especially in a shared access environment.
To see the effect of our implementation, we will study the messaging occurring between
clients and servers, & clients and clients. Also in our calculations, we assume that the
time taken for scheduling the players‟ processes for processing is the same in both cases
of networks (client/server & P2P), so we won‟t take it into consideration. Know that in
P2P communication, there is a linear relationship between work traffic and the number of
concurrent player, also there‟s a linear relationship between network traffic and CPU
utilization for computations (region/game).but in case of Client/ server communication,
there‟s a linear relationship between traffic and the number of concurrent player, but
increasing the CPU utilization with increasing the number of concurrent players will lead
to bottle-necks, so CPU utilization in this case is limited.
Also, we should consider that, the communication using optical fibers (which basically
covers the P2P communication between servers), has a speed of: 4.8 G-bits/s; and the
communication using Ethernet cables, which is mainly used for the client/ server
communication, has a speed of transfer of 10M-bits/s. And we will consider that servers
have a processing power of 3Ghertz or more, where in our case, Hertz will represent on
command (query) per second. Let‟s say that messages transferred within the system are
divided into 4 types: messages between one player and another one in different regions,
messages between server and its client, messages from one player to its peers in the same
region and messages from a server to the central server (that happens in critical
decisions). Assume that each type of messages has a frequency that ranges between 0 and
1. This frequency depends on the game type.
In all games, each query (command) will have size of 82 bytes+ query packet length.
From previous research, each query will need (0.5 + 0.004 * query Size) in case of
Client/Server Application, while it will only need (0.44+0.003 * query size) in case of the
P2P communication as we distributed the computation load.
And remember, by doing aggregation of messages that are between servers (P2P), which
is transferring messages in batches instead of transferring each message on its own; this
will decrease the frequency of transportation, decreasing the transfer time.
In the following diagram, we will describe the requirements for each workload
concerning the communication and its resources.
16

17. FPS
• The average bandwidth requirement per client is about 40 Kbps
• the amount of delaythat can be tolerated by a player varies somewhere
between 100 and 150 ms.
• are usually round-based so that players are forced to be idle if they are
defeated, but they can be active again in the next round, so that packets
produced are random, and larger in size than packets produced for
example in RTS
• High locality ( internal computational power on client), but low on server.
• Communication to the central server for critical decision: High.
• Communication between different Players: Low.
• Communication with server only: Low.
RPG
• The average bandwidth requirement per client is about 7 Kbps (lower
bandwidth requirement is due to the relatively slow pace)
• latencies above 225–250 ms are intolerable for players
• similar packet size and periodicity to FPS
• Low locality
• Communication to the central server for critical decision: Low.
• Communication between different Players: High.
• communication with server only: Medium.
RTS
• similar to RPG, the average bandwidth bandwidth requirement per client
is about 7 Kbps
• Latency values of up to 3.5 s, which is less than 1% of the total time for
this game
• RTS games basically produce small, regularly spaced packets and modest
aggregate bitrates which make it suitable for play over a low bit-rate
modem
• Low locality
• Communication to the central server for critical decision: Low.
• Communication between different Players: High.
• communication with server only:High.
17

18. Design Proposal 2
In the next figures, you will see the analysis of each game type depending on what type
of communication system we use, and we will see when it will be better to use our design
(Cluster P2P).
1-Traditional Client Server Communication:
FPS
RPG
RTS
Bandwidth
Bandwidth
Bandwidth
• 40 Kbps
• 7 Kbps
• 7 Kbps
Latency
Latency
Processing
Power
Latecy
Processing
power
Processing
power
18

19. 2- Cluster Peer-to-Peer communication:
FPS
RPG
RTS
Bandwidth
Bandwidth
Bandwidth
• 40 Kbps
• 7 Kbps
• 7 Kbps
Latency
Processing
Power
Latency
Latecy
Processing
power
Processing
power
Assume we will do the calculation within a second time (1 second).
Latency equation = (frequency of the type of command occurring * packet
size)”both of these define the required bandwidth for each game type”/ rate of
transfer “fiber/Ethernet”.
Communication between players f1 (covers 2 types): low in FPS, high in others
Critical decisions f2: high in FPS, low in other Between player and its server f3: low in
FPS, medium in RPG, large in RTS
Assume high = 0.8, medium =0.5, low =0.2
19

20. Design Proposal 2
-
-
-
FPS in traditional: large packet/ (server/client rate) *(f1+f2+f3)= (0.8+0.2+0.2)*40/
10Mbits/sec=4.8 *10^(-6) seconds
RPG traditional: large packet/ (server/client rate) *(f1+f2+f3)=
(0.8+0.2+0.5)*7/10Mbits/sec= 1.05 * 10^(-6) seconds
RTS traditional: large packet/ (server/client rate) *(f1+f2+f3)=
(0.8+0.2+0.8)*7/10Mbits/sec= 1.26 * 10 ^(-6) seconds
FPS new: f1 *(large packet)/(average of server and player rate) + f2*(large packet)/
server rate +f3* packet size/speed of (client/server)=
0.2*40/(10Mbit+4.8Gbit)+0.8*40/(4.8Gbit)+0.2*40/(10 M-Bits/sec)=8.0166*10^(-7)
RPG new: f1 *(small packet)/(average of server and player rate) + f2*(small packet)/
server rate +f3* packet size/speed of (client/server)=0.8 * 7/(10Mbit+4.8Gbit)+
0.2*7/(10Mbits/sec)+0.2*7/(4.8Gbits)= 1.414 * 10^(-7)
RTS new: f1 *(small packet)/(average of server and player rate) + f2*(small packet)/
server rate +f3* packet size/speed of (client/server)= 0.8 *7/( average of server and
player rate)+ 0.2 *7/( client/server)+0.8*7/( server) = 1.4233 *10(-7)
Processing time = time taken by the query to process * amount of data size in bytes
FPS in traditional: “40”large packets (0.5 + 0.004 * query Size) =0.66 ms
RPG traditional: “7”small packets (0.5 + 0.004 * query Size) =0.528 ms
RTS traditional: “7”small packets (0.5 + 0.004 * query Size) =0.528 ms
FPS new: large packets”40” (0.44+0.003 * query size) =0.56 ms
RPG new: small packets “7” (0.44+0.003 * query size) =0.461 ms
RTS new: small packets “7” (0.44+0.003 * query size) =0.461 ms
6. Conclusion
7. Acknowledgment and references
[1] YE , CHENG, “System-performance modeling for massively multiplayer online
role-playing games”, IBM SYSTEMS JOURNAL, VOL 45, NO 1, 2006.
[2] B.Yang, H.Garcia-Molina, “Designing a Super-Peer Network”, Computer Science
Department, Stanford University.
[3] B.O. Knutsson, H. Lu, W. Xu, B. Hopkins, “Peer-to-Peer Support for Massively
Multiplayer Games”, IEEE INFOCOM, vol. 1, pp. 2, March. 2004.
[4] J. Jardine, D. Zappala , A Hybrid Architecture for Massively Multiplayer Online
Games, pp. 60-65, 2008.
[5] J.Smed; T.Kaukoranta; H.Hakonen, “A Review on Networking and Multiplayer
Computer Games”, Turku Centre for Computer Science, TUCS Technical Report No
454, April 2002.
[6] M.Claypool, “The effect of latency on user performance in Real-Time Strategy
games”, CS Department, Worcester Polytechnic Institute, May 2005.
20

21. [7] Keen and Graev‟s forum; Available at: http://www.keenandgraev.com/
[8] List of massively multiplayer online games, Wikipedia, the free encyclopedia;
Available at:http://en.wikipedia.org/wiki/List_of_MMOGs
[9] Prof. David Golumbia, MDST110 Electronic Coursebook for Students ,
Information Technology and Digital Media Studies, University of Virginia , Fall
2004; Available at :
http://people.virginia.edu/~dg6n/classes/0405.1.fall.mdst110/lectures/20.html
[10] Counter-Strike, Wikipedia, the free encyclopedia; Available at:
http://en.wikipedia.org/wiki/Counter-Strike
8. Words count
5000
21

22. Design Proposal 2
22