MINI PROJECT REPORT

On

QOST FOR GAMES ON DEMAND

FOR

QOST

BY

CHAWANDKE ROHIT SURYAKANT

PRN: 091030

A brief look at the computer gaming industry:

The computer gaming industry consists of two major types of actors – the
game developers and the game publishers (although sometimes the
developer and the publisher is the same company – when in-house
studios develop games). The developer is the studio that develops a
game. They create the entire game either from scratch or from a license
on the games engine. The publisher’s skills lie in identifying and financing
games that sell and market these towards the distributors and retailers.
When the game is finished, the physical copies of the game are created.
This is called “going gold”, which refers to the actual pressing of CDs and
DVDs, the medium on which the game is distributed by to the retailers. A
developer pitches an idea for a game with a publisher, and since creating
games is costly and takes time, receives an advance that will keep him
going until the game goes gold. The publisher then takes the profit until
the advance is covered and then splits the profit with the developer in a
ratio depending on the contract. Of course, the costs for creating a game
differ wildly. Some games are created with five or six people working full
time for a year or two, whereas other games can at times employ 60-100
people over a period of five years. Those big titles are called “AAA”, and
are expected to sell good worldwide. A “typical” AAA title had a budget
around 2 million US dollar in 2001, and budgets significantly higher exist.
The personnel involved in creating a game follow an inverted u-
curve. The initial size of the staff is small and continues to grow until the
game is approaching a state of near completion. At that time most of the
staff is laid off and at best, a small team remains to support and patch the
game. The continuity in the game developer business is therefore small,
as it is difficult for most developers and publishers to eliminate downtime
for the personnel in between games33. Although the money leak is
plugged when the personnel is laid off at the completion of a game, the
continued support of the game may suffer. This was adapted to the
situation some years back, before the growth of online play, because a
game sold most copies the first month it was released. 34 The consumers
bought the game, played it and put it away, perhaps a few patches was
released closely after the release. With the exceptional success of
Counter Strike this was changed. CS attracted new players long after its
initial release and prompted the owner Valve to support the game with
updates for, when this is written, five years. Five years is an eternity for a
game to survive, especially with such a large fan base that CS enjoys. The
online multiplayer community demands constant updating to remain
faithful to the game. Crappy support will cause them to leave the game
and, consequently, not buy the expansion packs. However, the majority of
gamers still buy the games for single player, and the hardcore multiplayer
fan base is a minority still. The Entertainment Software Association, ESA,
reported that “43 % of most frequent game players say they play games
online”, but that includes simple browser-based games, online trivia,
puzzle board games etc.
With the recent explosion in deployment of services to large
numbers of customers over the Internet and in global ser-vices in general,
issues related to the architecture of scalable servers are becoming
increasingly important. However, our understanding of these types of
applications is currently limited, especially on how well they scale to
support large numbers of users. One such, novel, commercial class of
applications, are interactive, multiplayer game servers.
Multiplayer games are both an important class of commercial
applications (in the entertainment industry) and they can be valuable in
understanding the architectural requirements of scalable services. They
impose requirements on system performance, scalability, and availability,
stressing multiple aspects of the system architecture (e.g. compute cycles
and network I/O). Recently there has been a lot of interest on client side
issues with respect to games. However, there has been little or no work on
the server side. In this paper we use a commercial game server to gain in-
sight in this class of applications and the requirements they impose on
modern architectures.
The amount of bandwidth and associated latencies available to
Internet's end-users has been improving rapidly. This offers the prospect
of delivering traditional as well as novel services to large numbers of
clients. Improved networks are only one of the conditions necessary for
this prospect to materialize. In addition, powerful servers are needed to
pro-vide the required compute resources. The higher the number of
clients and the quality of the provided service, the higher computing
resource demands placed on the server side.
Understanding the scalability of such services (i.e., how their
demands change with the number of clients) is essential for designing
server architectures to successfully support them. While the scalability of
scientific workloads has been studied extensively, little is currently known
about the scalability of commercial applications. Interactive multiplayer
games are a class of commercial applications that has not been studied
thus far and that is interesting especially for the entertainment industry.
This class of applications has gained a lot of attention lately due to the
potential for providing customizable entertainment. Practically all modern
titles today include an online, multiplayer mode.

