Chapter P2P file sharing network applications 2.22 Web and HTTP 2.3 FTP DNS

Transcription

1 Chapter 2 Application Layer A note on the use of these ppt slides: We re making these slides freely available to all (faculty, students, readers). They re in PowerPoint form so you can add, modify, and delete slides Computer Networking: (including this one) and slide content to suit your needs. They obviously A Top Down Approach represent a lot of work on our part. In return for use, we only ask the following: Featuring the Internet, If you use these slides (e.g., in a class) in substantially unaltered form, 3 rd edition. that you mention their source (after all, we d like people to use our book!) If you post any slides in substantially unaltered form on a www site, that Jim JmK Kurose,,Keith Ross you note that they are adapted from (or perhaps identical to) our slides, and note our copyright of this material. Thanks and enjoy! JFK/KWR Addison-Wesley, July Chapter 2: Application layer Principles i of 2.6 P2P file sharing network applications 2.22 Web and HTTP 2.3 FTP Electronic Mail SMTP, POP3, IMAP DNS All material copyright J.F Kurose and K.W. Ross, All Rights Reserved 2: Application Layer 1 2: Application Layer 2 Chapter 2: Application Layer Some network apps Our goals: conceptual, implementation aspects of network application protocols transport-layer service models client- paradigm peer-to-peer paradigm learn about protocols by examining popular application-level protocols HTTP FTP SMTP / POP3 / IMAP DNS programming network applications socket API Internet telephone Web Real-time video Instant messaging conference Remote login Massive parallel P2P file sharing computing Multi- network games Streaming stored video clips 2: Application Layer 3 2: Application Layer 4

2 Creating a network app Application architectures Write programs that run on different end systems and communicate over a network. e.g., Web: Web software communicates with browser software No software written for devices in network core Network core devices do not function at app layer This design allows for rapid app development application transport network data link physical application transport network data link physical application transport network data link physical Client- Peer-to-peer (P2P) Hybrid of client- and P2P 2: Application Layer 5 2: Application Layer 6 Client- architecture : always-on host permanent IP address farms for scaling clients: communicate with may be intermittently connected may have dynamic IP addresses do not communicate directly with each other Pure P2P architecture no always on arbitrary end systems directly communicate peers are intermittently connected and change IP addresses example: Gnutella Highly scalable But difficult to manage 2: Application Layer 7 2: Application Layer 8

3 Hybrid of client- and P2P Napster File transfer P2P File search centralized: Peers register content at central Peers query same central to locate content Instant messaging Chatting between two s is P2P Presence detection/location centralized: User registers its IP address with central when it comes online User contacts central to find IP addresses of buddies Processes communicating Process: program running Client process: process within a host. that initiates communication within same host, two processes communicate Server process: process using inter-process that waits to be communication (defined contacted by OS). processes in different Note: applications with hosts communicate by P2P architectures have exchanging messages client processes s & processes 2: Application Layer 9 2: Application Layer 10 Sockets host or process sends/receives d/ messages to/from its socket controlled by app developer socket analogous to door process sending process shoves socket message out door TCP with buffers, Internet sending process relies on variables transport t infrastructure t on other side of door which controlled brings message to socket by OS at receiving process API: (1) choice of transport protocol; (2) ability to fix a few parameters (lots more on this later) host or process socket TCP with buffers, variables 2: Application Layer 11 Addressing processes For a process to receive messages, it must have an identifier A host has a unique32- bit IP address Q: does the IP address of the host on which the process runs suffice for identifying the process? Answer: No, many processes can be running on same host Identifier includes both the IP address and port numbers associated with the process on the host. Example port numbers: HTTP : 80 Mail : 25 More on this later 2: Application Layer 12

