ENSC 427: COMMUNICATION NETWORKS ANALYSIS OF SMART …

ENSC 427: COMMUNICATION NETWORKS

SPRING 2013

ANALYSIS OF SMART

DEVICE GAME

PROTOCOL

http://www.sfu.ca/~mea19/

Mehdi Elahi ([email protected]) 301043763

Seyed Ahmari ([email protected]) 301124836

Bilal Nurhusien ([email protected]) 301050921

Team 14

2 Analysis of Smart Device Game Protocol

Table of Contents List of Figures ................................................................................................................................................ 3

1.0 Abstract ................................................................................................................................................... 4

2.0 Introduction ............................................................................................................................................ 4

3.0 Background ............................................................................................................................................. 4

3.1 Why Mobile Games? ........................................................................................................................... 4

3.2 Game Protocol .................................................................................................................................... 5

3.3 TCP and UDP ....................................................................................................................................... 8

4.0 Implementation ...................................................................................................................................... 8

4.1 Simulation with NS-2 ........................................................................................................................... 8

4.11 Wireless Scenario with Domains ................................................................................................... 8

4.2 Throughput and Delay ...................................................................................................................... 10

5.0 Results and Discussion .......................................................................................................................... 10

5.1 Delay ................................................................................................................................................. 10

5.2 Throughput ....................................................................................................................................... 12

6.0 Conclusion ............................................................................................................................................. 14

7.0 References ............................................................................................................................................ 15

Appendix A: Code for Wireless Scenario with Domains ............................................................................. 16


List of Figures

Figure 1: Mobile app statistics ...................................................................................................................... 5

Figure 2: Typical game server traffic over IP network. ................................................................................. 6

Figure 3: Tank game protocol. ...................................................................................................................... 6

Figure 4: Algorithm flow chart for the server and client. ............................................................................. 7

Figure 5: Tank game screen shot. ................................................................................................................. 7

Figure 6: Wireless scenario with domains using CBR traffic. ........................................................................ 8

Figure 7: UDP Transmit Delay. (Client to Server.) ....................................................................................... 10

Figure 8: TCP Transmit Delay. (Client to Server.) ........................................................................................ 11

Figure 9: UDP Receive Delay. (Server to Client.) ......................................................................................... 11

Figure 10: TCP Receive Delay. (Server to Client.) ........................................................................................ 12

Figure 11: UDP Transmit Throughput. (Client to Server.) ........................................................................... 12

Figure 12: TCP Transmit Throughput. (Client to Server.) ............................................................................ 13

Figure 13: UDP Receive Throughput. (Server to Client.) ............................................................................. 13

Figure 14: TCP Receive Throughput. (Server to Client.) .............................................................................. 14


1.0 Abstract Multiplayer online games have been used throughout the world as a form of entertainment and way of

connecting with others. Many of these video games rely on game servers to authoritatively determine

the source of events and exchange information with clients. Unfortunately, due to the unpredictable

nature of computer networks, games suffer from packet loss, latency, and jitter. Our project consists of

creating a game server in different wireless scenarios and examining the effect this type of traffic has on

the client’s quality of service. We’ll also create networks that use hierarchical routing layouts in order to

see how they affect the user’s experience.

2.0 Introduction In this project, we’ll simulate a tank game that’s running a simple game protocol for smart mobile

devices such as iPhones. The server application was created using a static IP that runs on a Ubuntu

Server LTS 10.04 with bandwidth of 100 MBps upload and download speed. The client is an iPhone 4G

that runs the protocol using 3G and Wi-Fi connections. The protocol is token based and runs on pure

UDP for speed. A token based protocol disregards any client network details such as IP addresses, and

rather creates a token number to identify the client. This allows the client to resume a game even after

disconnections; the server replies to the client only after receiving the client’s token. This specifically

designed protocol supports clients that are hopping through different network domains. For example, a

cell phone that is moving from one cell tower to another.

Even though, the protocol has worked using small test cases. Bigger scale tests are needed to confirm its

reliability. By simulating the implementation in NS-2 we can create more scenarios cheaper and faster.

The goal of this project is to simulate the implementation in NS-2 for variety of scenarios to identify