In virtually all cases, multiplayer games are enabled by a central

server. Clients connect to this server who is responsible for interpreting
their actions, maintaining consistency, and passing information among
them. A variety of multiplayer games exist with different characteristics
and demands varying from simple card games, up to role playing
environments with hundreds of users. There is no single application that is
representative of all such servers. In this work we focus on first person
action games. We believe that this game architecture is the prime
candidate for evolving into highly interactive simulators. First person
action games support ₃ne grain, close to instantaneous control of player
actions and a high degree of interaction amongst the players and a
detailed 3D virtual world. We believe these properties are fundamental for
simulating a believable environment with a degree of freedom and
response times that approximate real life experience. While other
multiplayer games players exist, the level of interaction is typically
coarse. In the interest of space, we will use the term server to refer to
servers for first person action games in the rest of this paper.
Current servers are limited to few tens of users. These types of
multiplayer games can benefit dramatically from scalability. Being able to
support hundreds (and eventually thousands) of users opens up additional
opportunities for interaction and may enable new games or online multi
person experiences (e.g., a virtual world where hundreds of players
interact simulating real life. Accordingly, it is important to understand how
game servers behave and what bottlenecks may exist. Recent work has
focused on client side issues related to the CPU and graphics subsystems.
Overview and Background:

Online gaming or online games are the games that are played online
via the LAN, Internet, or even Telecommunication. They are distinct
from video and computer games that are not networked. Normally, all
technical requirement for playing online games is a web browser
and/or appropriate client software. A game played in a browser is
called a browser-based game or web game. In broad definition, online
gaming includes Internet gaming, web gaming, online gambling, local
LAN gaming, and mobile gaming, but not the non-networked video and
personal computer gaming. Figure 1 illustrates the different types of
online games. Within the diagram, the overlapping circles such as
MMORPG, Internet, Web and online gambling games are generally
operated through wide/public network environment. Mobile gaming is
operated by telecommunication, and local LAN gaming is operated by
local/private network. Before we present our experimental analysis of
server scale-ability and behaviour, in this section we review a typical
multi player game setup. We emphasize the actions taken by the
server and provide a high level description of the structure of the
server and client applications.
 Figure shows a generic setup for interactive, multiplayer game
sessions. In this client server setup, servers usually maintain
consistency of the plot and handle coordination among clients, whereas
clients perform all graphics and user interface operations. More
specifically: A set of players, or clients connect to a centralized game
server, or simply server, they join a game session, and participate until
they leave the session, they are terminated, or the session is ended.
Clients communicate only with the server. The server parses client
actions and notices other clients accordingly. Players can locate
available servers via well known directory servers where servers
publicize their network ad-dress and other game related information. In
this work, we are interested in server behaviour after a game session
has been initiated. Game servers are usually stand{alone PCs or
workstations. Client systems are, today, either home{ level desktop
systems or game consoles.

QOS PROVISIONING FOR REAL-TIME MULTIPLAYER GAMES:

Real-time applications, especially multiplayer games such as first
person shooters, real-time strategy games, or sports games have strict
QoS demands on the underlying network. Moreover, in Networks,
compared to wired networks like the Internet, these applications
encounter additional problems due to the special challenges of
Networks. In this section, we discuss the substantial QoS requirements
of real-time multiplayer games then describe our objective regarding to
QoS provisioning.

Requirements of Real-Time Multiplayer Games:

In case of real-time multiplayer games, end-to-end communication

delay, jitter and packet loss to a certain degree are the most important
QOS attributes of the network, while the available network bandwidth is
of less importance. For most real-time multiplayer games, a maximum
of 150 ms round trip delay is still acceptable. The effects of jitter,
however, are not so well-researched yet. In the authors suggest that
latency and jitters are strongly coupled in the Inter-net with the ratio of
jitter to latency being 0.2 or smaller. This also means that jitter in
general is very small in the Internet if latency is below 150 ms and
therefore has little impact on the game. Furthermore, players’
perception of jitter is game-dependant because high level of jitter
usually leads to packets not arriving in time thus requiring the use of
prediction mechanisms such as dead-reckoning. As the quality of these
prediction mechanisms differ from game to game, players also perceive
jitter differently. Furthermore, prediction mechanisms cannot always
anticipate players’ actions accurately so high level of jitter usually
degrades the players’ experience. Hence, the jitter level must be kept
as low as possible. Moreover, the packet loss rate has similar effects
and it should be kept in the range of 3 – 5 % for real-time multiplayer
games.

To evaluate the performance of the investigated QoS mechanisms, we

used the following metrics:
Latency: the average time in ‘ms’ it takes to transmit a packet from
 the source to the destination.
Jitter: it describes how much the packets vary in latency and is
determined by calculating the standard deviation of the latency.
Loss rate: the loss rate determines the amount of sent packets in
relation to the amount of packets that have not been received
successfully at the destination.
Effects of every QoS extension in detail:
1) Local Repair: Using the local repair mechanism de-grades the
performance of the packet loss rate as well as latency and jitter. In
particular, the average loss rate of high priority connections is increased
by 5 %. First, this is due to the fact that the local repair process takes too
much time for delivering real-time packets. Second, repaired routes tend
to be longer than the original route and in this case the node sends an
additional route error RERR message to the source which will itself restart
the route discovery process again. Therefore, we do not recommend to
use the built-in local repair mechanism of AODV in case of real-time
traffic.
2) RTS/CTS Mechanism: The RTS/CTS mechanism de-grades the
performance of the routing protocol as well. The latency and jitter, and
even the loss rate of the game traffic are significantly higher if RTS/CTS is
enabled. The reason behind this is that multiplayer game data packets are
very small in general and the RTS/CTS mechanism induces a huge
overhead in this case decreasing the performance in all metrics
significantly. As a result, RTS/CTS should not be activated by default and
instead a threshold should be maintained by the system that depends on
the number of neighbors and the size of the data packets that have to be
transmitted. A neighbor list can be discovered easily by collecting MAC
layer beacons from adjacent nodes.
3) Broken Link Detection: Using the Link Layer Feedback (LLF)
mechanism of the MAC layer, broken links can be detected very quickly.
The average latency can be reduced below 20 ms and jitter below 15 ms if
LLF is activated. In addition, the packet loss rate can be reduced further
by some percent as. Moreover, the amount of routing traffic is much
smaller if LLF is used since AODV does not require HELLO messages for
broken link detection any more.
4) Priority Queuing: To evaluate the effect of priority queuing, we
handled the real-time game traffic as high priority traffic and the
background traffic as low priority traffic. High priority packets that are not
delivered within 100 ms (one-way) are regarded as lost and consequently
the average latency and jitter of high priority packets are reduced
significantly in all simulated scenarios, in our case to 20 ms and 14 ms. As
a side effect, the packet loss rate increases as more packets are outdated.
Regardless of the applied QoS mechanisms the loss rate highly depends
on the number of hops. The higher the hop count, the more high priority
packets are discarded since they arrive too late at the destination.
However, when employing priority queuing, the loss rate of high priority
packets can be substantially reduced. On the other hand, latency and
jitter of low priority traffic is increased.
5) Timeouts: When adding timeouts to priority queuing, the loss rate of
high priority traffic is slightly reduced further. Because of the small
timeout value of the high priority queue, high priority packets which are
late are now dropped earlier thus alleviating congestion. Connections with
up to two or three hops have a loss rate of 2 % or 8 %, respectively. The
average loss rate, however is still over 10 %. In addition, jitter and latency
of low priority traffic can be also reduced.
6) Backup Route: The backup route mechanism increases the loss rate of
high priority traffic for 2-hop connections slightly to 3 %. On the other
hand, the loss rate of 3-hop connections is now reduced to 5 %. Using the
backup route mechanism low priority traffic yields the lowest latency in all
scenarios as depicted in Fig. 10.