4 App-layer protocol defines What transport service does an app need? Types of messages Public-domain i protocols: exchanged, eg, request defined in RFCs & response messages allows for Syntax of message interoperability types: what fields in eg, HTTP, SMTP messages & how fields are delineated Proprietary protocols: Semantics of the eg, KaZaA fields, ie, meaning of information in fields Rules for when and how processes send & respond to messages 2: Application Layer 13 Data loss some apps (e.g., audio) can tolerate some loss other apps (e.g., file transfer, telnet) require 100% reliable data transfer Timing some apps (e.g., Internet telephony, interactive games) require low delay to be effective Bandwidth some apps (e.g., multimedia) m require r minimum amount of bandwidth to be effective other apps ( elastic apps ) make use of whatever bandwidth they get 2: Application Layer 14 Transport service requirements of common apps Internet transport protocols services Application file transfer Web documents real-time audio/video stored audio/video interactive ti games instant messaging Data loss no loss no loss no loss loss-tolerant l t loss-tolerant loss-tolerant no loss Bandwidth Time Sensitive elastic no elastic no elastic no audio: 5kbps-1Mbps yes, 100 s msec video:10kbps-5mbps same as above yes, few secs few kbps up yes, 100 s msec elastic yes and no TCP service: UDP service: connection-oriented: setup unreliable data transfer required between client and between sending and processes receiving process reliable transport between does not provide: sending and receiving i process connection setup, flow control: sender won t reliability, flow control, overwhelm receiver congestion control, timing, or bandwidth guarantee congestion control: throttle sender when network overloaded Q: why bother? Why is does not provide: timing, there a UDP? minimum bandwidth guarantees 2: Application Layer 15 2: Application Layer 16

5 Internet apps: application, transport protocols Web and HTTP Application remote terminal access Web file transfer streaming multimedia Internet telephony Application layer protocol SMTP [RFC 2821] Telnet [RFC 854] HTTP [RFC 2616] FTP [RFC 959] proprietary (e.g. RealNetworks) proprietary (e.g., Dialpad) Underlying transport protocol TCP TCP TCP TCP TCP or UDP typically UDP First some jargon Web page consists of objects Object can be HTML file, JPEG image, Java applet, audio file, Web page consists of base HTML-file which h includes several referenced objects Each object is addressable by a URL Example URL: / if host name path name 2: Application Layer 17 2: Application Layer 18 HTTP overview HTTP overview (continued) HTTP: hypertext transfer protocol Web s application layer PC running protocol Explorer client/ model client: browser that requests, receives, displays Web objects : Web sends objects in response to requests Mac running HTTP 1.0: RFC 1945 Navigator HTTP 1.1: 1: RFC 2068 Server running Apache Web Uses TCP: HTTP is stateless t client initiates TCP maintains no connection (creates socket) information about to, port 80 past client requests accepts TCP connection from client aside Protocols that maintain HTTP messages (applicationlayer protocol messages) past history (state) must state are complex! exchanged between browser be maintained (HTTP client) and Web if /client crashes, (HTTP ) their views of state may TCP connection closed be inconsistent, must be reconciled 2: Application Layer 19 2: Application Layer 20

6 HTTP connections Nonpersistent HTTP Persistent HTTP At most one object is Multiple objects can sent over a TCP be sent over single connection. TCP connection HTTP/1.0 uses between client and nonpersistent HTTP. HTTP/1.1 uses persistent connections in default mode 2: Application Layer 21 Nonpersistent stent HTTP Suppose enters URL edu/somedepartment/home time 1a. HTTP client initiates TCP connection to HTTP (process) at on port HTTP client sends HTTP request message (containing URL) into TCP connection socket. Message indicates that client wants object somedepartment/home.index (contains text, references to 10 jpeg images) 1b. HTTP at host waiting for TCP connection at port 80. accepts connection, notifying client 3. HTTP receives request message, forms response message containing requested object, and sends message into its socket 2: Application Layer 22 Nonpersistent stent HTTP (cont.) Response time modeling time 5. HTTP client receives response message containing html file, displays html. Parsing html file, finds 10 referenced jpeg objects 6. Steps 1-5 repeated for each of 10 jpeg objects 4. HTTP closes TCP connection. 2: Application Layer 23 Definition of RRT: time to send a small packet to travel from client to and back. Response time: one RTT to initiate TCP connection one RTT for HTTP request and first few bytes of HTTP response to return file transmission time total = 2RTT+transmit time initiate TCP connection RTT request file RTT file received time time to transmit file time 2: Application Layer 24

