Aspects of Networking in Introduction Multiplayer Computer Games - PDF document

Aspects of Networking in Introduction Multiplayer Computer Games • Internet + wireless making multiplayer computer games (MCGs) more popular • Commercial computer games increasingly J. Smed, T. Kaukoranta and H. Hakonen having mutiplayer option. With servers: – Electronic Arts – Ultima Online The Electronic Library – Blizzard – Battle.net Volume 20, Number 2, Pages 87-97 – Microsoft’s – MSN Gaming Zone • Consoles, too ( PS2 , Xbox ) 2002 • Wireless devices, too ( Nokia NGage ) Other VR Research Efforts Shared Space Technologies • Distributed Interactive Simulations (DIS) – Protocol (IEEE), architectures … (MCG’s) – 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 Network Resources Outline • Distributed simulations face three • Introduction resource limitations (done) • Networking Resources – Network bandwidth (next) • Distribution Concepts – Network latency • Scalability – Host processing power (to handle network) • Physical restrictions that the system • Security and Cheating cannot overcome • Conclusions – Must be considered in the design of the application • (More on each, next) 1

Transmission Techniques Bandwidth (Bitrate) • Data sent/received per time • LAN – 10 Mbps to 10 Gbps – Limited size and scope • WANs – tens of kbps from modems, to 1.5 Mbps (T1, broadband), to 55 Mbps (T3) • (a) Unicast, one send and one get – Potentially enormous, Global in scope • Number of users, size and frequency of – Wastes bandwidth when path shared • (c) Broadcast, one send and all get messages determines bitrate use • As does transmission technique (next slide) – Perhaps ok for LAN – Wastes bandwidth when most don’t need • (b) Multicast, one send and only subscribed get – Current Internet does not support – Multicast overlay networks Network Latency Computational Power • Delay when message sent until received – Variation (jitter) also matters • Processing to send/receive packets • Cannot be totally eliminated • Most devices powerful enough for raw – Speed of light propagation yields 25-30 ms across Atlantic sending – With routing and queuing, usually 80 ms • Application tolerances: – Can saturate LAN • Rather, application must process state in – File download – minutes each packet – Web page download – up to 10 seconds • Especially critical on resource-constrained – Interactive audio – 100s of ms • MCG latencies tolerance depends upon game devices – First-Person Shooters – 100s of ms – I.e.- hand-held console, cell phone, PDA, – Real-Time Strategy – up to 1 second [SGB+03] – Other games Outline Distribution Concepts • Cannot do much about above resource • Introduction (done) • Networking Resources limitations (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 2

Communication Architectures Data and Control Architectures Split-screen All peers equal • Want consistency Console -Easy to - Limited extend players -Doesn’t scale – Same state on each node (LAN only) – Needs tightly coupled, low latency, small nodes • Want responsiveness – More computation locally to reduce network – Loosely coupled Server pool • In general, cannot do both. Tradeoffs. -Improved scalability -More complex One node server - Clients only to server -Server may be bottleneck 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 (Example: Smart terminal, (consistency) send and echo) 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 • Distributed and Replicated – Message aggregation – Interest management – Allow short-circuit relay – Dead reckoning – Replicated has copies, used when predictable (ie- non-player characters) (next) – Distributed has local node only, used when unpredictable (ie- players) 3

Message Aggregation Interest Management – Auras (1) • 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. - But implementation – Multiple users command to clients (player complex A’s and player B’s actions to player C) Interest Management- Focus and Interest Management- Auras (2) Nimbus - Divide into cells (or hexes). - Compute bounding box - Easier, but less discriminating - Relatively easy, precise • Always symmetric – both receive - nimbus must intersect with focus to 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 • Predict position based on last known position plus direction • Introduction (done) – Can also only send updates when deviates past a • Networking Resources threshold (done) (predicted position) • Distribution Concepts (done) • Scalability (next) (“warp”) • Security and Cheating • Conclusions (actual position) • When prediction differs, get “warping” or “rubber-banding” effect 4

Serial and Parallel Execution Scalability • Given time T(1), speedup with n • Ability to adapt to resource changes nodes • Example: • Part of T(1) is serializable, part is parallel • T s + T p = T(1) and α = T s /(T s + T p ) – Expand to varying number of players • If serialized optimally: – Allocate non-player computation among (Amdahls’ law) nodes • Need hardware parallelism that enables 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 Outline Security and Cheating • Introduction • Unique to games (done) • Networking Resources (done) – Other multi-person applications don’t have • Distribution Concepts – In DIS, military not public and considered (done) • Scalability trustworthy (done) • Cheaters want: • Security and Cheating (next) • Conclusions – Vandalism – create havoc (relatively few) – Dominance – gain advantage (more) 5

Packet and Traffic Tampering Preventing Packet Tampering • Reflex augmentation - enhance cheater’s • Cheaters figure out by changing bytes and reactions – Example: aiming proxy monitors opponents observing effects movement packets, when cheater fires, – Prevent by MD5 checksums (fast, public) improve aim • Still cheaters can: • Packet interception – prevent some packets – Reverse engineer checksums from reaching cheater – Attack with packet replay – Example: suppress damage packets, so • So: cheater is invulnerable • Packet replay – repeat event over for – Encrypt packets – Add sequence numbers (or encoded sequence added advantage numbers) to prevent replay – Example: multiple bullets or rockets if otherwise limited Information Exposure Design Defects • Allows cheater to gain access to replicated, hidden • If clients trust each other, then if client is game data (i.e. status of other players) replaced and exaggerates cheater effects, – Passive, since does not alter traffic others will go along – Example: defeat “fog of war” in RTS, see through – Can have checksums on client binaries walls in FPS • Cannot be defeated by network alone – Better to have trusted server that puts • Instead: into play client actions (centralized server) • Distribution may be the source of – Sensitive data should be encoded unexpected behavior – Kept in hard-to-detect memory location – Features only evident upon high load (say, – Centralized server may detect cheating (example: latency compensation technique) attack enemy could not have seen) • Harder in replicated system, but can still share – Example: Madden Football Conclusion Future Work • Overview of problems with MCGs • Other distributed systems solutions • Connection to other distributed systems • Cryptography • Practitioners should be encouraged to – Networking resources participate – Distribution architectures – Scalability – Security 6