7)Real-Time Neighbor Aware Rate Control: Applying our rate control

mechanism the loss rate of high priority traffic has been reduced to 2 %
and 4.5 % for 2-hop and 3-hop connections, respectively. Thus, 2- and 3-
hop connections can be employed for real-time multiplayer games.
Connections with 4 hops still suffer from a very high loss rate about 18 %
and therefore cannot be used for real-time applications. Thus, the average
loss rate of high priority traffic is just slightly below 10 %. However,
latency and jitter of low priority traffic are slightly increased since they
remained in the same range in case of high priority traffic.
Online Cheating:

1. Cheating by Collusion:

It is common that players collude to cheat. Take online Bridge game as an

example, one infamous collusion cheating is like this: one cheater uses
two computers, through each of which he logs on to a Bridge server with a
distinct ID, then he partners his two IDs on a same Bridge table, just like
two distinct players partnering each other. The cheater will play by
himself both hands of cards, which are supposed to be held by two
different players and blind to each other! Therefore, he can always make
a precise contract; or when he turns to be a defender, he knows exactly
every card the declarer has after the dummy – the partner of the declarer
– places his cards face-up on the table as required by the rule of Bridge.
Two cheaters, who do not stay in a same place and cannot see each other,
can also cheat by collusion, since they can communicate to exchange
card information via email, online chatting or instant messenger software,
or telephone etc.