7 Persistent HTTP Nonpersistent HTTP issues: requires 2 RTTs per object OS must work and allocate host resources for each TCP connection but browsers often open parallel TCP connections to fetch referenced objects Persistent HTTP leaves connection open after sending response subsequent HTTP messages between same client/ are sent over connection Persistent without pipelining: pp client issues new request only when previous response has been received one RTT for each referenced object Persistent with pipelining: default in HTTP/1.1 client sends requests as soon as it encounters a referenced object as little as one RTT for all the referenced objects 2: Application Layer 25 HTTP request message two types of HTTP messages: request, response HTTP request message: ASCII (human-readable format) request line (GET, POST, HEAD commands) header lines Carriage return, line feed indicates end of message GET /somedir/page.html HTTP/1.1 Host: User-: Mozilla/4.0 Connection: close Accept-language:fr (extra carriage return, line feed) 2: Application Layer 26 HTTP request message: general format Uploading form input Post method: Web page often includes form input URL method: Input is uploaded to Uses GET method in entity body Input is uploaded d in URL field of request line: 2: Application Layer 27 2: Application Layer 28

8 Method types HTTP response message HTTP/1.0 HTTP/1.11 GET GET, POST, HEAD POST HEAD asks to leave requested object out of response PUT uploads file in entity body to path specified in URL field DELETE deletes file specified in the URL field status line (protocol status code status phrase) data, e.g., requested HTML file header lines HTTP/ OK Connection close Date: Thu, 06 Aug :00:15 GMT Server: Apache/1.3.0 (Unix) Last-Modified: Mon, 22 Jun Content-Length: 6821 Content-Type: text/html data data data data data... 2: Application Layer 29 2: Application Layer 30 HTTP response status codes In first line in ->client response message. A few sample codes: 200 OK request succeeded, requested object later in this message 301 Moved Permanently requested object moved, new location specified later in this message (Location:) 400 Bad Request request message not understood by 404 Not Found requested document not found on this 505 HTTP Version Not Supported 2: Application Layer 31 Trying out HTTP (client side) for yourself 1. Telnet to your favorite Web : telnet cis.poly.edu Type in a GET HTTP request: GET /~ross/ HTTP/1.1 Host: cis.poly.edu Opens TCP connection to port 80 (default HTTP port) at cis.poly.edu. Anything typed in sent to port 80 at cis.poly.edu By typing this in (hit carriage return twice), you send this minimal (but complete) GET request to HTTP 3. Look at response message sent by HTTP! 2: Application Layer 32

9 User- state: cookies Cookies: keeping state (cont.) Many major Web sites Example: use cookies Susan access Internet Four components: always from same PC She visits a specific e- 1) cookie header line in commerce site for first the HTTP response time message When initial HTTP 2) cookie header line in requests arrives at site, HTTP request message site creates a unique ID 3) cookie file kept on and creates an entry in s host and managed backend database for by s browser ID 4) back-end database at Web site Cookie file ebay: 8734 Cookie file amazon: 1678 ebay: 8734 one week later: Cookie file amazon: 1678 ebay: 8734 client usual http request msg usual http response + Set-cookie: 1678 usual http request msg cookie: 1678 usual http response msg usual http request msg cookie: 1678 usual http response msg creates ID 1678 for cookiespecific action cookiespectific action 2: Application Layer 33 2: Application Layer 34 Cookies (continued) What cookies can bring: authorization shopping carts recommendations session state (Web ) aside Cookies and privacy: cookies permit sites to learn a lot about you you may supply name and to sites search engines use redirection & cookies to learn yet more advertising companies obtain info across sites Web caches (proxy ) Goal: satisfy client request without involving origin sets browser: Web accesses via cache browser sends all HTTP requests to cache object in cache: cache returns object else cache requests object from origin, then returns object to client client client Proxy origin origin 2: Application Layer 35 2: Application Layer 36

