ANALYSIS OF SMART DEVICE GAME PROTOCOL

Transcription

1 ENSC 427: COMMUNICATION NETWORKS SPRING 2013 ANALYSIS OF SMART DEVICE GAME PROTOCOL Mehdi Elahi Seyed Ahmari Bilal Nurhusien Team 14

2 2 Table of Contents List of Figures Abstract Introduction Background Why Mobile Games? Game Protocol TCP and UDP Implementation Simulation with NS Wireless Scenario with Domains Throughput and Delay Results and Discussion Delay Throughput Conclusion References Appendix A: Code for Wireless Scenario with Domains... 16

3 3 List of Figures Figure 1: Mobile app statistics... 5 Figure 2: Typical game server traffic over IP network Figure 3: Tank game protocol Figure 4: Algorithm flow chart for the server and client Figure 5: Tank game screen shot Figure 6: Wireless scenario with domains using CBR traffic Figure 7: UDP Transmit Delay. (Client to Server.) Figure 8: TCP Transmit Delay. (Client to Server.) Figure 9: UDP Receive Delay. (Server to Client.) Figure 10: TCP Receive Delay. (Server to Client.) Figure 11: UDP Transmit Throughput. (Client to Server.) Figure 12: TCP Transmit Throughput. (Client to Server.) Figure 13: UDP Receive Throughput. (Server to Client.) Figure 14: TCP Receive Throughput. (Server to Client.)... 14

4 4 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 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

5 Analysis of Smart Device Game Protocol market offer 3G speed with a higher speed achieved through Wi Wi-Fi. Fi. Since most mobile game protocols are made specifically for wireless computer networks, there is a need to study thi thiss topology in network simulations. It is important to note that there here 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 etc.) users will naturally want more interactive and network savvy multiplayer games. Figure 1: Mobile app statistics 3.2 Game Protocol A game server is a server that ss 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 connected clients the ability to maintain their own acc accurate urate version of the game world. A simple game session is depicted in Figure 2. 5

6 Analysis of Smart Device Game Protocol Figure 2:: Typical game server traffic over IP network. Figure 3 depicts the 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 assigned an SID (Session ID)) and PID (Player ID). The client sends the player position and orientation of its tank and the server sends game data containing another other player s information. Both server and client continue to communicate until the game is over. The following flow chart illustrates the algorithm used to write the server and client applications. 6

7 Analysis of Smart Device Game Protocol Figure 4: 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. 7

8 8 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 v To plot the throughput and delay graphs, we used XGRAPH for both UDP and TCP traffic types 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. Wired domain Wireless Domain Figure 6: Wireless scenario with domains using CBR traffic.

9 9 In order to route packets between wireless and wired domains, we used a hierarchical routing layout. This layout was created using the following code: #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 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: #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]] From the code above, we see that the address assigned to the server is 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. #hierarchical address for wireless nodes set temp { } set n(1) [ $ns_ node [lindex $temp 0]] set n(2) [ $ns_ node [lindex $temp 1]] set n(4) [ $ns_ node [lindex $temp 2]]... #client node address $ns node-config wiredrouting OFF set n(3) [ $ns_ node [lindex $temp 3]] 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

10 Analysis of Smart Devicee Game Protocol 10 TCP offered to the user experience. The results are examined in the discussion section. It is important to note that wireless nodes have no concept of links; therefore, packets are routed in a wireless topology using adhoc routing protocols. That is to say, nodes build forwarding tables by exchanging routing queries among their neighbours. 4.2 Throughput and Delay Throughput refers to the amount data received by a node per unit time (in our case, bits/sec). (1) The throughput is determined in the record {} procedure of the source code. Periodically, the record{} procedure is called and calculates the amount of bandwidth received by a node in a given time period. Throughput is then recorded to a file where it can be viewed using XGRAPH later on. Delay was calculated by measuring packet. In other words, the elapsed time between arrival of last packet and the current. (2) 5.0 Results and Discussion 5.1 Delay The UDP and TCP TX (transmit) delay graphs are shown in Figures 7 and 8, respectively. TX graphs represent the time that takes for a packet to travel from client to server. Figure 7: UDP Transmit Delay. (Client to Server.)

11 Analysis of Smart Devicee Game Protocol 11 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 now compare this 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 towers faster. Figure 8: TCP Transmit Delay. (Client to Server.) 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 9: UDP Receive Delay. (Server to Client.)

12 Analysis of Smart Devicee Game Protocol 12 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. 5.2 Throughput Throughput is another network element that we studied. The throughput graphs for all the cases are shown below the graphs we can seee 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 gaming, so the UDP would be a better choice. Figure 11: UDP Transmit Throughput. (Client to Server.)

13 Analysis of Smart Devicee Game Protocol 13 Figure 12: TCP Transmit Throughput. (Client to Server.) Figure 13: UDP Receive Throughput. (Server to Client.)

14 Analysis of Smart Devicee Game Protocol 14 Figure 14: TCP Receive Throughput. (Server to Client.) 6.0 Conclusion After analyzing the simulation results, we noticed that the packet loss was dependent on the position of the mobile node with respect to the cell towers. As a mobile node moved from one tower to another, it resulted in 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, there was greater delay and lag time compared to networks that used UDP. This is due to the connection oriented nature of TCP; it needs to verify that data has been delivered with accuracy. According to the results, it appears that UDP is the better choice for real-time applications (especially gaming) due to its lower lag time.

15 References [[1] Schroeder, Stan. (2011, Jul 07). Mobile Games Dominate Smartphone App Usage [Online]. Available: [2] A. Leon-Garcia and I. Widjaja, Communication Networks: Fundamental Concepts and Key Architectures, 2nd edition, McGraw -Hill, [3] M. Greis. "Marc Greis Tutorial for the UCB/LBNL/VINT Network Simulator "ns"." [Online] Available: [March 2013]. [4] Game Server searched in Wikipedia [Online]. Available: (Mar. 2013). [5] SugihJamin. "Networking Multiplayer Games" Internet: Sept.10, 2006 [Mar, 2013]. [6] John Laird. "Networking in Games" Internet: Sept [Mar, 2013]. [7] Prasana. (2011, April. 5). Sample Coding in Wireless [Online]. Available: master.blogspot.ca/2011/04/sample-coding-in-wireless.html

16 16 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)

17 17 #============== #============== #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 { };#towers network id

18 18 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_ $n(0) set Y_ $n(0) set Z_ 0.0 $n(1) set X_ $n(1) set Y_ $n(1) set Z_ 0.0

19 19 $n(2) set X_ $n(2) set Y_ $n(2) set Z_ 0.0 $n(4) set X_ $n(4) set Y_ $n(4) set Z_ 0.0 $n(3) set X_ 0.0 $n(3) set Y_ $n(3) set Z_ 0.0 #============== #============== #Needed Procs #Record Function set xbw0 0 set xtime set xbw2 0 set xtime 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/ ]";#tx puts $f1 "$now [expr $bw2/$time*8/ ]";#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] } {

20 20 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"

21 21 } #============== #============== #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 " #============== #============== #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 "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