1 / 47

Chapter 2: outline

Chapter 2: outline. 2.5 DNS. 2.6 P2P applications 2.7 socket programming with UDP 2.8 socket programming with TCP. people: many identifiers: SSN, name, passport # Internet hosts, routers: IP address (32 bit) - used for addressing datagrams “name”, e.g., www.yahoo.com - used by humans

frankowens
Download Presentation

Chapter 2: outline

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Chapter 2: outline 2.5 DNS 2.6 P2P applications 2.7 socket programming with UDP 2.8 socket programming with TCP Application Layer

  2. people: many identifiers: SSN, name, passport # Internet hosts, routers: IP address (32 bit) - used for addressing datagrams “name”, e.g., www.yahoo.com - used by humans Q: how to map between IP address and name, and vice versa ? Domain Name System: distributed database implemented in hierarchy of many name servers application-layer protocol: hosts, name servers communicate to resolvenames (address/name translation) note: core Internet function, implemented as application-layer protocol DNS: domain name system Application Layer

  3. why not centralize DNS? : : : : DNS services : : : : DNS: services, structure A: Application Layer

  4. Root DNS Servers org DNS servers edu DNS servers com DNS servers poly.edu DNS servers umass.edu DNS servers pbs.org DNS servers yahoo.com DNS servers amazon.com DNS servers DNS: a distributed, hierarchical database … … client wants IP for www.amazon.com: • : • : • : Application Layer

  5. contacted by local name server that can not resolve name root name server: contacts authoritative name server if name mapping not known gets mapping returns mapping to local name server DNS: root name servers c. Cogent, Herndon, VA (5 other sites) d. U Maryland College Park, MD h. ARL Aberdeen, MD j. Verisign, Dulles VA (69 other sites ) k. RIPE London (17 other sites) i. Netnod, Stockholm (37 other sites) m. WIDE Tokyo (5 other sites) e. NASA Mt View, CA f. Internet Software C. Palo Alto, CA (and 48 other sites) 13 root name “servers” worldwide a. Verisign, Los Angeles CA (5 other sites) b. USC-ISI Marina del Rey, CA l. ICANN Los Angeles, CA (41 other sites) g. US DoD Columbus, OH (5 other sites) Application Layer

  6. TLD, authoritative servers top-level domain (TLD) servers: • : • : • : authoritative DNS servers: • : Application Layer

  7. Local DNS name server • : • : • : • : • : Application Layer

  8. host at cis.poly.edu wants IP address for cs.virginia.edu local DNS server dns.poly.edu DNS name resolution example root DNS server TLD DNS server iterated query: • : • : authoritative DNS server dns.cs.virginia.edu requesting host cis.poly.edu gaia.cs.virginia.edu Application Layer

  9. local DNS server dns.poly.edu DNS name resolution example root DNS server recursive query: • : • : TLD DNS server authoritative DNS server dns.cs.umass.edu requesting host cis.poly.edu gaia.cs.umass.edu Application Layer

  10. DNS reflection Attack Send DNS request And Spoof IP Header Application Layer

  11. once (any) name server learns mapping, it caches mapping cache entries timeout (disappear) after some time (TTL) TLD servers typically cached in local name servers thus root name servers not often visited cached entries may be out-of-date (best effort name-to-address translation!) if name host changes IP address, may not be known Internet-wide until all TTLs expire update/notify mechanisms proposed IETF standard RFC 2136 DNS: caching, updating records Application Layer

  12. DNS: distributed db storing resource records (RR) type=NS name is domain (e.g., foo.com) value is hostname of authoritative name server for this domain DNS records RR format:(name, value, type, ttl) type=A • nameis hostname • valueis IP address type=CNAME • name is alias name for some “canonical” (the real) name • www.ibm.comis really servereast.backup2.ibm.com • valueis canonical name type=MX • valueis name of mailserver associated withname Application Layer

  13. queryand reply messages, both with same message format 2 bytes 2 bytes identification flags # questions # answer RRs # additional RRs # authority RRs questions (variable # of questions) answers (variable # of RRs) authority (variable # of RRs) additional info (variable # of RRs) DNS protocol, messages msg header • identification: 16 bit # for query, reply to query uses same # • flags: • query or reply • recursion desired • recursion available • reply is authoritative Application Layer

  14. 2 bytes 2 bytes identification flags # questions # answer RRs # additional RRs # authority RRs questions (variable # of questions) answers (variable # of RRs) authority (variable # of RRs) additional info (variable # of RRs) DNS protocol, messages name, type fields for a query RRs in response to query records for authoritative servers additional “helpful” info that may be used Application Layer

  15. Inserting records into DNS • example: new startup “Network Utopia” • register name networkuptopia.com at DNS registrar (e.g., Network Solutions) • provide names, IP addresses of authoritative name server (primary and secondary) • registrar inserts two RRs into .com TLD server:(networkutopia.com, dns1.networkutopia.com, NS) (dns1.networkutopia.com, 212.212.212.1, A) • create authoritative server type A record for www.networkuptopia.com; type MX record for networkutopia.com Application Layer

  16. DEMO • Ssh power1.cs.virgini.edu • Nslookup • Dig • More /etc/resolv.conf • Whois (Arin.com) Application Layer

  17. Synthesis: a day in the life of a web request • journey down protocol stack complete! • application, transport, network, link • putting-it-all-together: synthesis! • goal:identify, review, understand protocols (at all layers) involved in seemingly simple scenario: requesting www page • scenario:student attaches laptop to campus network, requests/receives www.google.com Link Layer and LANs

  18. browser A day in the life: scenario DNS server Comcast network 68.80.0.0/13 school network 68.80.2.0/24 web page web server Google’s network 64.233.160.0/19 64.233.169.105 Link Layer and LANs

  19. DHCP UDP IP Eth Phy DHCP UDP IP Eth Phy DHCP DHCP DHCP DHCP DHCP DHCP DHCP DHCP DHCP DHCP A day in the life… connecting to the Internet • connecting laptop needs to get its own IP address, addr of first-hop router, addr of DNS server: use DHCP • DHCP request encapsulated in UDP, encapsulated in IP, encapsulated in 802.3 Ethernet router (runs DHCP) • Ethernet frame broadcast (dest: FFFFFFFFFFFF) on LAN, received at router running DHCP server • Ethernet demuxed to IP demuxed, UDP demuxed to DHCP Link Layer and LANs

  20. DHCP UDP IP Eth Phy DHCP UDP IP Eth Phy DHCP DHCP DHCP DHCP DHCP DHCP DHCP DHCP DHCP A day in the life… connecting to the Internet • DHCP server formulates DHCP ACKcontaining client’s IP address, IP address of first-hop router for client, name & IP address of DNS server • encapsulation at DHCP server, frame forwarded (switch learning) through LAN, demultiplexing at client router (runs DHCP) • DHCP client receives DHCP ACK reply Client now has IP address, knows name & addr of DNS server, IP address of its first-hop router Link Layer and LANs

  21. ARP ARP Eth Phy ARP query ARP reply DNS UDP IP Eth Phy DNS DNS DNS A day in the life… ARP (before DNS, before HTTP) • before sending HTTPrequest, need IP address of www.google.com: DNS • DNS query created, encapsulated in UDP, encapsulated in IP, encapsulated in Eth. To send frame to router, need MAC address of router interface: ARP • ARP query broadcast, received by router, which replies with ARP reply giving MAC address of router interface router (runs DHCP) • client now knows MAC address of first hop router, so can now send frame containing DNS query Link Layer and LANs

  22. DNS UDP IP Eth Phy DNS UDP IP Eth Phy DNS DNS DNS DNS DNS DNS DNS DNS DNS A day in the life… using DNS DNS server Comcast network 68.80.0.0/13 • IP datagram forwarded from campus network into Comcast network, routed (tables created by RIP, OSPF, IS-IS and/or BGP routing protocols) to DNS server router (runs DHCP) • IP datagram containing DNS query forwarded via LAN switch from client to 1st hop router • demuxed to DNS server • DNS server replies to client with IP address of www.google.com Link Layer and LANs

  23. SYN SYN SYN SYN SYN SYN SYN HTTP TCP IP Eth Phy TCP IP Eth Phy HTTP SYNACK SYNACK SYNACK SYNACK SYNACK SYNACK SYNACK A day in the life…TCP connection carrying HTTP • to send HTTP request, client first opens TCP socket to web server router (runs DHCP) • TCP SYN segment (step 1 in 3-way handshake) inter-domain routed to web server • web server responds with TCP SYNACK (step 2 in 3-way handshake) web server 64.233.169.105 • TCP connection established! Link Layer and LANs

  24. Three way handshake Data Link Layer

  25. client state server state LISTEN LISTEN choose init seq num, x send TCP SYN msg SYNSENT SYNbit=1, Seq=x choose init seq num, y send TCP SYNACK msg, acking SYN SYN RCVD SYNbit=1, Seq=y ACKbit=1; ACKnum=x+1 received SYNACK(x) indicates server is live; send ACK for SYNACK; this segment may contain client-to-server data ESTAB ACKbit=1, ACKnum=y+1 received ACK(y) indicates client is live TCP 3-way handshake ESTAB TransportLayer

  26. HTTP TCP IP Eth Phy HTTP TCP IP Eth Phy HTTP HTTP HTTP HTTP HTTP HTTP HTTP HTTP HTTP HTTP HTTP HTTP HTTP HTTP A day in the life… HTTP request/reply • web page finally (!!!) displayed • HTTP request sent into TCP socket • IP datagram containing HTTP request routed to www.google.com router (runs DHCP) • web server responds with HTTP reply (containing web page) web server • IP datagram containing HTTP reply routed back to client 64.233.169.105 Link Layer and LANs

  27. Analysis of Client Server model Application Layer

  28. u1 d1 u2 d2 File distribution: client-server Question: how much time to distribute file (size F) from one server to N peers? • peer upload/download capacity is limited resource us: server upload capacity di: peer i download capacity file, size F us server di uN network (with abundant bandwidth) ui dN ui: peer i upload capacity Application Layer

  29. File distribution time: client-server • server transmission: mustsequentially send (upload) N filecopies: • time to send one copy: F/us • time to send N copies: NF/us F us di network ui • client: each client must download file copy • dmin = min client download rate • min client download time: F/dmin time to distribute F to N clients using client-server approach Dc-s > max{NF/us,,F/dmin} increases linearly in N Application Layer

  30. P2P Architecture Application Layer

  31. Pure P2P architecture • no always-on server • arbitrary end systems directly communicate • peers are intermittently connected and change IP addresses examples: • file distribution (BitTorrent) • Streaming (KanKan) • VoIP (Skype) Application Layer

  32. File distribution time: P2P server transmission: mustupload at least onecopy time to send one copy: F/us F us di • client: each client must download file copy • min client download time: F/dmin network ui • clients: as aggregate must download NF bits • max upload rate (limting max download rate) is us + Sui time to distribute F to N clients using P2P approach DP2P > max{F/us,,F/dmin,,NF/(us + Sui)} increases linearly in N … … but so does this, as each peer brings service capacity Application Layer

  33. Client-server vs. P2P: example client upload rate = u, F/u = 1 hour, us = 10u, dmin ≥ us Application Layer

  34. P2P file distribution: BitTorrent • file divided into 256Kb chunks • peers in torrent send/receive file chunks torrent: group of peers exchanging chunks of a file tracker: tracks peers participating in torrent Alice arrives … … obtains list of peers from tracker … and begins exchanging file chunks with peers in torrent Application Layer

  35. peer joining torrent: has no chunks, but will accumulate them over time from other peers registers with tracker to get list of peers, connects to subset of peers (“neighbors”) P2P file distribution: BitTorrent • while downloading, peer uploads chunks to other peers • peer may change peers with whom it exchanges chunks • churn: peers may come and go • once peer has entire file, it may (selfishly) leave or (altruistically) remain in torrent Application Layer

  36. requesting chunks: at any given time, different peers have different subsets of file chunks periodically, Alice asks each peer for list of chunks that they have Alice requests missing chunks from peers, rarest first BitTorrent: requesting, sending file chunks sending chunks: tit-for-tat • Alice sends chunks to those four peers currently sending her chunks at highest rate • other peers are choked by Alice (do not receive chunks from her) • re-evaluate top 4 every10 secs • every 30 secs: randomly select another peer, starts sending chunks • “optimistically unchoke” this peer • newly chosen peer may join top 4 Application Layer

  37. BitTorrent: tit-for-tat (1) Alice “optimistically unchokes” Bob (2) Alice becomes one of Bob’s top-four providers; Bob reciprocates (3) Bob becomes one of Alice’s top-four providers higher upload rate: find better trading partners, get file faster ! Application Layer

  38. Distributed Hash Table (DHT) • Hash table • DHT paradigm • Circular DHT and overlay networks • Peer churn

  39. Simple Database Simple database with(key, value) pairs: • key: human name; value: social security # • key: movie title; value: IP address

  40. Hash Table • More convenient to store and search on numerical representation of key • key = hash(original key)

  41. Distributed Hash Table (DHT) • Distribute (key, value) pairs over millions of peers • pairs are evenly distributed over peers • Any peer can query database with a key • database returns value for the key • To resolve query, small number of messages exchanged among peers • Each peer only knows about a small number of other peers • Robust to peers coming and going (churn)

  42. Assign key-value pairs to peers • rule: assign key-value pair to the peer that has the closestID. • convention: closest is the immediate successor of the key. • e.g., ID space {0,1,2,3,…,63} • suppose 8 peers: 1,12,13,25,32,40,48,60 • If key = 51, then assigned to peer 60 • If key = 60, then assigned to peer 60 • If key = 61, then assigned to peer 1

  43. Circular DHT • each peer only aware of immediate successor and predecessor. 1 12 60 13 48 25 40 32 “overlay network”

  44. What is the valueassociated with key 53 ? value Resolving a query 1 12 60 13 48 25 O(N) messages on avgerage to resolve query, when there are N peers 40 32

  45. What is the value for key 53 Circular DHT with shortcuts value • each peer keeps track of IP addresses of predecessor, successor, short cuts. • reduced from 6 to 3 messages. • possible to design shortcuts with O(log N) neighbors, O(log N) messages in query 1 12 60 13 48 25 40 32

  46. Peer churn handling peer churn: • peers may come and go (churn) • each peer knows address of its two successors • each peer periodically pings its two successors to check aliveness • if immediate successor leaves, choose next successor as new immediate successor example: peer 5 abruptly leaves 1 3 15 4 12 5 10 8

  47. Excersizes Stop Application Layer

More Related