flaws, constraints, and to find better ways that improve the system.

The scale of simulation must be according to real life situations. The server and client communication

passes through routers, towers, etc. so the simulation must be in an environment that takes all the

network components into account. For example, people using smart devices can move with different

speeds, so we must understand how the speed of the smart phone for example in a moving car will

affect the overall quality of the client’s experience.

3.0 Background In recent years, there has been a growing preponderance of multiplayer online games. However, when

the first multiplayer online games were released, limitations in network infrastructure limited the

multiplayer game experience to small Local Area Networks (LANs). With the internet revolution and

increasingly higher internet speeds available, games have also evolved into high interactive, network

savvy multiplayer games such as MMORPGs and RPGs.

3.1 Why Mobile Games?

When small smart devices were introduced (such as 3rd generation cell phones and tablets), a new

market opened for small games that attract gamers across the world. Most of the smart devices in the

market offer 3G speed with a higher speed achieved through Wi

are made specifically for wireless computer networks, there is a need to study thi

simulations.

It is important to note that there are more than one billion smart phones in the world. The mobile game

market is growing every year, and is one the biggest industries in the world. As shown in the following

figure, 64% of smart phone users have download a game in the past month. As network connections

improve (in terms of speed, bandwidth, etc

savvy multiplayer games.

3.2 Game Protocol

A game server is a server that’s used by game clients to play multiplayer video games. The server

receives and processes each player's input.

connected clients the ability to maintain their own acc

session is depicted in Figure 2.

Analysis of Smart Device Game Protocol

market offer 3G speed with a higher speed achieved through Wi-Fi. Since most mobile game protocols

are made specifically for wireless computer networks, there is a need to study this topology in network

here are more than one billion smart phones in the world. The mobile game


of smart phone users have download a game in the past month. As network connections

(in terms of speed, bandwidth, etc.) users will naturally want more interactive and network

Figure 1: Mobile app statistics

s used by game clients to play multiplayer video games. The server

receives and processes each player's input. It also transmits enough data about its internal state to allow

to maintain their own accurate version of the game world. A simple game


Fi. Since most mobile game protocols

s topology in network

here are more than one billion smart phones in the world. The mobile game


of smart phone users have download a game in the past month. As network connections

interactive and network

s used by game clients to play multiplayer video games. The server

transmits enough data about its internal state to allow

urate version of the game world. A simple game

Figure 2:

Figure 3 depicts the communication between the client and

We see from the figure above, the client initiates communication

assigned an SID (Session ID) and PID (Player

its tank and the server sends game data containing

continue to communicate until the game is over.

The following flow chart illustrates the algorithm used to write the


: Typical game server traffic over IP network.

communication between the client and server for the tank game.

Figure 3: Tank game protocol.

We see from the figure above, the client initiates communication with the game server. The client is

) and PID (Player ID). The client sends the player position and orientation

game data containing another player’s information. Both server and client

until the game is over.

The following flow chart illustrates the algorithm used to write the server and client applications.


with the game server. The client is

player position and orientation of

other player’s information. Both server and client

server and client applications.

Figure 4: Algorithm flow chart for the server and client.

Figure 5 shows a screen shot of the actual tank game.


Algorithm flow chart for the server and client.

Figure 5 shows a screen shot of the actual tank game.

Figure 5: Tank game screen shot.



3.3 TCP and UDP

TCP is a connection oriented protocol that guarantees reliability and ordering of packets. It requires a

three way handshake to set up a connection, and it offers flow and congestion control. Conversely, UDP

is not a connection oriented protocol and doesn’t guarantee reliability or ordering of packets.

Applications using UDP must manually break data up into datagrams and send them individually (not a

stream of information). It also lacks flow and congestion control. We’ll examine the effect of using TCP

and UDP protocols on the user quality of experience in the results section.

4.0 Implementation

4.1 Simulation with NS-2

The simulations were carried out in NS-2 v2.3.5. To plot the throughput and delay graphs, we used

XGRAPH for both UDP and TCP traffic types.

4.11 Wireless Scenario with Domains

To reiterate, we wanted to simulate a game application for mobile devices using NS-2. As depicted in

Figure 6, we created a network scenario consisting of wireless and wired domains. As the mobile client

traversed the map, it received information from the server (via wireless towers). It also sent information

to the server in the opposite direction.

Figure 6: Wireless scenario with domains using CBR traffic.

Wired domain

Wireless Domain


In order to route packets between wireless and wired domains, we used a hierarchical routing layout.

This layout was created using the following code:

As seen in the code above, there are two domains and zero sub-domains; four nodes are located in the

wireless domain and one node in the wired domain. Essentially, the wireless towers act as gateways

between the domains.

Then, we assigned each node in the simulation an address to identify its position in the hierarchy. For

the base station node, we used the following:

From the code above, we see that the address assigned to the server is 0.0.0. In other words, the server

is in domain zero, sub-domain zero, and is the only node in that sub-domain. Using the following code,

we assigned addresses to the wireless nodes.

From the addresses above, we see that each wireless node is assigned to domain one, sub-domain zero,

and their respective node numbers. The client and server both send and receive CBR traffic to one

another. We also used FTP traffic in a different network scenario to see what benefit or disadvantage

#Configure the server node

$ns node-config –addressType hierarchical \

-mobileIP ON

# hierarchical address to identify server node

set temp {0.0.0}; # 0 (0 Domain), 0 (0 Subdomain), 0 (Only node)

set n(0) [ $ns_ node [lindex $temp 0]]

#hierarchical address for wireless nodes

set temp {1.0.0 1.0.1 1.0.2 1.0.3}




.

.

.

#client node address

$ns node-config –wiredRouting OFF


#Create the network layout

AddrParams set domain_num_ 2; #domain numbers

Lappend cluster_num 1 1; #sub-domain for both domains

AddrParams set cluster_num_ $cluster_num

Lappend eilastlevel 1 4; # number of nodes for each sub-domain

AddrParams set nodes_num_ $eilastlevel

TCP offered to the user experience. The results are examined in the discussion section.

note that wireless nodes have no concept of links; therefore, p

using adhoc routing protocols. That is to say, nodes

queries among their neighbours.

4.2 Throughput and Delay

Throughput refers to the amount data

��

The throughput is determined in the record {

procedure is called and calculates the amount

Throughput is then recorded to a file where it can be viewed

Delay was calculated by measuring the elapsed time between arrival of last packet and the current

packet. In other words,

��

5.0 Results and Discussion

5.1 Delay

The UDP and TCP TX (transmit) delay graphs

represent the time that takes for a packet to travel from client to server.

Figure


TCP offered to the user experience. The results are examined in the discussion section.

des have no concept of links; therefore, packets are routed in a wireless topology

adhoc routing protocols. That is to say, nodes build forwarding tables by exchanging routing

Throughput refers to the amount data received by a node per unit time (in our case, bits/sec).

��

� !"

�#!$%

&�'� �()*%

in the record {} procedure of the source code. Periodically, the record{}

the amount of bandwidth received by a node in a given time period

hroughput is then recorded to a file where it can be viewed using XGRAPH later on.


� ��+,--�.� /0�1�� 2 � ��3-��4,� /0�1�� . (2)

Results and Discussion

delay graphs are shown in Figures 7 and 8, respectively.

represent the time that takes for a packet to travel from client to server.

Figure 7: UDP Transmit Delay. (Client to Server.)


TCP offered to the user experience. The results are examined in the discussion section. It is important to

ackets are routed in a wireless topology

build forwarding tables by exchanging routing

bits/sec).

(1)

} procedure of the source code. Periodically, the record{}

