distributed computing systems
play

Distributed Computing Systems Compensation techniques Cheating - PDF document

2/26/2016 Outline Network Games Architectures Distributed Computing Systems Compensation techniques Cheating Cloud games (Slides for Final Class) Peer-to-Peer Systems Overview P2P file sharing Communication


  1. 2/26/2016 Outline • Network Games – Architectures Distributed Computing Systems – Compensation techniques – Cheating – Cloud games (Slides for Final Class) • Peer-to-Peer Systems – Overview – P2P file sharing Communication Architectures Data and Control Architectures Split-screen All peers equal - Limited players -Easy to extend • Want consistency - Doesn’t scale (LAN 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) 1

  2. 2/26/2016 Network Game Architectures Outline • Centralized • Network Games – Use only two-way relay (no short-circuit) – Architectures (done) – One node holds data so view is consistent at all times – Compensation techniques (next) – Lacks responsiveness • Distributed and Replicated – Cheating – Allow short-circuit relay, provides responsiveness – Cloud games – What about consistency?  Make design decisions • Peer-to-Peer Systems • Replicated has copies, used when predictable (e.g., behavior of non-player characters) – Overview • Distributed has local node only, used when unpredictable (e.g., behavior of players) – P2P file sharing Dead Reckoning Interest Management – Auras • Based on ocean navigation techniques (“dead” == “deduced ( ded .)”) • Predict position based on last known position plus direction – Only send updates when deviates past threshold • Nodes express area of interest to them – Do not get messages for outside areas (predicted position) (“warp”) - Only world information in circle/sent sent even if world is larger (actual position) - Side benefit  can • When prediction differs and adjust, get “ warping ” or prevent cheating (later) “ rubber-banding ” effect – Some techniques move smoothly to place over short time Time Delay Time Warp • Server delays processing of events • With network latency, must lead opponent to hit (even with “instant” weapon!) – Wait until all messages from clients arrive • Instead, knowing latency roll-back (warp) to when action took – (Note, game plays at highest round-trip time) place • Server sends messages to more distant client first, – Usually, estimate latency as ½ round-trip time delays messages to closer – Needs accurate estimate of round-trip time • Client 100 ms behind Server processes Client 1 Client 2 • Still hits (note command arrives both client commands command arrives blood) • (Boxes are bounding boxes ) Time Time Delay https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking 2

  3. 2/26/2016 Time Warp Notes Outline • Inconsistency • Network Games – Player target – Architectures (done) – Move around corner – Warp back  hit – Compensation techniques (done) – Bullets seem to “bend” around corner ! – Cheating (next)  “Magic” bullets – Cloud games • Fortunately, player often does not notice • Peer-to-Peer Systems – Doesn’t see opponent – Overview – May be just wounded – P2P file sharing Cheating Packet and Traffic Tampering • Packet interception – prevent some packets from • Unique to games reaching cheater – Other multi- person applications don’t have – e.g., suppress damage packets, so cheater is – e.g, Distributed Interactive Simulation (DIS), not invulnerable public, “employees” so considered trustworthy • Packet replay – repeat event over for added • Cheaters want: advantage – e.g., multiple bullets or rockets if otherwise limited – Vandalism – create havoc (relatively few). • Solutions: • Mostly, game design to prevent (e.g., no friendly fire) – MD5 Checksum or Encrypt packets – Dominance – gain advantage (more) – Authoritative host keeps within bounds • Next slides Information Exposure Packet Tampering • Allows cheater to gain access to • Reflex augmentation - enhance replicated, hidden game data (e.g. status of other players) cheater’s reactions – Passive, since does not alter traffic – e.g., aiming proxy monitors – e.g., ignore “fog of war” in RTS, or “wall opponents movement packets, hack” to see through walls in FPS when cheater fires, improve aim • Cannot be defeated by network alone • Tough to detect • Instead: – Sensitive data should be encoded – e.g., PunkBuster – scan for – Kept in hard-to-detect memory location “known” hacks – Centralized server may detect cheating – False positives? (e.g., attack enemy could not have seen) S. Yeung and J. Lui . “Dynamic Bayesian approach for detecting cheats in multi- player online games”, Springer Multimedia Systems, Vol. 14, No. 4 Sep. 2008. aimbot human 3

  4. 2/26/2016 Cloud-based Games Outline • Connectivity and capacity of networks growing • Network Games • Opportunity for cloud-based games – Architectures (done) – Game processing on servers in cloud – Compensation techniques – Stream game video down to client (done) – Client displays video, sends player input up to server – Cheating (done) – Cloud games (next) Game frames • Peer-to-Peer Systems Server – Overview Server – P2P file sharing Server Player input Thin Client Cloud Servers 20 Why Cloud-based Games? Cloud Game - Modules (1 of 2) • Input ( i ) – receives • Potential elastic scalability – Overcome processing and storage limitations of clients control messages from – Avoid potential upfront costs for servers, while supporting demand players • Ease of deployment – Client “thin”, so inexpensive ( $100 for OnLive console vs. $400 for • Game logic – manages Playstation 4 console) game content – Potentially less frequent client hardware upgrades – Games for different platforms (e.g., Xbox and Playstation) on one • Networking ( n ) – device exchanges data with • Piracy prevention – Since game code is stored in cloud, server controls content and server content cannot be copied • Rendering ( r ) – renders – Unlike other solutions (e.g., DRM), still easy to distribute to players • Click-to-play game frames – Game can be run without installation • How to put in cloud? Cloud Game - Modules (2 of 2) Application Streams vs. Game Streams “Cuts” • Traditional thin client • Approximate traffic analysis applications (e.g., x-term, 1. All game logic on player, – 70 kb/s traditional network remote login shell): cloud only relay game – Relatively casual interaction – 700 kb/s virtual world information (traditional • e.g., typing or mouse clicking – 2000-7000 kb/s live video network game) – Infrequent display updates (HD) • e.g., character updates or 2. Player only gets input and – 1000-7000 kb/s pre-recorded scrolling text displays frames (remote • Computer games: video rendering) – Intense interaction • Cloud-based games? • e.g., avatar movement and 3. Player gets input and shooting – 7000 kb/s (HD) – Frequently changing displays renders frames (local • e.g., 360 degree panning rendering) Challenge: Latency since player input requires round-trip to server before player sees effects 4

  5. 2/26/2016 Outline Definition of Peer-to-Peer (P2P) • Significant autonomy from central servers • Network Games (done) • Exploits resources at edges of Internet – Architectures (done) – Storage and content – Compensation techniques (done) – Multicast routing – Cheating (done) – CPU cycles – Cloud games (done) – Human knowledge (e.g., recommendations, • Peer-to-Peer Systems (next) classification) – Overview • Resources at edge may have intermittent – P2P file sharing connectivity P2P File Sharing – General P2P Includes • Alice runs P2P client on • Asks for “Hey Jude” • P2P communication her laptop • Application displays – Instant messaging – Voice-over-IP (e.g., Skype) • Registers her content in other peers with copy • P2P multicast routing P2P system • Alice choses one, Bob – e.g., Mbone, Yoid, Scattercast • File is copied from Bob’s • P2P computation computer to Alice’s – e.g., seti@home, folding@home • P2P systems built on overlays  P2P – e.g., PlanetLab • While Alice downloads, • P2P file sharing others upload – e.g., Napster, gnutella, KaZaA, eDonkey, BitTorrent … Example: Searching P2P File Sharing Capabilities N 2 1000’s of nodes N 1 N 3 • Allows Alice to show directory in her file Set of nodes may change system – Anyone can retrieve file from it Key=“title” Internet ? – Like Web server Value=MP3 data… Client Publisher • Allows Alice to copy files from other’s Lookup(“title”) N 4 N 6 – Like Web client N 5 • Allows users to search nodes for content based on keyword matches • Needles versus Haystacks – Like search engine (e.g., Google) Searching for top 40 pop song? Or obscure punk track ‘81 nobody’s heard of? • Search expressiveness Whole word? Regular expressions? File names? Attributes? Whole-text search? 5

Recommend


More recommend