Networks Network Protocols Peertopeer ClientServer Configurations Trust Nov

Networks Network Protocols Peer-to-peer Client-Server Configurations Trust Nov 27, Fall 2006 IAT 410 1

Networks g Required for multiplayer games g 3 Standard technologies – Modems – Ethernet – Internet Nov 27, Fall 2006 IAT 410 2

Internet g The greatest thing since sliced bread g The savior of humanity g Will increase freedom and democracy – Around the world – In your neighborhood Nov 27, Fall 2006 IAT 410 3

Internet User Protocols g TCP g – Connection – Reliable – Bytes arrive in order they were sent – Collects small packets and transmits them together – Stream of bytes Nov 27, Fall 2006 UDP – Connectionless – Unreliable – Arbitrary arrival order IAT 410 4

TCP g Reliable stream of bytes – Implies the need for a “connection” g Connection sets up data structures – Hold incoming packets – Hold outgoing packets – Handle retransmits Nov 27, Fall 2006 IAT 410 5

TCP Reliability g Each packet does Send-Receive. Acknowledge Sender Send Receiver Receive Acknowledge g Sender holds sent packet until ACK is received g Sender retransmits if ACK takes too long Nov 27, Fall 2006 IAT 410 6

TCP One Send-Receive-Ack takes time g Overlay Sends and Acks g Maintain a queue in sender and receiver g Sender 0 Send Receiver Ack Sender 1 0 2 1 0 3 2 1 3 2 3 Nov 27, Fall 2006 IAT 410 7

TCP Circular Queue -- Sender g Sends data and Puts it in send queue g Sets timer on this queue item g If timer expires, and no ACK, re-send data – Set another, longer timer – Exponentially increasing time g When ACK received – If this queue slot is the oldest, • Free the slot for new data g If no queue space avail, sender app waits! Nov 27, Fall 2006 IAT 410 8

TCP Receive Queue g Receiver maintains a queue the same size as the sender’s g When a packet arrives, send ACK g If the packet is next in sequence – Give it to application g Else Keep it in queue – Another, earlier packet is on its way Nov 27, Fall 2006 IAT 410 9

TCP g If no ACKS arrive for a long enough time – Temporarily gives up – Sends test packets g When test packets get through – Starts slow, builds up Nov 27, Fall 2006 IAT 410 10

TCP Wrap-up g Connection sets up sequencing and queues – Reliable arrival: – Reliable order: g Retransmit Sequence numbers TCP bunches up data on 200 ms intervals – Minimizes overhead for small chunks of data – This option can be turned off g TCP Has an “emergency” channel – OOB Out Of Band Nov 27, Fall 2006 IAT 410 11

UDP g Connectionless! – No underlying data to maintain g Unreliable transmission – If you lose a packet, it’s gone – Network software must handle this g Out-of-order arrival – Network software must handle that, too! g Fast – When the port gets the data, the app gets it Nov 27, Fall 2006 IAT 410 12

UDP g Packets will drop! – 1 in 5 over non-local connection g Have to do your own re-send g Some packets are time sensitive – Care little about the past ship location g No header compression – May end up with greater overhead than TCP with PPP Nov 27, Fall 2006 IAT 410 13

Game Architectures g Peer-to-peer g Client/Server – One server per game g Floating server – One client is also a server g Distributed server – Multiple servers for large world Nov 27, Fall 2006 IAT 410 14

Peer-to-Peer g Simple version: Lockstep – eg. Doom – Each client transmits to other – Wait for everyone to get data – Proceed to next step Nov 27, Fall 2006 IAT 410 15

Peer-to-Peer g Advantages g – Simple – Nobody has to provide a server • Including the Game’s authors! – Good for turn-based games with low bandwidth – TCP Nov 27, Fall 2006 IAT 410 Disadvantages – Frame rate is that of • Slowest machine • Worst connection – Hackable – Not good for real-time games 16

Client/Server g Server per game – MUDs, Fireteam, Net. Trek – Someone must provide server ($$$) • Possibly the game’s authors – Less hackable – Single point of failure – Server must be big & well-connected Nov 27, Fall 2006 IAT 410 17

Floating Server Peer-to-peer g Server resolves the action g One peer is the server g – Unreal • One player elects to be the server – X-Wing vs Tie-Fighter: • First player to enter session – Starcraft • Player with the CD Nov 27, Fall 2006 IAT 410 18

Multiple Server g Many machines coordinate service – Ultima Online, Everquest, AOL g Used for large virtual worlds g Everquest – One server per game-geographic region – Freeze on handoff affects game play Nov 27, Fall 2006 IAT 410 19