a given time period.


. (2)

respectively. TX graphs

From Figure 7, we see that the average delay is around 200(ms). This is consistent through the

simulation, but there are two major points that the delay increases dramatically. In these two points the

client is moving from one tower to another, so the delay will be much higher. We

graph to TCP TX graph in Figure 7. Since TCP communication protocol uses error detection and packet

recovery, the graph shows a higher average delay around (300ms). Please note that in the TCP

simulation, the client switched between

Figure

Figure 9 and Figure 10 are the RX (receive) UDP and TCP graphs respectively. RX means that the packet is

sent from the server to client.

Figure


the average delay is around 200(ms). This is consistent through the


client is moving from one tower to another, so the delay will be much higher. We now compare this

. Since TCP communication protocol uses error detection and packet


switched between towers faster.

Figure 8: TCP Transmit Delay. (Client to Server.)


Figure 9: UDP Receive Delay. (Server to Client.)


the average delay is around 200(ms). This is consistent through the


now compare this

. Since TCP communication protocol uses error detection and packet



Figure

We can see from the previous two figures that using UDP over TCP

5.2 Throughput

Throughput is another network element that we studied. The

shown below the graphs we can see that the TCP bandwidth is consistence over the simulation, but in

TCP we can see a lot of oscillation, which is not very good for ga

