Oct 31, Fall 2005Game Design1 Networks Network Protocols Peer-to-peer Client-Server Configurations...

Click here to load reader

download Oct 31, Fall 2005Game Design1 Networks Network Protocols Peer-to-peer Client-Server Configurations Trust

of 43

  • date post

    14-Dec-2015
  • Category

    Documents

  • view

    213
  • download

    0

Embed Size (px)

Transcript of Oct 31, Fall 2005Game Design1 Networks Network Protocols Peer-to-peer Client-Server Configurations...

  • Slide 1

Oct 31, Fall 2005Game Design1 Networks Network Protocols Peer-to-peer Client-Server Configurations Trust Slide 2 Oct 31, Fall 2005Game Design2 Topics AI Flocking & coordinated movement Planning Pathfinding and search Networking Multiplayer/things not covered today Audio Slide 3 Oct 31, Fall 2005Game Design3 Other topics Advanced graphics Animation Deformation, inverse kinematics Motion capture Particle effects Special lighting Ethics Cheating, justice Slide 4 Oct 31, Fall 2005Game Design4 Other topics Fake terrain Industry Playtesting AIwisdom.com Slide 5 Oct 31, Fall 2005Game Design5 Networks Required for multiplayer games 3 Standard technologies Modems Ethernet Internet Slide 6 Oct 31, Fall 2005Game Design6 Internet The greatest thing since sliced bread The savior of humanity Will increase freedom and democracy Around the world In your neighborhood Slide 7 Oct 31, Fall 2005Game Design7 Internet User Protocols TCP Connection Reliable Bytes arrive in order they were sent Collects small packets and transmits them together Stream of bytes UDP Connectionless Unreliable Arbitrary arrival order Slide 8 Oct 31, Fall 2005Game Design8 TCP Reliable stream of bytes Implies the need for a connection Connection sets up data structures Hold incoming packets Hold outgoing packets Handle retransmits Slide 9 Oct 31, Fall 2005Game Design9 TCP Reliability Each packet does Send-Receive- Acknowledge Sender holds sent packet until ACK is received Sender retransmits if ACK takes too long Sender Receive Receiver Send Acknowledge Slide 10 Oct 31, Fall 2005Game Design10 TCP One Send-Receive-Ack takes time Overlay Sends and Acks Maintain a queue in sender and receiver 0 1 2 3 0 1 2 3 Ack 0 1 2 3 Send Sender Receiver Slide 11 Oct 31, Fall 2005Game Design11 TCP Circular Queue -- Sender Sends data and Puts it in send queue Sets timer on this queue item If timer expires, and no ACK, re-send data Set another, longer timer Exponentially increasing time When ACK received If this queue slot is the oldest, Free the slot for new data If no queue space avail, sender app waits! Slide 12 Oct 31, Fall 2005Game Design12 TCP Receive Queue Receiver maintains a queue the same size as the senders When a packet arrives, send ACK If the packet is next in sequence Give it to application Else Keep it in queue Another, earlier packet is on its way Slide 13 Oct 31, Fall 2005Game Design13 TCP If no ACKS arrive for a long enough time Temporarily gives up Sends test packets When test packets get through Starts slow, builds up Slide 14 Oct 31, Fall 2005Game Design14 TCP Wrap-up Connection sets up sequencing and queues Reliable arrival: Retransmit Reliable order:Sequence numbers TCP bunches up data on 200ms intervals Minimizes overhead for small chunks of data This option can be turned off TCP Has an emergency channel OOB Out Of Band Slide 15 Oct 31, Fall 2005Game Design15 UDP Connectionless! No underlying data to maintain Unreliable transmission If you lose a packet, its gone Network software must handle this Out-of-order arrival Network software must handle that, too! Fast When the port gets the data, the app gets it Slide 16 Oct 31, Fall 2005Game Design16 UDP Packets will drop! 1 in 5 over non-local connection Have to do your own re-send Some packets are time sensitive Care little about the past ship location No header compression May end up with greater overhead than TCP with PPP Slide 17 Oct 31, Fall 2005Game Design17 Game Architectures Peer-to-peer Client/Server One server per game Floating server One client is also a server Distributed server Multiple servers for large world Slide 18 Oct 31, Fall 2005Game Design18 Peer-to-Peer Simple version: Lockstep eg. Doom Each client transmits to other Wait for everyone to get data Proceed to next step Slide 19 Oct 31, Fall 2005Game Design19 Peer-to-Peer Advantages Simple Nobody has to provide a server Including the Games authors! Good for turn-based games with low bandwidth TCP Disadvantages Frame rate is that of Slowest machine Worst connection Hackable Not good for real-time games Slide 20 Oct 31, Fall 2005Game Design20 Client/Server Server per game MUDs, Fireteam, NetTrek Someone must provide server ($$$) Possibly the games authors Less hackable Single point of failure Server must be big & well-connected Slide 21 Oct 31, Fall 2005Game Design21 Floating Server Peer-to-peer Server resolves the action One peer is the server Unreal One player elects to be the server X-Wing vs Tie-Fighter: First player to enter session Starcraft Player with the CD Slide 22 Oct 31, Fall 2005Game Design22 Multiple Server Many machines coordinate service Ultima Online, Everquest, AOL Used for large virtual worlds Everquest One server per game-geographic region Freeze on handoff affects game play Slide 23 Oct 31, Fall 2005Game Design23 What Data to Send? Sending entire world state is usually too much Can send just user actions Simulation engine does the same thing at each client Pseudo-random numbers from same seed Slide 24 Oct 31, Fall 2005Game Design24 Sending User Actions-- Problems Any error in engine Divergence in worlds Small error can lead to big divergence X-Wing vs Tie Fighter Created a resynchronize protocol Causes jumps Wrote smoothing algorithm for resynchs Sim City 2000 Network Edition Send checksums for world state each turn Slide 25 Oct 31, Fall 2005Game Design25 Prediction Eg. Unreal Waiting for user inputs is too slow Client does prediction Motion prediction Server corrects things if client is wrong Slide 26 Oct 31, Fall 2005Game Design26 Prediction: Dead Reckoning Eg. SIMNET (US Army Tank Simulator) Each vehicle simulates own tank Sends data every 5 seconds, updating Position, Speed, Acceleration Expected path Prediction violation criteria Receiver simulates own tank AND simulates local copy of other tanks Slide 27 Oct 31, Fall 2005Game Design27 Dead Recokoning Receiver gets latest 5-second update Updates own copy of other tanks Predicts other tanks Using prediction data Until new data arrives Each simulator also sends update When own prediction violates own criteria Assumes latencies < 500ms Slide 28 Oct 31, Fall 2005Game Design28 Dead Reckoning Sim A As Predicted Path Bs Predicted Path Sim B Sim A As Predicted Path Bs Predicted Path Sim B B Exceeds prediction: predict again and transmit Transmit new prediction every 5 seconds Predict B Predict A Slide 29 Oct 31, Fall 2005Game Design29 Dead Reckoning: Requirements Data structures for other entities Model of entity behavior Vehicle speed, acceleration range, turn radius Responsiveness to commands Situation parameters Following a road Precomputed path (NPCs) Slide 30 Oct 31, Fall 2005Game Design30 Multiple Copies Maintain 2 Data sets Now Accurate self Predicted others Zero latency for self Ground Truth Accurate everybody Large latency for almost everybody 200-500ms ago Slide 31 Oct 31, Fall 2005Game Design31 Latency Issues When latencies get high Prediction gets worse and worse Correcting prediction errors may cause visual jumps Easy to notice! If jumps are large enough Temporarily interpolate between wrong prediction and the new correction Slide 32 Oct 31, Fall 2005Game Design32 Prediction Interpolation Real Interpolated Response Predicted Slide 33 Oct 31, Fall 2005Game Design33 Some games may allow distributed ownership Ballistic simulation Shooter fires bullet Intended target receives the simulation Sports - eg. Tennis Player A hits ball Player B gets simulation token B simulates ball path from As racket Token Ownership Slide 34 Oct 31, Fall 2005Game Design34 Trust Never trust the client Data on the users hard drive is insecure Diablo utility to modify character data Wrote patch to prevent hacking Throws out your stuff if theres a time inconsistency Daylight savings nuked my stuff! Slide 35 Oct 31, Fall 2005Game Design35 Trust Network communications are insecure NetTrek communications are encrypted NetTrek also requires blessed client Servers have different policies on requiring a blessed client Prevents robot players or assistants Slide 36 Oct 31, Fall 2005Game Design36 Trust -- Checksums First line of defense: Checksum of all packets Include header in checksum! Stops casual tampering Hash function Hard to compute source value from result MD5 Slide 37 Oct 31, Fall 2005Game Design37 Checksums Not immune to: Code disassembly Packet replay Packet replay attack: Capture a legal packet, and re-send it more frequently than allowed Client can restrict send frequency Server cannot reject high-frequency packets Internet bunch-ups are source of OK bunch-ups Slide 38 Oct 31, Fall 2005Game Design38 Combating Replay Each new packet client sends is different Add a pseudo-random number to each packet Not just sequence number! Client & Server match pseudo-random numbers Random numbers Seeds must match! Dropped packets: include sequence number! Slide 39 Oct 31, Fall 2005Game Design39 Combating Replay XOR each packet with a pseudo-random bit pattern Make sure the bit patterns are in sync! Based on previous synchronized pseudo- random numbers Add junk Confuse length analysis Slide 40 Oct 31, Fall 2005Game Design40 Reverse Engineering Remove symbols Put encryption code in with rest of network stuff Compute magic numbers: At runtime In server Encrypt from the start! Slide 41 Oct 31, Fall 2005Game Design41 Lists Of Servers Denial of service: Send a packet to server-server saying Im a server Fake the IP return address with a random IP# Server-server adds new server to list Server may run out of memory storing hundreds of thousands of fake servers Slide 42 Oct 31, Fall 2005Game Design42 List of Servers Require a dialog Server-list server responds with Password Keepalive interval Password must be given by attacker at the correct time Works OK if client is not better connected! Slide 43 Oct 31, Fall 200