10 More about Web caching Cache acts as both client Why Web caching? and Reduce response time for Typically y cache is installed client request. by ISP (university, Reduce traffic on an company, residential ISP) institution s access link. Internet dense with caches enables poor content providers to effectively deliver content (but so does P2P file sharing) 2: Application Layer 37 Caching example Assumptions average object size = 100,000 bits avg. request rate from institution s browsers to origin s = 15/sec delay from institutional router to any origin and back to router = 2 sec Consequences utilization on LAN = 15% utilization on access link = 100% total delay = Internet delay + access delay + LAN delay = 2 sec + minutes + milliseconds institutional network public Internet Mbps access link 10 Mbps LAN origin s institutional cache 2: Application Layer 38 Caching example (cont) Possible solution increase bandwidth of access link to, say, 10 Mbps Consequences nc s utilization on LAN = 15% utilization on access link = 15% Total delay = Internet delay + access delay + LAN delay = 2 sec + msecs + msecs often a costly upgrade institutional network public Internet 10 Mbps access link 10 Mbps LAN origin s institutional cache Caching example (cont) Install cache suppose hit rate is.4 Consequence 40% requests will be satisfied almost immediately 60% requests satisfied by origin utilization of access link reduced to 60%, resulting in negligible ibl delays (say 10 msec) total avg delay = Internet delay + access delay + LAN delay =.6*(2.01) secs + milliseconds < 1.4 secs institutional network public Internet Mbps access link 10 Mbps LAN origin s institutional cache 2: Application Layer 39 2: Application Layer 40

11 Conditional GET Goal: don t send object if cache cache has up-to-date cached HTTP request msg version If-modified-since: <date> object cache: specify date of not cached copy in HTTP request modified If-modified-since: <date> : response contains no object if cached copy is upto-date: HTTP/ Not Modified HTTP response HTTP/ Not Modified HTTP request msg If-modified-since: <date> HTTP response HTTP/ OK <data> object modified 2: Application Layer 41 FTP: the file transfer protocol at host FTP interface FTP client local file system file transfer FTP remote file system transfer file to/from remote host client/ model client: side that initiates transfer (either to/from remote) : remote host ftp: RFC 959 ftp : port 21 2: Application Layer 42 FTP: separate control, data connections FTP commands, responses FTP client contacts t FTP at port 21, specifying TCP as transport protocol Client obtains authorization over control connection Client browses remote directory by sending commands over control connection. When receives a command for a file transfer, the opens a TCP data connection to client After transferring one file, closes connection. FTP client TCP control connection port 21 TCP data connection port 20 FTP Server opens a second TCP data connection to transfer another file. Control connection: out of band FTP maintains state : current directory, earlier authentication 2: Application Layer 43 Sample commands: Sample return codes sent as ASCII text over status code and phrase (as control channel in HTTP) USER name 331 Username OK, PASS password password required LIST return list of file in current directory RETR filename retrieves (gets) file STOR filename stores (puts) file onto remote host 125 data connection already open; transfer starting 425 Can t open data connection 452 Error writing file 2: Application Layer 44