choice.

Figure 11


Figure 10: TCP Receive Delay. (Server to Client.)

We can see from the previous two figures that using UDP over TCP will reduce the delay.

is another network element that we studied. The throughput graphs for all the cases are


TCP we can see a lot of oscillation, which is not very good for gaming, so the UDP would be a better

11: UDP Transmit Throughput. (Client to Server.)


reduce the delay.

graphs for all the cases are


ming, so the UDP would be a better

Figure

Figure


Figure 12: TCP Transmit Throughput. (Client to Server.)

Figure 13: UDP Receive Throughput. (Server to Client.)


Figure

6.0 Conclusion After analyzing the simulation results

the mobile node with respect to the cell towers

resulted in greater packet loss than

unless the mobile node moved out of range

greater delay and lag time compared to

nature of TCP; it needs to verify that

appears that UDP is the better choice for

time.


Figure 14: TCP Receive Throughput. (Server to Client.)

After analyzing the simulation results, we noticed that the packet loss was dependent on the position of

de with respect to the cell towers. As a mobile node moved from one tower

greater packet loss than normal. Moreover, packet delay remained relatively consistent

unless the mobile node moved out of range of the towers. When using a TCP connection

reater delay and lag time compared to networks that used UDP. This is due to the con

verify that data has been delivered with accuracy. According to the results, it

UDP is the better choice for real-time applications (especially gaming) due to its lower


dependent on the position of

tower to another, it

remained relatively consistent

connection, there was

This is due to the connection oriented

According to the results, it

gaming) due to its lower lag


