4/15/2014 Introduction Aspects of Networking in • Network growth, especially wireless, Multiplayer Computer Games making multiplayer computer games (MCGs) more popular • Commercial computer games increasingly J. Smed, T. Kaukoranta and H. Hakonen having mutiplayer option • And not just PCs, but consoles, too ( PS4 , Xbox One, Wii… ) The Electronic Library Volume 20, Number 2, Pages 87-97 • Wireless-only devices, too (3d DS, PS Vita, 2002 Smart phones ) Shared Space Technologies Other VR Research Efforts (MCG’s) • Distributed Interactive Simulations (DIS) – Protocol (IEEE), architectures … – Ex: flight simulation – Large scale, spread out, many users • Distributed Virtual Environments (DVEs) – Immersive, technology oriented – Ex: “Caves” – Local, few users • Computer Supported Cooperative Work (CSCW) – Focus on collaboration – Ex: 3D editors • And MCGs are similar, yet not discussed in scientific literature � Hence, this paper seeks to rectify 1
4/15/2014 Outline Network Resources • Introduction (done) • Distributed simulations face three resource limitations • Networking Resources (next) – Network bandwidth • Distribution Concepts – Network latency • Scalability – Host processing power (to handle network aspects) • Security and Cheating • Physical restrictions that system cannot overcome • Conclusions – Must be considered in design of application (More on each, next) Network Bandwidth Network Bandwidth (Capacities) (Transmission Techniques) • Data sent/received per time • LAN – 10 Mbps to 10 Gbps – Limited size (hosts) and scope (distance) • WANs – 10s of kbps from modems, to 1-10 Mbps (broadband), to 55 Mbps (T3) and more – Potentially enormous (billions of hosts), Global (a) Unicast: one send and one receive • in scope (across continents and world) – Can waste bandwidth when path shared by several clients (c) Broadcast: one send and all receive • • Number of users, size and frequency of – Perhaps ok for LAN messages determines bitrate use – Can waste bandwidth when most nodes don’t need (b) Multicast: one send and only subscribed receive • As does transmission technique (next slide) • – Current Internet does not support – Multicast overlay networks (e.g., MBone or application layer mcast) 2
4/15/2014 Network Latency Computational Power • Processing to send/receive packets Delay when message sent until received • – Variation in delay (delay jitter) also matters • Most devices powerful enough for raw Cannot be totally eliminated • sending/receiving – e.g., speed of light propagation yields 25-30 ms across Atlantic – And with routing and queuing, usually 80+ ms – Can saturate LAN Application tolerances: • • Rather, application must process state in each – File download – minutes packet (e.g., receive packet, update game – Web page download – up to 10 seconds – Interactive audio – 100s of ms world) MCG latencies tolerance? � Depends upon game! • • Especially critical on resource-constrained – First-Person Shooters – about 100 ms – Third-Person Adventure – up to 500 ms devices – Real-Time Strategy – up to 1 second – e.g., hand-held console, cell phone, PDA, – And depends upon action within game! (topic for another paper) Outline Distribution Concepts • Cannot do much about above resource • Introduction (done) limitations • Networking Resources (done) • Should tackle problems at higher level • Distribution Concepts (next) • Choose architectures for • Scalability – Communication • Security and Cheating – Data • Conclusions – Control • Plus, compensatory techniques to relax requirements 3
4/15/2014 Communication Architectures Data and Control Architectures Split-screen All peers equal - Limited players -Easy to extend -Doesn’t scale (LAN • Want consistency only) – Same state on each node – Needs tightly coupled, low latency, small nodes • Want responsiveness – More computation locally to reduce network – Loosely coupled (asynchronous) Central server Server pool - Clients only to -Improved • In general, cannot do both � Tradeoffs server scalability -Server may be -More bottleneck complex Relay Architecture Choices “Relay” Architecture Abstraction (Example: Dumb terminal, send and wait for response) • Want control to propagate quickly so can update data ( responsiveness ) • Want to reflect same data on all nodes ( consistency ) (Example: Smart terminal, send and echo) 4
4/15/2014 MCG Architectures Compensatory Techniques • Centralized • Architectures alone not enough – Use only two-way relay (no short-circuit) • Design to compensate for residual – One node holds data so view is consistent at all times • Techniques: – Lacks responsiveness – Message aggregation • Distributed and Replicated – Allow short-circuit relay – Interest management – Replicated has copies, used when predictable (e.g., – Dead reckoning behavior of non-player characters) (next) – Distributed has local node only, used when unpredictable (e.g., behavior of players) Message Aggregation Interest Management – Auras (1 of 2) • Combine multiple messages in one packet to • Nodes express area of interest to them reduce network overhead – Do not get messages for outside areas • Examples: – Multiple user commands to server (move and - Only circle sent even if shoot) world is larger – Multiple users command to clients (player A’s and - But implementation player B’s actions combined to player C) complex (squares easier) 5
4/15/2014 Interest Management- Focus and Interest Management- Auras (2 of 2) Nimbus - Divide into cells (or hexes) - Compute bounding box - Easier, but less discriminating - Relatively easy, precise - Nimbus must intersect with focus to receive Always symmetric – both receive • - Example above: hider has smaller nimbus, so seeker – But can sub-divide – focus and nimbus cannot see, while hider can see seeker since seeker’s nimbus intersects hider’s focus Dead Reckoning Outline • Based on ocean navigation techniques (“dead” == “deduced (ded.)”) • Predict position based on last known position plus direction • Introduction (done) – Only send updates when deviates past threshold • Networking Resources (done) (predicted position) • Distribution Concepts (done) • Scalability (next) (“warp”) • Security and Cheating • Conclusions (actual position) • When prediction differs and adjust, get “warping” or “rubber-banding” effect – Some techniques move to place over short time 6
4/15/2014 Serial and Parallel Execution Scalability Given time T(1), speedup with n nodes • • Ability to adapt to resource changes • Part of T(1) must happen serially and part can be done in parallel • Example: T s + T p = T(1) and α = T s /(T s + T p ) – Expand to varying number of players • If serialized optimally: (Amdahls’ law) – Allocate non-player computation among nodes • Need hardware parallelism that supports software concurrency • If T s = 0, everything parallelizable but then no communication (ex: players at own console with no interaction) • If T p = 0, then turn based • Between are MCGs which have some of both Serial and Parallel MCGs Communication Capacity • Scalability limited by communication requirements of chosen architecture Separate games (Multicasting) Turn-based games • Can consider pool of m servers with n clients divided evenly amongst them Interactive • Servers in hierarchy have root as bottleneck games • In order not to increase with n , must have clients not aware of other clients (interest management) and do message aggregation 7
4/15/2014 Outline Security and Cheating • Introduction (done) • Unique to games – Other multi-person applications don’t have • Networking Resources (done) – In DIS, military not public and considered • Distribution Concepts (done) trustworthy • Scalability (done) • Cheaters want: • Security and Cheating (next) – Vandalism – create havoc (relatively few) • Conclusions – Dominance – gain advantage (more) Preventing Packet Tampering Packet and Traffic Tampering • Cheaters figure out by changing bytes and • Reflex augmentation - enhance cheater’s observing effects reactions – Prevent by MD5 checksums (fast, public) – e.g., aiming proxy monitors opponents movement packets, when cheater fires, improve aim • Still cheaters can: • Packet interception – prevent some packets from – Reverse engineer checksums reaching cheater – Attack with packet replay – e.g., suppress damage packets, so cheater is • So: invulnerable – Encrypt packets • Packet replay – repeat event over for added advantage – Add sequence numbers (or encoded sequence numbers) to prevent replay – e.g., multiple bullets or rockets if otherwise limited 8
Recommend
More recommend