12 Electronic Mail Three major components: s mail s simple mail transfer protocol: SMTP User Agent aka a.k.a. mail reader composing, editing, reading mail messages e.g., Eudora, Outlook, elm, Netscape Messenger outgoing, incoming messages stored on mail r SMTP mail SMTP SMTP outgoing g message queue mail mailbox 2: Application Layer 45 Electronic Mail: mail s Mail Servers mailbox contains incoming messages for message queue of outgoing (to be sent) mail messages SMTP protocol between mail s to send messages client: sending mail : receiving i mail mail SMTP mail SMTP SMTP mail 2: Application Layer 46 Electronic Mail: SMTP [RFC 2821] uses TCP to reliably transfer message from client to, port 25 direct transfer: sending to receiving three phases of transfer handshaking (greeting) transfer of messages closure command/response interaction commands: ASCII text response: status code and phrase messages must be in 7-bit ASCII Scenario: Alice sends message to Bob 1) Alice uses UA to compose message and to bob@someschool.edu 2) Alice s UA sends message to her mail ; message placed in message queue 3) Client side of SMTP opens TCP connection with Bob s mail 1 mail ) SMTP client sends Alice s message over the TCP connection 5) Bob s mail places the message in Bobs b s mailbox 6) Bob invokes his to read message mail 5 6 2: Application Layer 47 2: Application Layer 48

13 Sample SMTP interaction S: 220 hamburger.edu C: HELO crepes.fr S: 250 Hello crepes.fr, pleased to meet you C: MAIL FROM: S: 250 Sender ok C: RCPT TO: S: 250 Recipient ok C: DATA S: 354 Enter mail, end with "." on a line by itself C: Do you like ketchup? C: How about pickles? C:. S: 250 Message accepted for delivery C: QUIT S: 221 hamburger.edu closing connection Try SMTP interaction for yourself: telnet name 25 see 220 reply from enter HELO, MAIL FROM, RCPT TO, DATA, QUIT commands above lets you send without using client (reader) 2: Application Layer 49 2: Application Layer 50 SMTP: final words Mail message format SMTP uses persistent t Comparison with HTTP: connections HTTP: pull SMTP requires message (header & body) to be in 7- SMTP: push bit ASCII both have ASCII SMTP uses command/response CRLF.CRLF to determine interaction, status codes end of message HTTP: each object encapsulated in its own response msg SMTP: multiple objects sent in multipart msg SMTP: protocol for exchanging msgs RFC 822: standard for text message format: header lines, e.g., To: From: Subject: different from SMTP commands! body the message, ASCII characters only header body blank line 2: Application Layer 51 2: Application Layer 52

14 Message format: multimedia extensions MIME: multimedia mail extension, RFC 2045, 2056 additional lines in msg header declare MIME content type MIME version method used to encode data multimedia data type, subtype, parameter declaration From: To: Subject: Picture of yummy crepe. MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Type: image/jpeg base64 encoded data... parameter declaration......base64 encoded data encoded data 2: Application Layer 53 Mail access protocols SMTP SMTP access protocol sender s mail receiver s mail SMTP: delivery/storage to receiver s Mail access protocol: retrieval from POP: Post Office Protocol [RFC 1939] authorization ( <-->) and download IMAP: Internet Mail Access Protocol [RFC 1730] more features (more complex) manipulation of stored msgs on HTTP: Hotmail, Yahoo! Mail, etc. 2: Application Layer 54 POP3 protocol authorization phase client commands: : declare name pass: password responses +OK -ERR transaction phase, client: list: list message numbers retr: retrieve eve message by number dele: delete quit S: +OK POP3 ready C: bob S: +OK C: pass hungry S: +OK successfully logged on C: list S: S: S:. C: retr 1 S: <message 1 contents> S:. C: dele 1 C: retr 2 S: <message 1 contents> S:. C: dele 2 C: quit S: +OK POP3 signing off 2: Application Layer 55 POP3 (more) and IMAP More about POP3 Previous example uses download and delete mode. Bob cannot re-read e- mail if he changes client Download-and-keep : d copies of messages on different clients POP3 is stateless across sessions IMAP Keep all messages in one place: the Allows to organize messages in folders IMAP keeps state across sessions: names of folders and mappings between message IDs and folder name 2: Application Layer 56