What Data to Send? g Sending entire world state is usually too much g Can send just user actions – Simulation engine does the same thing at each client – Pseudo-random numbers from same seed Nov 27, Fall 2006 IAT 410 20

Sending User Actions-Problems g Any error in engine – Divergence in worlds – Small error can lead to big divergence g X-Wing vs Tie Fighter – Created a resynchronize protocol – Causes jumps • Wrote smoothing algorithm for resynchs g Sim City 2000 Network Edition – Send checksums for world state each turn Nov 27, Fall 2006 IAT 410 21

Prediction g Eg. Unreal g Waiting for user inputs is too slow g Client does prediction – Motion prediction g Server Nov 27, Fall 2006 corrects things if client is wrong IAT 410 22

Prediction: Dead Reckoning Eg. SIMNET (US Army Tank Simulator) g Each vehicle simulates own tank g Sends data every 5 seconds, updating g – Position, Speed, Acceleration – Expected path – Prediction violation criteria g Receiver simulates own tank – AND simulates local copy of other tanks Nov 27, Fall 2006 IAT 410 23

Dead Recokoning g Receiver gets latest 5 -second update g Updates own copy of other tanks g Predicts other tanks – Using prediction data – Until new data arrives g Each simulator also sends update – When own prediction violates own criteria g Assumes Nov 27, Fall 2006 latencies < 500 ms IAT 410 24

Dead Reckoning Sim A A’s Predicted Path Predict B Sim B B’s Predicted Path Predict A Sim A A’s Predicted Path Predict B Transmit new prediction every 5 seconds Nov 27, Fall 2006 IAT 410 Sim B B’s Predicted Path Predict A B Exceeds prediction: predict again and transmit 25

Dead Reckoning: Requirements g Data structures for other entities g Model of entity behavior – Vehicle speed, acceleration range, turn radius – Responsiveness to commands g Situation parameters – Following a road – Precomputed path (NPCs) Nov 27, Fall 2006 IAT 410 26

Multiple Copies g Maintain 2 Data sets g Now – Accurate self – Predicted others – “Zero” latency for self g Ground Truth – Accurate everybody – Large latency for almost everybody – 200 -500 ms ago Nov 27, Fall 2006 IAT 410 27

Latency Issues g When latencies get high – Prediction gets worse and worse g Correcting prediction errors may cause visual jumps – Easy to notice! g If jumps are large enough – Temporarily interpolate between wrong prediction and the new correction Nov 27, Fall 2006 IAT 410 28

Prediction Interpolated Response Real Predicted Nov 27, Fall 2006 IAT 410 29

Token Ownership g Some games may allow distributed ownership – Ballistic simulation – Shooter fires bullet – Intended target receives the simulation g Sports - eg. Tennis – Player A hits ball – Player B gets simulation token – B simulates ball path from A’s racket Nov 27, Fall 2006 IAT 410 30

Trust g “Never trust the client” g Data on the user’s hard drive is insecure – Diablo utility to modify character data – Wrote patch to prevent hacking • Throws out your stuff if there’s a time inconsistency – Daylight savings nuked my stuff! Nov 27, Fall 2006 IAT 410 31

Trust g Network communications are insecure g Net. Trek communications are encrypted g Net. Trek also requires “blessed” client – Servers have different policies on requiring a blessed client – Prevents robot players or assistants Nov 27, Fall 2006 IAT 410 32

Trust -- Checksums g First line of defense: – Checksum of all packets – Include header in checksum! – Stops casual tampering g Hash function – Hard to compute source value from result – MD 5 Nov 27, Fall 2006 IAT 410 33

Checksums g Not immune to: – Code disassembly – Packet replay g 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 Nov 27, Fall 2006 IAT 410 34

Combating Replay g 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 g Random numbers – Seeds must match! – Dropped packets: include sequence number! Nov 27, Fall 2006 IAT 410 35

Combating Replay g XOR each packet with a pseudo-random bit pattern – Make sure the bit patterns are in sync! – Based on previous synchronized pseudorandom numbers g Add junk – Confuse length analysis Nov 27, Fall 2006 IAT 410 36

Reverse Engineering g Remove symbols g Put encryption code in with rest of network stuff g Compute magic numbers: – At runtime – In server g Encrypt Nov 27, Fall 2006 from the start! IAT 410 37

Lists Of Servers g Denial of service: – Send a packet to server-server saying “I’m 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 Nov 27, Fall 2006 IAT 410 38

List of Servers g 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! Nov 27, Fall 2006 IAT 410 39