7.0 References [[1] Schroeder, Stan. (2011, Jul 07). Mobile Games Dominate Smartphone App Usage [Online]. Available:

http://mashable.com/2011/07/07/smartphone-mobile-games/

[2] A. Leon-Garcia and I. Widjaja, “Communication Networks: Fundamental Concepts and Key

Architectures,” 2nd edition, McGraw -Hill, 2004.

[3] M. Greis. "Marc Greis Tutorial for the UCB/LBNL/VINT Network Simulator "ns"." [Online] Available:

http://www.isi.edu/nsnam/ns/tutorial/, [March 2013].

[4] Game Server searched in Wikipedia [Online]. Available: http://en.wikipedia.org/wiki/Game_server

(Mar. 2013).

[5] SugihJamin. "Networking Multiplayer Games" Internet:

http://web.eecs.umich.edu/~sugih/courses/eecs494/fall06/lectures/lecture8-mmog.pdf, Sept.10, 2006

[Mar, 2013].

[6] John Laird. "Networking in Games" Internet:

http://ai.eecs.umich.edu/soar/Classes/494/talks/lecture-16.pdf, Sept. 2012 [Mar, 2013].

[7] Prasana. (2011, April. 5). Sample Coding in Wireless [Online]. Available: http://ns2-

master.blogspot.ca/2011/04/sample-coding-in-wireless.html


Appendix A: Code for Wireless Scenario with Domains

#ENSC 427 (Team 14, SPRING 2013)

# Wireless Scenario with Domains (using CBR traffic)

# file name: wireless_domain.tcl

#====================================================================================

====================

#======================================================================================================== #Initialization # Define options set val(adhocRouting) DSDV set val(chan) Channel/WirelessChannel ;# channel type set val(prop) Propagation/TwoRayGround ;# radio-propagation model set val(netif) Phy/WirelessPhy ;# network interface type set val(mac) Mac/802_11 ;# MAC type set val(ifq) Queue/DropTail/PriQueue ;# interface queue type set val(ll) LL ;# link layer type set val(ant) Antenna/OmniAntenna ;# antenna model set val(ifqlen) 50 ;# max packet in ifq set val(nn) 5 ;# number of mobilenodes set val(x) 1000 ;# X dimension of topography set val(y) 1000 ;# Y dimension of topography set val(stop) 150 ;# time of simulation end set ns [new Simulator] set tracefd [open wireless_domain.tr w] set namtrace [open wireless_domain.nam w] #======================================================================================================== #======================================================================================================== #Open the output files and create trace set f0 [open bw_tx.tr w] set f1 [open bw_rx.tr w] set f2 [open delay_tx.tr w] set f3 [open delay_rx.tr w] $ns trace-all $tracefd $ns namtrace-all-wireless $namtrace $val(x) $val(y) #======================================================================================================== #======================================================================================================== # set up topography object set topo [new Topography] $topo load_flatgrid $val(x) $val(y) create-god $val(nn)


#======================================================================================================== #======================================================================================================== #Create the network layout AddrParams set domain_num_ 2;#domain numbers lappend cluster_num 1 1;#sub-domain for each domain AddrParams set cluster_num_ $cluster_num lappend eilastlevel 1 4;#node number for each sub-domain AddrParams set nodes_num_ $eilastlevel #======================================================================================================== #======================================================================================================== #Configure the server node $ns node-config -addressType hierarchical \ -mobileIP ON set temp {0.0.0} set n(0) [$ns node [lindex $temp 0]] #Configure tower nodes $ns node-config -adhocRouting $val(adhocRouting) \ -llType $val(ll) \ -macType $val(mac) \ -ifqType $val(ifq) \ -ifqLen $val(ifqlen) \ -antType $val(ant) \ -propType $val(prop) \ -phyType $val(netif) \ -channelType $val(chan) \ -topoInstance $topo \ -wiredRouting ON \ -agentTrace ON \ -routerTrace ON \ -macTrace ON \ -movementTrace ON \ -mobileIP ON set temp {1.0.1 1.0.2 1.0.3 1.0.4};#towers network id


set n(1) [$ns node [lindex $temp 0]] set n(2) [$ns node [lindex $temp 1]] set n(4) [$ns node [lindex $temp 2]] $n(1) random-motion 0 $n(2) random-motion 0 $n(4) random-motion 0 #Configure mobile node $ns node-config -wiredRouting OFF set n(3) [$ns node [lindex $temp 3]] #$n(3) base-station [AddrParams addr2id [$n(0) node-addr]] [$n(3) set regagent_] set home_agent_ [AddrParams addr2id [$n(1) node-addr]] #hop tower to tower #======================================================================================================== #======================================================================================================== #Create Wired links $ns duplex-link $n(4) $n(0) 1Mb 150ms DropTail $ns duplex-link $n(1) $n(0) 1Mb 150ms DropTail $ns duplex-link $n(2) $n(0) 1Mb 150ms DropTail #Change graphic $ns color 1 blue $ns color 2 red $ns duplex-link-op $n(0) $n(4) orient down $ns duplex-link-op $n(0) $n(1) orient left-down $ns duplex-link-op $n(0) $n(2) orient right-down $n(0) shape box $n(0) color red $n(0) label Server $n(1) label Tower $n(2) label Tower $n(4) label Tower $n(3) label Client #======================================================================================================== #======================================================================================================== #Initial locations $n(0) set X_ 325.0 $n(0) set Y_ 585.0 $n(0) set Z_ 0.0 $n(1) set X_ 208.327 $n(1) set Y_ 468.327 $n(1) set Z_ 0.0


$n(2) set X_ 441.673 $n(2) set Y_ 468.327 $n(2) set Z_ 0.0 $n(4) set X_ 325.0 $n(4) set Y_ 420.0 $n(4) set Z_ 0.0 $n(3) set X_ 0.0 $n(3) set Y_ 380.0 $n(3) set Z_ 0.0 #======================================================================================================== #======================================================================================================== #Needed Procs #Record Function set xbw0 0 set xtime 0.000 set xbw2 0 set xtime2 0.000 proc record {} { global sink sink2 f0 f1 f2 f3 xbw0 xbw2 xtime xtime2 #f1 f2 #Get an instance of the simulator set ns [Simulator instance] #Set the time after which the procedure should be called again set time 0.08 #How many bytes have been received by the traffic sinks? set bw0 [$sink(3) set bytes_] set bw2 [$sink2(3) set bytes_] #Get the current time set now [$ns now] #Calculate the bandwidth (in MBit/s) and write it to the files puts $f0 "$now [expr $bw0/$time*8/1000000]";#tx puts $f1 "$now [expr $bw2/$time*8/1000000]";#rx #Calculate Delay for tx set xtime [expr $xtime+$time]; if { $bw0 > [expr 0] } { puts $f2 "$now $xtime" set xtime 0.0 } set xbw0 $bw0 #Calculate Delay for rx [expr $xbw2 * 2] set xtime2 [expr $xtime2+$time] if { $bw2 > [expr 0] } {


puts $f3 "$now $xtime2" set xtime2 0.0 } set xbw2 $bw2 #Reset the bytes_ values on the traffic sinks $sink(3) set bytes_ 0 $sink2(3) set bytes_ 0 #Re-schedule the procedure $ns at [expr $now+$time] "record" } #Create Traffic Function proc create_traffic_tx { node_num } { global ns n sink set udp($node_num) [new Agent/UDP] #set sink($node_num) [new Agent/LossMonitor] $ns attach-agent $n($node_num) $udp($node_num) $ns attach-agent $n(0) $sink($node_num) $ns connect $udp($node_num) $sink($node_num) #set ftp1 [new Application/FTP] set cbr($node_num) [new Application/Traffic/CBR] $cbr($node_num) set packetSize_ 1500 $cbr($node_num) set interval_ 0.2 $cbr($node_num) attach-agent $udp($node_num) $udp($node_num) set class_ 1 $cbr($node_num) set class_ 1 return $cbr($node_num) #$ns at 1.0 "$cbr start" } proc create_traffic_rx { node_num } { global ns n sink2 # Set a TCP connection between n(1) and n(3) set udp2($node_num) [new Agent/UDP] #set sink2($node_num) [new Agent/LossMonitor] $ns attach-agent $n(0) $udp2($node_num) $ns attach-agent $n($node_num) $sink2($node_num) $ns connect $udp2($node_num) $sink2($node_num) set cbr2($node_num) [new Application/Traffic/CBR] $cbr2($node_num) set packetSize_ 1500 $cbr2($node_num) set interval_ 0.2 $cbr2($node_num) attach-agent $udp2($node_num) $udp2($node_num) set class_ 2 $cbr2($node_num) set class_ 2 return $cbr2($node_num) #$ns at 1.0 "$cbr2 start"


} #======================================================================================================== #======================================================================================================== #Setup traffic sources set sink(3) [new Agent/LossMonitor] set sink2(3) [new Agent/LossMonitor] set source0 [create_traffic_tx 3] set source1 [create_traffic_rx 3] #======================================================================================================== #======================================================================================================== #Simulation data $ns at 0.02 "$source0 start" $ns at 0.02 "$source1 start" $ns at 0.01 "record" $ns at 0.02 "$n(3) setdest 600.0 380.0 5.0" #======================================================================================================== #======================================================================================================== #Finalization #Initial node size for {set i 0} {$i < $val(nn)} { incr i } { $ns initial_node_pos $n($i) 10 } #Telling nodes when the simulation ends for {set i 0} {$i < $val(nn) } { incr i } { $ns at $val(stop) "$n($i) reset"; } # ending nam and the simulation $ns at $val(stop) "$ns nam-end-wireless $val(stop)" $ns at $val(stop) "stop" $ns at 150.01 "puts \"end simulation\" ; $ns halt" proc stop {} { global ns tracefd namtrace global f0 f1 f2 f3 #f2 #Close the output files close $f0 close $f1 close $f2 close $f3 #close $f2 $ns flush-trace close $tracefd close $namtrace exec nam wireless_domain.nam & }$ns run

ENSC 427: COMMUNICATION NETWORKS ANALYSIS OF SMART …

Documents

Transcript of ENSC 427: COMMUNICATION NETWORKS ANALYSIS OF SMART …