2. Cheating by Abusing Procedure or Policy

Some players make use of game procedure or policy to cheat. One
example is scoring cheat, which might happen when two players are
scoring a Go (WeiQi or Baduk) game. Because artificial intelligence
research is not mature enough to identify dead stones and then decide
who wins at the end of each game, online Go players must identify and
remove the dead stones by themselves before their software can count
the result. Some cheaters may stealthily remove live stones in the scoring
process, and “overturn” the result. A common example of abusing policy
is escaping. In some online games, each game one player plays will affect
his rank. When a cheater is going to lose his game, he will disconnect
himself from the system so that his game is unfinished and thus non-
scorable. The type of cheater is commonly called an “escaper”. Different
online games may use different schemes to deal with this cheating. For
example, some online Go games implemented a penalty policy: the player
who disconnects his game will lose that game if he does not finish it in a
limited say 20 days. StarCraft used a different method: for each player,
the system can show the number of games he has dropped so that each
player may check that information and determine whether to play a game
with a specific opponent.
Cheaters may also exploit the above policy of escaping prevention
to cheat in online Go games. This cheating may be called scapegoating (or
hit- then-hide) and works as follows. One cheater uses some attacks 1 to
disconnect his opponent so that the game is recorded as disconnected by
the opponent. Afterwards he does not log on until the opponent
automatically loses that game, because nobody will show up to finish that
game in the limited period.

3. Cheating Related with Virtual Assets:

Trading of virtual characters and items (e.g. clothing, weapons,

homes and magical objects) acquired in games is a new and real business
created by online games. Many players would like to have good
characters, or improve the status of their own characters by getting some
items in the game. Nonetheless, it is not easy for every player to get good
characters and items, which require gaming skills and time. Where there
is demand, there is supply, and then there is a market! Now virtual
characters and items become virtual assets, or real assets in a virtual
world, and many of them have been auctioned for real money on eBay.
Where there is money flow, there is cheating. Trade cheating also has
happened to virtual characters and items, since no security mechanism
was implemented to protect them. For example, players Alice and Bob
would like to exchange virtual items owned by each other. After receiving
the item from Alice, Bob does not give his item to Alice. There is no way
for Alice to get her own item back or claim her right over the item that
Bob has promised to pass to her. It was reported recently that a person
earned around US$11,000 through this type of trade cheating: he kept the
money but never sent any item to the payers. Another case reported that
a person lost his item bought at around US$220 and called the police, and
the investigation showed that the theft was the person who sold the item -
he hacked the game site, and stole the item back after selling it
(Hankyoreh, 2001). Digital signature can provide non-repudiation, which
helps each player to claim his possession of valuable characters and
items. Fair-trading can be implemented to prevent trade cheating.

4. Cheating by Compromising Passwords

Historically, user passwords, as an easy target with high payoff potential,