15 DNS: Domain Name System People: many identifiers: ifi Domain Name System: SSN, name, passport # distributed database Internet t hosts, routers: implemented in hierarchy of many name s IP address (32 bit) - application-layer protocol used for addressing host, routers, name s to datagrams communicate to resolve names name, e.g., (address/name translation) ww.yahoo.com - used by note: core Internet humans function, implemented as Q: map between IP application-layer layer protocol addresses and name? complexity at network s edge DNS DNS services Hostname to IP address translation Host aliasing Canonical and alias names Mail aliasing Load distribution Replicated Web s: set of IP addresses for one canonical name Why not centralize DNS? single point of failure traffic volume distant centralized database maintenance doesn t scale! 2: Application Layer 57 2: Application Layer 58 Distributed, Hierarchical Database Root DNS Servers com DNS s org DNS s edu DNS s yahoo.com DNS s amazon.com DNS s pbs.org DNS s poly.edu umass.edu DNS sdns s Client wants IP for 1 st approx: Client queries a root to find com DNS Client queries com DNS to get amazon.com DNS Client queries amazon.com DNS to get IP address for m 2: Application Layer 59 DNS: Root name s contacted by local name that can not resolve name root name : contacts authoritative name if name mapping not known gets mapping returns mapping to local name e NASA Mt View, CA f Internet Software C. Palo Alto, CA (and 17 other locations) b USC-ISI Marina del Rey, CA l ICANN Los Angeles, CA a Verisign, Dulles, VA c Cogent, Herndon, VA (also Los Angeles) d U Maryland College Park, MD g US DoD Vienna, VA h ARL Aberdeen, MD j Verisign, ( 11 locations) o k RIPE London (also Amsterdam, i Autonomica, Frankfurt) Stockholm (plus 3 other locations) m WIDE Tokyo 13 root name s worldwide 2: Application Layer 60

16 TLD and Authoritative Servers Top-level l domain (TLD) s: responsible for com, org, net, edu, etc, and all top-level country domains uk, fr, ca, jp. Network solutions maintains s for com TLD Educause for edu TLD Authoritative DNS s: organization s DNS s, providing authoritative hostname to IP mappings for organization s s rs (e.g., Web and mail). Can be maintained by organization or service provider Local Name Server Does not strictly belong to hierarchy h Each ISP (residential ISP, company, university) has one. Also called default name When a host makes a DNS query, query is sent to its local DNS Acts as a proxy, forwards query into hierarchy. 2: Application Layer 61 2: Application Layer 62 Example root DNS Recursive queries root DNS Host at cis.poly.edu 3 wants IP address for gaia.cs.umass.edu 2 local DNS dns.poly.edu 1 8 requesting host cis.poly.edu TLD DNS 6 authoritative DNS dns.cs.umass.edu gaia.cs.umass.edu recursive query: puts burden of name resolution on contacted name heavy load? iterated query: 2 7 local DNS dns.poly.edu contacted 1 replies with name of to contact I don t know this name, but ask this 8 requesting host cis.poly.edu 3 6 TLD DNS serve 5 4 authoritative DNS dns.cs.umass.edu gaia.cs.umass.edu 2: Application Layer 63 2: Application Layer 64

17 DNS: caching and updating records once (any) name learns mapping, it caches mapping cache entries timeout (disappear) after some time TLD s typically y cached in local name s Thus root name s not often visited update/notify mechanisms under design by IETF RFC tf /ht h t si d h t l DNS records DNS: distributed db storing resource records (RR) Type=A RR format: (name, value, type, ttl) name is hostname value is IP address Type=NS name is domain (e.g. foo.com) value is IP address of authoritative name for this domain Type=CNAME name is alias name for some cannonical (the real) name is really east.backup2.ibm.com value is cannonical name Type=MX value is name of mail associated with name 2: Application Layer 65 2: Application Layer 66 DNS protocol, messages DNS protocol : query and reply pymessages, both with same message format msg header identification: 16 bit # for query, reply to query uses same # flags: query or reply recursion desired recursion available reply is authoritative DNS protocol, messages Name, type fields for a query RRs in reponse to query records for authoritative s additional helpful info that may be used 2: Application Layer 67 2: Application Layer 68

