! " Lecture 5: Networking for Games (cont d) Packet headers. Packet footers. IP address. Edge router (cable modem, DSL modem)

Transcription

1 Lecture 5: Networking for Games (cont d) Special Send case: to NAT network [0-128] IP address Edge router (cable modem, DSL modem) Core routers (divided by autonomous systems (AS)) ! " 1. Application 2. Presentation 3. Session 4. Transport Socket to socket Examples: TCP and UDP 5. Network/internet 6. Link Host to host (across WAN) Example: IP Hosts directly connected (LAN) Example: Ethernet, Physical Electrical, bit encoding, Packet headers Packet footers ETH IP TCP Application Data ( payload ) TCP IP ETH

2 #$ Sliding window used for flow & congestion control Window size adjusted to limit number of outstanding packets Ideally window size ~(2 * bandwidth * roundtrip latency) WHY? Receiver ACKs every in-order packet Go-back-N retransmission policy (not selective retransmit) ACK of packet N implicitly ACKs packets [0,N-1] Sender shifts transmit window in response to ACKs Lack of ACK is implicit NACK timeout and retransmit Dropping a packet induces a LARGE bubble/latency Slow start makes it worse (window size halves, slowly grows) Either dropped data or dropped ACKs can cause retransmission» Dropped ACKs not quite as bad due to subsequent ACKs Window size: # % Large is good can hide round trip latency (DISCUSS) Small is good minimize buffering, go-back-n penalty, minimize congestion, less likely to have receiver overflow Goal: 2 x bandwidth x roundtrip-latency (DISCUSS) Window used for Flow/congestion control: Limit # of un-ack d packets sent Reliability: Go-back-N retransmission policy Good features of TCP: Reliable, ordered message delivery Plays nice reacts to congestion & flow control problems Nevertheless, few games use TCP for game actions Why is that? (DISCUSS) & % Raw best efforts packet delivery (to socket) Does not handle: Flow control Congestion control Dropped packets (reliable delivery) Reordered packets (in-order delivery) Given all of these problems, why do most (real-time) games use UDP? DISCUSS

3 &% Observation: Can build desired TCP behaviors into application layer Application-level sequence numbers Retransmit critical data (or make application updates redundant)» Q: How might you make updates redundant? Can even do application-level flow and congestion control Observation: Old data is often useless Why retransmit state of game N msecs ago just send new state Issue: Ensure updates include previous update info» Option: Send absolute updates, not relative» Option: Piggyback un-ack d old updates on new ones Discussion: What are the implications of this design approach? ' ((&!# )& " TCP is best for backend processing Authentication, CD key checking, billing Ranking, ladder, reputation, black lists Buddy lists, clans/guilds, chat (even in-game) Patches, downloads, updates UDP is best for in-game, real-time messages: Can prioritize/filter data (critical data vs flavor data) Send absolute updates, no deltas (if feasible)» If deltas, send baseline (key frame) data occasionally Use soft state (more on this later) Add reliability/congestion control as needed» Avoid flow control by limiting amount of communication % Lots of little packets vs fewer large packets Q: Does it matter? If so, does it matter much? A: Yes, routers route packets the fewer the better Of course, too big can cause problems, too» Limited buffering» Cross-packet interference» Receiver buffer/processing» Raw link bandwidth and fragmentation

4 %!*" Hostname vs IP address Q: How do you determine IP address from hostname? A: Domain name service (DNS)» gethostbyname( trust.cs.utah.edu ) » gethostbyaddr( ) trust.cs.utah.edu» Use man pages and nslookup to play with DNS Q: How are addresses assigned? A: Static (class A-D or by ISP) or dynamic (DHCP) issues! Servers can play DNS games Different DNS servers can have different mappings Can assign multiple IP addresses to single hostname» DNS server will hand them out round robin Q: What are the implications? Wired LANs: ' (+%,-./ Very low drop rates basically only receive buffer overflow High bandwidths Mbps (per node or shared) Low latencies ~ 1msec Wireless LANs: Modest drop rates often enough to notice Modest bandwidths Mbps (variable and shared) Low latencies ~ 1-10msecs Internet (WAN) Modest drop rates but sporadic and subject to major spikes Modest bandwidths usually determined by 1 st hop» Dialup? DSL? Cable modem? UTOPIA? High latencies msecs (US), msecs (international) Go play with: 0 12 nslookup: see how naming is done tcpdump / Ethereal: see what s flying over network ping: see how long it takes to talk to» US sites (university, commercial, hi-speed house, dial-up house)» International sites: Europe, Asia, Australia, Not graded go have fun with it

5 RTS: 3. / < 250ms not noticeable ms playable > 500ms not playable FPS: < 150ms preferred, particular latency sensitive Car racing: < 100ms preferred ms sluggish > 500ms, car out of control (like driving QE2) Players can adapt to latency if steady Variable latency is bad slow but smooth better 2# 2 # Issue: Can multiple computers share a single IP address? Solution: NAT 1. Router has two addresses External: Real IP address Internal: Local-only IP address 2. Local hosts request IP addr from router (DHCP) Returns local-only IP address 3. Outgoing connections: Table w/ per-connection entries Use port number to differentiate Forward responses from Internet to appropriate host/index 100: : : : Ext: Int: # Machines can have multiple IP addresses: Local IP address: Only means something inside LAN Global IP address: Visible address shared by many devices Q: Can we assume that IP address == machine? A: No multiple devices can have identical external IP address A: No machine s IP address can change (DHCP) Q: Can we handle incoming connections? A: Not very well If nobody has connected out as #.#.#.#:yyy, where should the router send an incoming connection to #.#.#.#:yyy? Partial solution: Can manually configure port forwarding» Not a great idea unsophisticated users» Sure to drive up your live-help costs if you do

6 Designed to keep unwanted traffic away Incoming Outgoing Enforce simple rules Only ports 80 and 25 (in/out) Only in to :80 No outgoing connections to playboy.com Can be enforced in HW or SW (e.g., ZoneAlarm) Q: What implications does this have on game design? A: Similar to NAT 5 X X - Proxy: A process that sits between client & server From client perspective, looks like the server From server perspective, looks like the client Application-specific knowledge built into proxy Use of proxies? Caching: Answer client from local (proxy) cache Firewall: Implement application-specific filtering rules Question: How could we exploit proxies for gaming? Classic vs transparent proxies: Classic: Client explicitly connects to proxy Transparent: Proxy intercepts packets w/o client knowledge» Either by sitting in middle or via dynamic server lookup Socket programming: socket() connect() bind() listen() accept() send/sendto() recv/from() closesocket() -# Homework: Read up on these system calls Online manual pages Networking text books (see next page)

7 $4 Computer Networks: A Systems Approach, Peterson and Davie, Morgan-Kaufmann UNIX Network Programming: Vol 1, 2 nd /3 rd edition R. Stevens, Prentice-Hall 6 %/ Next time: More networking for game designers