have been among the first targets on which an attacker would focus
attention when he attacks a system. Passwords used for online games are
not an exception. A password used by a player, as usual, is often the key
to all the data and authorization that this player has in the game system.
An attacker can exploit a compromised password to do various cheatings.
Therefore, good password management and practice is also essential to
prevent online game cheating.
One of the main threats upon passwords comes from offline or
online dictionary attack. Due to the limitation of human memory, people
like choosing easy-to-remember passwords such as phone numbers,
birthdays, or names of friends or family, or words in human languages. A
dictionary attack tries each of a list of word and other possible weak
passwords, and simple transformations such as capitalizing, prefixing,
suffixing or reversing a word, as a candidate until the hashed value of the
candidate matches a password hash. It has been very often successful in
attacking many easy-to-remember passwords. Anybody who gets a
password file can launch an offline dictionary attack against all passwords
in the file, while anybody who knows a player ID can do an online
dictionary attack by simulating his logon procedure.
In the case an online game system is designed to be resilient to
online dictionary attack, e.g., by limiting the number of logging that a
player is allowed to try, a malicious attacker may easily block any user,
whose ID is known, by continuing logging with wrong passwords. Very few
designers are willing to tolerate this consequence, and the convenience of
players is a more important issue to them, consequently, their systems
will be vulnerable to online dictionary attack on passwords. Good
password management and practice are needed to protect players from
online or offline password attacks.
5. Cheating due to Lack of Authentication:

Password authentication only provides assurance that one is a

registered or legitimate game player. In many cases, two-way
authentication between game servers and clients are also needed to
authenticate that both servers and clients are genuine. For online game
systems that do not implement this two-way authentication, it is easy for
a cheater to collect many ID-password pairs of legitimate players by
setting up a bogus game server.
It is also important to re-authenticate a player before any password
changing operation. Otherwise, when a player temporarily leave his
computer with his game session unclosed - that is not unpopular in many
internet cafe where online gamers are active - a cheater who can
physically access to the player’s machine may stealthily change his
password, and exploit the new password later. It is also probable for a
technically capable cheater to replay the game session and force a
password change.

Exploiting Bugs:
Something considered a cheat, but is not a hack, is the exploiting of
“bugs” sometimes called “sploitz”. A definition of bug is; “A computer
bug is an error, flaw, mistake, failure, or fault in a computer program that
prevents it from working correctly or produces an incorrect result. Bugs
arise from mistakes and errors, made by people, in either a program's
source code or its design.”22 It is generally so that every game comes
with bugs, even if well coded games contain fewer bugs than badly
coded. A synonym to bug in this context is glitch, and the bug exploiter is
called glitcher.
Exploiting bugs can be done in many different ways, depending on
the type of the game and the bug itself. For example, a common bug in
some FPS-games allows players to reach areas of map that is not
suppose to be accessible, and from these areas they are invisible to
other players. Hence they can shoot other players undetected. Trying to
list every bug that has been exploited is of course impossible; suffice it
to say that there probably are bugs for every game ever released. Some
are severe, some negligible and some are not even noticed by the
majority of the players. Generally though, bugs are not that big of a
problem compared to hacks, people exploiting bugs are often easy to
spot. The problem arises when the glitches exploits a bug not visible to
other players. The exploiting is then tantamount to hacks, e.g. exploiting
a bug that lets the player see through walls. The existence of a certain
bug in MMORPG’s is so severe that it is worth mentioning individually. In
some MMORPG’s certain techniques allows the players to duplicate
items, the action being called “duping”. Duping is a form of bug
exploitation, but it can also be a combination of hack and exploiting. A
game with good support from the developer and the publisher will have
patches released. A patch is an update to the game that focuses on
fixing bugs and other game play issues, but some also release new
features in their patches.

CONCLUSION:

Thus we analyzed and evaluated common QoS extensions and proposed

new approaches for online gaming. Here we can classify these extensions
into the three categories like routing protocol enhancements, traffic
management mechanisms and MAC layer support mechanisms. Moreover,
applying QoS extensions, the packet loss rate for connections up to three
hops can be reduced below 5 % while the end-to-end communication
delay and delay jitter remain in the range of 20 - 25 ms and 15 - 20 ms,
respectively. This allows to meet the demands of real-time multiplayer
games.