Lecture notes.
Upcoming SlideShare
Loading in...5

Lecture notes.






Total Views
Views on SlideShare
Embed Views



0 Embeds 0

No embeds



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

    Lecture notes. Lecture notes. Presentation Transcript

    • Last Time
      • More collision detection packages
      • Time critical collision detection
      • Introduction to networking for games
    • Today
      • Networking protocols
      • Cheating and Security
        • Great article: Evaluations
    • Internet Protocols
      • There are only two internet protocols that are widely deployed and useful for games: UDP and TCP/IP
        • TCP/IP (Transmission Control Protocol/Internet Protocol) is most commonly used
        • UDP (User Datagram Protocol) is also widely deployed and used
      • Other protocols exist:
        • Proprietary standards
        • Broadcast and Multicast are standard protocols with some useful properties, but they are not widely deployed
        • If the ISPs don’t provide it, you can’t use it
    • TCP/IP Overview
      • Advantages:
        • Guaranteed packet delivery
        • Ordered packet delivery
        • Packet checksum checking (some error checking)
        • Transmission flow control
      • Disadvantages:
        • Point-to-point transport
        • Bandwidth and latency overhead
        • Packets may be delayed to preserve order
      • Uses:
        • Data that must be reliably sent, or requires one of the other properties
        • Games that can tolerate latency
    • UDP Overview
      • Advantages:
        • Low overhead in bandwidth and latency
        • Immediate delivery - as soon as it arrives it goes to the client
      • Disadvantages:
        • Point to point connectivity
        • No reliability guarantees
        • No ordering guarantees
        • Packets can be corrupted
        • Can cause problems with some firewalls
      • Uses:
        • Data that is sent frequently and goes out of date quickly
    • Choosing a Protocol
      • The best way to do it is decide on the requirements and find the protocol to match
        • In most cases, that means TCP/IP
      • You can also design your own “protocol” by designing the contents of packets
        • A protocol is simply a set of rules for putting data in the packets and acting upon it
        • Add cheat detection or error correction, for instance
        • You then wrap you protocol inside TCP/IP or UDP – just send your “packet” as a regular chunk of data
    • Reducing Bandwidth Demands
      • Bandwidth is plentiful on the internet today, so it only becomes an issue with large environments
        • Even “slow” modems have more impact through high latency than low bandwidth (due to compression, error checking and analogue/digital conversion)
      • Regardless, smaller packets reduce both bandwidth and latency
        • Latency is measured from the time the first bit leaves to the time the last bit arrives - so fewer bits have lower latency
      • There are two primary ways to reduce bandwidth demands:
        • Dead reckoning allows you to send state less frequently
        • Area of interest management avoids sending irrelevant data
    • Area of Interest Management
      • Area of interest management is the networking equivalent of visibility - only send data to the people who need it
      • There is a catch, however: In a network you may not know where everyone is, so you don’t know what they can see
        • A chicken-and-egg problem
      • Hence, area-of-interest schemes are typically employed in client-server environments:
        • The server has complete information
        • It decides who needs to receive what information, and only sends information to those who need it
      • Two approaches: grid methods and aura methods
        • Sound familiar? (replace aura with bounding box)
    • Grid and Aura Methods
      • Grid methods break the world into a grid
        • Associate information with cells
        • Associate players with cells
        • Only send information to players in the same, or neighboring, cells
        • This has all the same issues as grid based visibility and collision detection
      • Aura methods associate an aura with each piece of information
        • Only send information to players that intersect the aura
        • Just like broad-phase collision detection with bounding volumes
      • Players need to find out all the information about a space when they enter it, regardless how long ago that information last changed
        • In other words, have to be careful with “state” information that is infrequently sent
    • Building for Networking
      • It is generally agreed that networking must be a consideration from the start of development
      • There are many good practices – see game programming web sites for tips (and descriptions of past mistakes)
      • One good practice: Access all data through a consistent interface, which both the networking and local code uses
        • Avoids different side effects from different access points
        • Can check for validity of data in one place, which makes checking for network errors easier
        • Can decrypt/encrypt in one place
        • Can automatically propagate data onto network
    • Cheating
      • It’s an arms race…
        • http://www.gamasutra.com/features/20000724/pritchard_01.htm
    • Why Care About Cheats?
      • Online gaming is big business
      • Cheats can achieve financial advantage:
        • Competitive games with prizes are the obvious example (casinos)
        • Also consider EverQuest: People play the game, build good characters, and then auction them on ebay. If they can cheat to obtain good characters, they are achieving unfair financial advantage
      • Cheats can ruin the game for everyone:
        • Players tend to have a strong sense of fairness
        • If they believe they are being cheated, they will not play, and you will not make any money
      • Single player cheaters typically only affect themselves, so you don’t care
    • Sources of Cheats
      • Reflex augmentation : Use a cheat to improve some aspect of physical performance, such as the firing rate or aiming
      • Authoritative clients : Clients issue commands that are inconsistent with the game-play, or mimic the server
      • Information Exposure : Clients obtain information that should be hidden
      • Compromised servers : A hacked server biases game-play toward the group that knows of the hacks
      • Bugs and Design Loopholes : Bugs are found and exploited, or parts of the program intended for one purpose are used for another
      • Environmental Weakness : Differences or problems with the OS or network environment are exploited
    • Observations About Cheating
      • The only way to make a system 100% secure is to completely isolate it (Eric Brewer, 1996)
      • Pritchard’s Rules (Gamasutra article):
        • If you build it, they will come - to hack and cheat
        • Hacking attempts increase as a game becomes more successful
        • Cheaters actively try to control knowledge of their cheats
        • Your game, along with everything on the cheater’s computer, in not secure - not memory, not files, not devices and networks
        • Obscurity is not security
        • Any communication over an open line is subject to interception, analysis and modification
        • There is no such thing as a harmless cheat
        • Trust in the server is everything in client-server games
        • Honest player would like the game to tip them off to cheater, hackers hate it
    • Reflex Augmentation
      • Aiming proxies intercept communications, build a map of where people are, and automatically shoot them
      • Rapid-fire proxies take each “shoot” packet and replicate it
      • Fix #1: The server validates player actions - if they are too good the player is considered a cheat and kicked out
        • What’s hard about this?
      • Fix #2: Make it difficult to insert non-valid packets
        • Encrypt the packets, but your encryption must be cheap, and cheap encryption can be broken
        • Make the encryption depend on the game state or other time-dependent “random” value. Hard to do with UDP. Why?
        • If using guaranteed delivery (TCP) serialize packets with a unique sequence of numbers - cannot then replicate or insert extra packets
    • A Word on Encryption
      • Typically: A key – known only to intended users – is used to convert regular data into something that looks random
        • Cannot go from random data back to key, or to the real data
      • Many ways to come up with the key
        • Agree on it ahead of time
        • Transmit it – key exchange algorithms
        • Derive it from somewhere else in such a way that all parties derive the same key (e.g. from game state)
      • Most encryption algorithms work on blocks of a fixed size
        • Split large amounts of data into smaller blocks
        • Pad blocks that are too small
    • Authoritative Clients
      • Occurs when one player’s game informs everyone else that a definitive event has occurred: e.g. I just got a power-up
      • Hacked clients can be created in many ways: change the executable, change game data in other files, hack packets
      • Fix is to insert command request steps:
        • Player request an action, its validity is checked, it is sent out on the network, and added to the player’s pending event queue
        • Incoming actions also go on the pending queue
        • Actions come off the pending queue, are validated again, and then are implemented
      • Sometimes validation is hard to get right, so try synchronization
        • Occasionally send complete game state around, and compare it
        • Actually, send something derived from complete game state
    • Information Exposure
      • Some classics: Modify the renderer to make walls transparent, modify maps to remove the fog of war
      • Basically, display variables must be modified in memory, or read out and displayed elsewhere
        • Hackers are very good at finding the locations of key data in memory, and modifying them transparently
      • Fixes:
        • Check that players agree on the value of certain variables, and the validity of actions - synchronization again
          • Note that you can look for actions that cannot be valid with the correct display
        • Compile statistics on drawing, and see of they look off (eg # polygons drawn)
        • Encrypt data in memory to avoid passive attacks
    • Compromised Servers
      • Many servers have customization options, and the community is encouraged to modify the server
        • This is completely legal
      • However, as a game becomes popular, naïve people start to play the game
        • They do not have the skills or knowledge to check that the server they are playing on is “pure”
        • They will grow frustrated, blame the developer, and complain to their friends
      • Some modifications can be very insidious, and may not be legal. For example, hack the server to do different damage for opponents
      • Solution is to warn people when they connect to the server, and about any other non standard properties (found through validation)
    • Bugs and Design Issues
      • Some bugs enable cheating, such as a bug that enables fast reloading, or one that incorrectly validates commands
      • Some design decisions make cheating easier:
        • Embedding cheats codes in single player mode makes it easy for a hacker to track down the variables that control cheats
        • Poor networking or event handling can allow repeat commands or other exploitations
          • Age of Empires and Starcraft example: all resource management is done after all events for a turn are processed. Poor networking allowed multiple cancel events on the queue, which restored multiple resources
      • Solution is to avoid bugs and think carefully about the implications of design decisions on hacking
    • Environmental Weaknesses
      • Facilities to deal with the OS or network may leave you vulnerable to some forms of attack
        • Interaction with the clipboard can introduce non-printable characters
        • Interaction with almost any scripting language may leave you open to hacks not related to the game itself (ie your game could be a way in)
        • Network connection drops or overloading can cause problems
      • Some cheats destroy the game for every player (tip the board) which can be useful if you are losing
      • Others knock off a specific player (your worst enemy, one assumes)
    • The Moral of the Story
      • You can’t win, you just try to make cheating as hard as possible and contain the damage
    • Todo
      • By Thursday, Dec 11, Midday, Final Demo
      • Monday, Dec 15, Final Exam, 2:45 P.M, RM 1221 CS