18 Inserting records into DNS Example: just created startup Network Utopia Register name networkuptopia.com at a registrar (e.g., g, Network Solutions) Need to provide registrar with names and IP addresses of your authoritative name (primary and secondary) Registrar inserts two RRs into the com TLD : (networkutopia.com, dns1.networkutopia.com, NS) (dns1.networkutopia.com, , A) Put in authoritative Type A record for w p. and Type MX record for networkutopia.com How do people get the IP address of your Web site? 2: Application Layer 69 P2P file sharing Example Alice runs P2P client application on her notebook computer Intermittently connects to Internet; gets new IP address for each connection Asks for Hey Jude Application displays other peers that have copy of Hey Jude. Alice chooses one of the peers, Bob. File is copied from Bob s PC to Alice s notebook: HTTP While Alice downloads, oa other s uploading from Alice. Alice s peer is both a Web client and a transient t Web. All peers are s = highly scalable! 2: Application Layer 70 P2P: centralized directory P2P: problems with centralized directory original i Napster design 1) when peer connects, it informs central : IP address content 2) Alice queries for Hey Jude 3) Alice requests file from Bob centralized directory Bob peers Single point of failure file transfer is Performance decentralized, but bottleneck locating content is Copyright highly decentralized infringement Alice 2: Application Layer 71 2: Application Layer 72

19 Query flooding: Gnutella fully distributed ib t d overlay network: graph no central edge between peer X public domain protocol and Y if there s a TCP many Gnutella clients connection implementing protocol all active peers and edges is overlay net Edge is not a physical link Given peer will typically be connected with < 10 overlay neighbors 2: Application Layer 73 Gnutella: protocol Query message sent over existing TCP connections peers forward Query message QueryHit sent over reverse path Scalability: limited scope flooding Query QueryHit File transfer: HTTP Query QueryHit 2: Application Layer 74 Gnutella: Peer joining Exploiting heterogeneity: KaZaA 1. Joining i peer X must find some other peer in Gnutella network: use list of candidate peers 2. X sequentially attempts ts to make TCP with peers on list until connection setup with Y 3. X sends Ping message to Y; Y forwards Ping message. 4. All peers receiving Ping message respond with Pong message 5. X receives many Pong messages. It can then setup additional TCP connections Peer leaving: see homework problem! Each peer is either a group leader or assigned to a group leader. TCP connection between peer and its group leader. TCP connections between some pairs of group leaders. Group leader tracks the content in all its ordinary peer children. group-leader peer neighoring relationships in overlay network 2: Application Layer 75 2: Application Layer 76

20 KaZaA: Querying Each file has a hash h and a descriptor Client sends keyword query to its group leader Group leader responds with matches: For each match: metadata, hash, IP address If group leader forwards query to other group leaders, they respond with matches Client then selects files for downloading HTTP requests using hash as identifier sent to peers holding desired file Kazaa tricks Limitations on simultaneous uploads Request queuing Incentive priorities Parallel downloading 2: Application Layer 77 2: Application Layer 78 Chapter 2: Summary Our study of network apps now complete! Application architectures client- P2P hybrid application service requirements: reliability, bandwidth, delay Internet transport service model connection-oriented, reliable: TCP unreliable, datagrams: UDP specific protocols: HTTP FTP SMTP, POP, IMAP DNS socket programming 2: Application Layer 79 Chapter 2: Summary Most importantly: learned about protocols typical request/reply message exchange: client requests info or service responds with data, status code message formats: headers: fields giving info about data data: info being communicated cated control vs. data msgs in-band, out-of-band centralized vs. decentralized stateless vs. stateful reliable vs. unreliable msg transfer complexity at network edge 2: Application Layer 80