chapter 2 application layer
play

Chapter 2 Application Layer - PowerPoint PPT Presentation

Chapter 2 Application Layer


  1. Transport service requirements of common apps �������������� ����������� ��������� ���������� �� ������������� ������� ������� �� �-���� ������� ������� �� ������������� ������� ������� �����*//������� �����*//������� ����-����������(����� ����-����������(����� ����-�������� ����-�������� �������0����-*1��� �������0����-*1��� ������*/����-01��� �������!����� ������������(����� ����-�������� �������������� �����*//������� ����������������� ����-�������� ��!�������� ���������� ����������������� ������� ������� 2: Application Layer ��

  2. Internet transport protocols services UDP service: TCP service: � unreliable data transfer � connection#oriented: setup between sending and required between client and receiving process server processes � does not provide: � reliable transport between connection setup, connection setup, sending and receiving process sending and receiving process reliability, flow control, � flow control: sender won’t congestion control, timing, overwhelm receiver throughput guarantee, or � congestion control: throttle security sender when network overloaded Q: why bother? Why is � does not provide: timing, there a UDP? minimum throughput guarantees, security 2: Application Layer ��

  3. Internet apps: application, transport protocols ����������� ���������� �������������� ����������� ������������������ 21� �3)&4�.5.*6 �-���� �4 �������3)&4�5076 ���������������������� �4 8�� �3)&4�.,*,6 ���� �4 &� �3)&4�+0+6 &� �3)&4�+0+6 ������������� ������������� �4 �4 8�� �����9��������� �������������������� �4 ����:; )� �3)&4�*55+6 2" ��)� ������������� "����������������� �������2����� ����������:; 2: Application Layer ��

  4. Chapter 2: Application layer � 2.1 Principles of � 2.6 P2P applications network applications � 2.7 Socket programming � app architectures with TCP � app requirements � 2.8 Socket programming � 2.2 Web and HTTP � 2.2 Web and HTTP with UDP with UDP � 2.4 Electronic Mail � SMTP, POP3, IMAP � 2.5 DNS 2: Application Layer ��

  5. Web and HTTP 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 � Web page consists of base HTML#file which includes several referenced objects � Each object is addressable by a URL � Example URL: ����������������������������������� path name host name 2: Application Layer ��

  6. HTTP overview HTTP: hypertext transfer protocol � Web’s application layer PC running protocol Explorer � client/server model � client: browser that requests, receives, Server “displays” Web objects running Apache Web � server: Web server server sends objects in response to requests Mac running Navigator 2: Application Layer ��

  7. HTTP overview (continued) HTTP is “stateless” Uses TCP: � server maintains no � client initiates TCP information about connection (creates socket) past client requests to server, port 80 � server accepts TCP Protocols that maintain aside aside connection from client connection from client Protocols that maintain � HTTP messages (application# “state” are complex! layer protocol messages) � past history (state) must exchanged between browser be maintained (HTTP client) and Web � if server/client crashes, server (HTTP server) their views of “state” may � TCP connection closed be inconsistent, must be reconciled 2: Application Layer ��

  8. 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 between client and between client and server. 2: Application Layer ��

  9. Nonpersistent HTTP ������������<��� Suppose user enters URL ��������������*/� �������������������������������������������� $����������� 1a . HTTP client initiates TCP connection to HTTP server 1b. HTTP server at host (process) at !!!�����2���������� waiting !!!�����2������������������ 80 for TCP connection at port 80. for TCP connection at port 80. “accepts” connection, notifying “accepts” connection, notifying client 2. HTTP client sends HTTP request message (containing 3. HTTP server receives request URL) into TCP connection socket. Message indicates message, forms response that client wants object message containing requested object, and sends message ����;���������(���������< into its socket time 2: Application Layer ��

  10. Nonpersistent HTTP (cont.) 4. HTTP server closes TCP connection. 5 . HTTP client receives response message containing html file, displays html. Parsing html file, finds 10 referenced jpeg objects objects time time 6. Steps 1#5 repeated for each of 10 jpeg objects 2: Application Layer ��

  11. Non#Persistent HTTP: Response time Definition of RTT: time for a small packet to travel from client to server and back. initiate TCP connection Response time: RTT � one RTT to initiate TCP � one RTT to initiate TCP request request file connection time to RTT transmit � one RTT for HTTP file request and first few file received bytes of HTTP response to return � '� � '� � file transmission time total = 2RTT+transmit time 2: Application Layer ��

  12. Persistent HTTP Nonpersistent HTTP issues: Persistent HTTP � requires 2 RTTs per object � server leaves connection open after sending � OS overhead for each TCP response connection � subsequent HTTP messages � browsers often open parallel between same between same TCP connections to fetch TCP connections to fetch client/server sent over client/server sent over referenced objects open connection � client sends requests as soon as it encounters a referenced object � as little as one RTT for all the referenced objects 2: Application Layer ��

  13. HTTP request message � two types of HTTP messages: request , response � HTTP request message: � ASCII (human#readable format) request line request line (GET, POST, (GET, POST, ������������������������������� HEAD commands) ������������������������� �������������������� �! header "����������������� lines #���������������$�� Carriage return, ��<������������������������������� line feed indicates end of message 2: Application Layer ��

  14. HTTP request message: general format 2: Application Layer ��

  15. Uploading form input Post method: � Web page often URL method: includes form input � Uses GET method � Input is uploaded to server in entity body server in entity body � Input is uploaded in � Input is uploaded in URL field of request line: �������������������������������������������� 2: Application Layer ��

  16. Method types HTTP/1.0 HTTP/1.1 � GET � GET, POST, HEAD � POST � PUT � uploads file in entity � HEAD body to path specified body to path specified � asks server to leave asks server to leave in URL field requested object out of � DELETE response � deletes file specified in the URL field 2: Application Layer ��

  17. HTTP response message status line (protocol status code ���������%!!�&'� status phrase) "��������������� (��������)�!*�#����++,��%�!!��-����� .��/����#��������0�!�1���23� header 4��������$��������)�%%�5����++,�6���� 4��������$��������)�%%�5����++,�6���� lines lines "�������4�������*,%�� "��������7������2������ data, e.g., ����������������������������� requested HTML file 2: Application Layer ��

  18. HTTP response status codes In first line in server#>client response message. A few sample codes: %!!�&' � request succeeded, requested object later in this message 0!����/�������������7 0!����/�������������7 � requested object moved, new location specified later in this message (Location:) !!�8���9�:���� � request message not understood by server ! �;���<���� � requested document not found on this server -!-������=�������;���.�������� 2: Application Layer ��

  19. Trying out HTTP (client side) for yourself 1. Telnet to your favorite Web server: Opens TCP connection to port 80 ��������������7�����,! (default HTTP server port) at cis.poly.edu. Anything typed in sent to port 80 at cis.poly.edu 2. Type in a GET HTTP request: By typing this in (hit carriage �����>�������������� return twice), you send �������������7���� this minimal (but complete) GET request to HTTP server 3. Look at response message sent by HTTP server! 2: Application Layer ��

  20. User#server state: cookies Example: Many major Web sites � Susan always access use cookies Internet always from PC Four components: � visits specific e# 1) cookie header line of HTTP response message commerce site for first 2) cookie header line in 2) cookie header line in time time HTTP request message � when initial HTTP 3) cookie file kept on requests arrives at site, user’s host, managed by user’s browser site creates: 4) back#end database at � unique ID Web site � entry in backend database for ID 2: Application Layer ��

  21. Cookies: keeping “state” (cont.) client server ��������� usual http request msg Amazon server creates ID cookie file usual http response 1678 for user create .������?�����*@,� entry ��������� �������� �� �������� �� usual http request msg cookie# access ���?�����*@, specific backend usual http response msg one week later: action database access usual http request msg ��������� cookie# �������� �� ���?�����*@, spectific usual http response msg action 2: Application Layer ��

  22. Cookies (continued) aside Cookies and privacy: What cookies can bring: � cookies permit sites to � authorization learn a lot about you � shopping carts � you may supply name � recommendations and e#mail to sites and e#mail to sites � user session state � user session state (Web e#mail) How to keep “state”: � protocol endpoints: maintain state at sender/receiver over multiple transactions � cookies: http messages carry state 2: Application Layer ��

  23. Web caches (proxy server) Goal: satisfy client request without involving origin server � user sets browser: origin server Web accesses via cache Proxy server server � browser sends all � browser sends all client client HTTP requests to cache � object in cache: cache returns object � else cache requests object from origin client origin server, then returns server object to client 2: Application Layer ��

  24. More about Web caching � cache acts as both Why Web caching? client and server � reduce response time � typically cache is for client request installed by ISP � reduce traffic on an (university, company, (university, company, institution’s access institution’s access residential ISP) link. � Internet dense with caches: enables “poor” content providers to effectively deliver content (but so does P2P file sharing) 2: Application Layer ��

  25. Caching example origin Assumptions servers � average object size = 100,000 public bits Internet � avg. request rate from institution’s browsers to origin servers = 15/sec servers = 15/sec 1.5 Mbps 1.5 Mbps � delay from institutional router access link to any origin server and back institutional to router = 2 sec network 10 Mbps LAN Consequences � utilization on LAN = 15% � utilization on access link = 100% institutional � total delay = Internet delay + cache access delay + LAN delay = 2 sec + minutes + milliseconds 2: Application Layer ��

  26. Caching example (cont) origin possible solution servers � increase bandwidth of access public link to, say, 10 Mbps Internet consequence � utilization on LAN = 15% � utilization on access link = 15% � utilization on access link = 15% 10 Mbps 10 Mbps � Total delay = Internet delay + access link access delay + LAN delay institutional = 2 sec + msecs + msecs network 10 Mbps LAN � often a costly upgrade institutional cache 2: Application Layer ��

  27. Caching example (cont) origin possible solution: install servers cache public � suppose hit rate is 0.4 Internet consequence � 40% requests will be satisfied almost immediately satisfied almost immediately 1.5 Mbps 1.5 Mbps � 60% requests satisfied by 60% requests satisfied by access link origin server � utilization of access link institutional reduced to 60%, resulting in network 10 Mbps LAN negligible delays (say 10 msec) � total avg delay = Internet delay + access delay + LAN institutional delay = .6*(2.01) secs + cache .4*milliseconds < 1.4 secs 2: Application Layer ��

  28. Conditional GET server cache � Goal: don’t send object if cache has up#to#date cached HTTP request msg version A$�����$����������� object � cache: specify date of B����C not cached copy in HTTP request modified HTTP response A$�����$����������� A$�����$����������� �������!� B����C 0! �;�������$��� � server: response contains no object if cached copy is up# HTTP request msg to#date: A$�����$����������� object �������!�0! �;��� B����C modified ����$��� HTTP response �������!�%!!�&' B����C 2: Application Layer ��

  29. Chapter 2: Application layer � 2.1 Principles of � 2.6 P2P applications network applications � 2.7 Socket programming � 2.2 Web and HTTP with TCP � 2.3 FTP � 2.8 Socket programming with UDP with UDP � 2.4 Electronic Mail � 2.4 Electronic Mail � 2.9 Building a Web � SMTP, POP3, IMAP server � 2.5 DNS 2: Application Layer ��

  30. FTP: the file transfer protocol file transfer FTP FTP FTP user client server interface user remote file at host local file system system system � transfer file to/from remote host � client/server model � client: side that initiates transfer (either to/from remote) � server: remote host � ftp: RFC 959 � ftp server: port 21 2: Application Layer ��

  31. FTP: separate control, data connections TCP control connection � FTP client contacts FTP server port 21 at port 21, TCP is transport protocol TCP data connection FTP FTP � client authorized over control port 20 client server connection � client browses remote � client browses remote � server opens another TCP directory by sending commands data connection to transfer over control connection. another file. � when server receives file � control connection: “out of transfer command, server band” opens 2 nd TCP connection (for � FTP server maintains “state”: file) to client current directory, earlier � after transferring one file, authentication server closes data connection. 2: Application Layer ��

  32. FTP commands, responses Sample commands: Sample return codes � sent as ASCII text over � status code and phrase (as control channel in HTTP) � �.�9� �������� � 00�����������&')� �����������:����� � �#..� �������� � �%-����������������� �%-����������������� � 4A.� return list of file in ������7�����D� current directory �����$����������� � 9��9�$������� retrieves � %-�"��E������������ (gets) file ���������� � .�&9�$������� stores � -%��������������� (puts) file onto remote $��� host 2: Application Layer ��

  33. Chapter 2: Application layer � 2.1 Principles of � 2.6 P2P applications network applications � 2.7 Socket programming � 2.2 Web and HTTP with TCP � 2.3 FTP � 2.8 Socket programming with UDP with UDP � 2.4 Electronic Mail � 2.4 Electronic Mail � SMTP, POP3, IMAP � 2.5 DNS 2: Application Layer ��

  34. Electronic Mail outgoing message queue user mailbox user Three major components: agent � user agents mail user server � mail servers agent SMTP � simple mail transfer mail protocol: SMTP server server user user SMTP SMTP agent User Agent SMTP � a.k.a. “mail reader” user mail � composing, editing, reading agent server mail messages � e.g., Eudora, Outlook, elm, user Mozilla Thunderbird agent user � outgoing, incoming messages agent stored on server 2: Application Layer ��

  35. Electronic Mail: mail servers user Mail Servers agent � mailbox contains incoming mail user messages for user server agent � message queue of outgoing SMTP (to be sent) mail messages mail server server user user � SMTP protocol between mail SMTP protocol between mail SMTP agent servers to send email messages SMTP � client: sending mail user mail agent server server � “server”: receiving mail user server agent user agent 2: Application Layer ��

  36. Electronic Mail: SMTP [RFC 2821] � uses TCP to reliably transfer email message from client to server, port 25 � direct transfer: sending server to receiving server � three phases of transfer � handshaking (greeting) � transfer of messages transfer of messages � closure � command/response interaction � commands: ASCII text � response: status code and phrase � messages must be in 7#bit ASCII 2: Application Layer ��

  37. Scenario: Alice sends message to Bob 4) SMTP client sends Alice’s 1) Alice uses UA to compose message over the TCP message and “to” connection ������������������ 5) Bob’s mail server places the 2) Alice’s UA sends message message in Bob’s mailbox to her mail server; message placed in message queue 6) Bob invokes his user agent to read message to read message 3) Client side of SMTP opens 3) Client side of SMTP opens TCP connection with Bob’s TCP connection with Bob’s mail server 1 mail mail user server user server agent 2 agent 6 3 4 5 2: Application Layer ��

  38. Sample SMTP interaction .��%%!����F���������� "����4&��������$�� .��%-!���������������$�)�����������������7��� "���#A4�<9&���B�����G�������$�C� .��%-!������G�������$�����.�������?� "��9"����&��BF�FG���F���������C� .��%-!�F�FG���F��������������9����������?� .��%-!�F�FG���F��������������9����������?� "��(#�#� .��0- �����������)����������H�H�����������F7������$� "��(��7�����?��?������I� "�������F�������?���I� "���� .��%-!������������������$�������/��7� "��J�A�� .��%%�����F���������������������������� 2: Application Layer ��

  39. Try SMTP interaction for yourself: � ����������/�������%- � see 220 reply from server � enter HELO, MAIL FROM, RCPT TO, DATA, QUIT commands above lets you send email without using email client above lets you send email without using email client (reader) 2: Application Layer ��

  40. SMTP: final words � SMTP uses persistent Comparison with HTTP: connections � HTTP: pull � SMTP requires message � SMTP: push (header & body) to be in 7# bit ASCII � both have ASCII � SMTP server uses � SMTP server uses command/response command/response �� !��� ! to determine interaction, status codes end of message � HTTP: each object encapsulated in its own response msg � SMTP: multiple objects sent in multipart msg 2: Application Layer ��

  41. Mail message format SMTP: protocol for header exchanging email msgs blank RFC 822: standard for text line message format: � header lines, e.g., � To: � To: body body � From: � Subject: different from SMTP commands ! � body � the “message”, ASCII characters only 2: Application Layer ��

  42. Mail access protocols SMTP SMTP access user user protocol agent agent receiver’s mail sender’s mail server server � SMTP: delivery/storage to receiver’s server � SMTP: delivery/storage to receiver’s server � Mail access protocol: retrieval from server � POP: Post Office Protocol [RFC 1939] • authorization (agent <##>server) and download � IMAP: Internet Mail Access Protocol [RFC 1730] • more features (more complex) • manipulation of stored msgs on server � HTTP: gmail, Hotmail, Yahoo! Mail, etc. 2: Application Layer ��

  43. POP3 protocol .��K&'��&�0����/�������7� "�������F�F� authorization phase .��K&'� "������������7� � client commands: .��K&' ������������$���7���������� � ����� declare username "������� � ����� password .���� +,� � server responses .��%�+�%� .���� .���� � K&' K&' "��������� � ��99 .��B������������������C transaction phase, client: .���� "��������� � ����� list message numbers "�������%� � ����� retrieve message by .��B������������������C number .���� "�������%� � ����� delete "��:���� � :��� .��K&'� �&�0����/������������$$ 2: Application Layer ��

  44. POP3 (more) and IMAP More about POP3 IMAP � Previous example uses � Keep all messages in “download and delete” one place: the server mode. � Allows user to � Bob cannot re#read e# organize messages in mail if he changes mail if he changes folders folders client � IMAP keeps user state � “Download#and#keep”: across sessions: copies of messages on � names of folders and different clients mappings between message IDs and folder � POP3 is stateless name across sessions 2: Application Layer ��

  45. Chapter 2: Application layer � 2.1 Principles of � 2.6 P2P applications network applications � 2.7 Socket programming � 2.2 Web and HTTP with TCP � 2.3 FTP � 2.8 Socket programming with UDP with UDP � 2.4 Electronic Mail � 2.4 Electronic Mail � 2.9 Building a Web � SMTP, POP3, IMAP server � 2.5 DNS 2: Application Layer ��

  46. DNS: Domain Name System People: many identifiers: Domain Name System: � SSN, name, passport # � distributed database implemented in hierarchy of Internet hosts, routers: many name servers � IP address (32 bit) # � application#layer protocol used for addressing used for addressing host, routers, name servers to host, routers, name servers 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 protocol addresses and name ? � complexity at network’s “edge” 2: Application Layer ��

  47. DNS Why not centralize DNS? DNS services � single point of failure � hostname to IP address translation � traffic volume � host aliasing � distant centralized database database � Canonical, alias names � Canonical, alias names � mail server aliasing � maintenance � load distribution � replicated Web doesn’t scale! servers: set of IP addresses for one canonical name 2: Application Layer ��

  48. Distributed, Hierarchical Database )����;=2�2������ ����;=2�������� ����;=2�������� ����;=2�������� �������� ��������� ������� ��������� ���>������ ;=2�������� ;=2�������� ;=2�������� ;=2�������� ;=2�������� ;=2�������� ;=2�������� Client wants IP for www.amazon.com; 1 st approx: � client queries a root server to find com DNS server � client queries com DNS server to get amazon.com DNS server � client queries amazon.com DNS server to get IP address for www.amazon.com 2: Application Layer ��

  49. DNS: Root name servers � 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 ��?���������;�������?� ��?���������;�������?� ��4�������8��������?��������@�� ��:�1��������4������� �����1; ��)" B�@������������*,����������������� ��:2�;�;�?�������?� ��������������2������������������� ���)@�����������1; .5����������������� $��?�����������.*����������� ���";B�������������2������ ��=�2��1��?��!��4� ������2&� ���"��������2���!����4�� ��� ������ 4�������A,����������������� 13 root name servers worldwide ��:24-"2"�1����������)����4� ���"4�==�@������������4� 2: Application Layer ��

  50. TLD and Authoritative Servers � Top#level domain (TLD) servers: � responsible for com, org, net, edu, etc, and all top#level country domains uk, fr, ca, jp. � Network Solutions maintains servers for com TLD � Educause for edu TLD � Educause for edu TLD � Authoritative DNS servers: � organization’s DNS servers, providing authoritative hostname to IP mappings for organization’s servers (e.g., Web, mail). � can be maintained by organization or service provider 2: Application Layer ��

  51. Local Name Server � does not strictly belong to hierarchy � each ISP (residential ISP, company, university) has one. � also called “default name server” also called “default name server” � when host makes DNS query, query is sent to its local DNS server � acts as proxy, forwards query into hierarchy 2: Application Layer ��

  52. DNS name root DNS server resolution example . � Host at cis.poly.edu A TLD DNS server wants IP address for 7 gaia.cs.umass.edu 0 local DNS server iterated query: iterated query: ���!����!��� ���!����!��� � contacted server , C replies with name of * 5 server to contact authoritative DNS server � “I don’t know this ���!��!�����!��� name, but ask this requesting host server” ���!����!��� ����!��!�����!��� 2: Application Layer ��

  53. DNS name resolution example root DNS server recursive query: . A � puts burden of name , C resolution on TLD DNS server contacted name server local DNS server local DNS server � heavy load? heavy load? 7 0 ���!����!��� * 5 authoritative DNS server ���!��!�����!��� requesting host ���!����!��� ����!��!�����!��� 2: Application Layer ��

  54. DNS: caching and updating records � once (any) name server learns mapping, it caches mapping � cache entries timeout (disappear) after some time � TLD servers typically cached in local name � TLD servers typically cached in local name servers servers • Thus root name servers not often visited � update/notify mechanisms under design by IETF � RFC 2136 � http://www.ietf.org/html.charters/dnsind#charter.html 2: Application Layer ��

  55. DNS records DNS: distributed db storing resource records (RR) RR format: 1����)�/����)��7��)����3 � Type=A � Type=CNAME � ���� is hostname ���� is hostname � ���� is alias name for some � ���� is alias name for some “canonical” (the real) name � /���� is IP address �����������" is really � Type=NS ���#�������������$�������� � ���� is domain (e.g. � /���� is canonical name foo.com) � /���� is hostname of � Type=MX authoritative name � /���� is name of mailserver server for this domain associated with ���� 2: Application Layer ��

  56. DNS protocol, messages DNS protocol : query and reply messages, both with same message format msg header � identification: 16 bit # for query, reply to query for query, reply to query uses same # uses same # � flags: � query or reply � recursion desired � recursion available � reply is authoritative 2: Application Layer ��

  57. DNS protocol, messages Name, type fields for a query RRs in response to query to query records for authoritative servers additional “helpful” info that may be used 2: Application Layer ��

  58. 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: registrar inserts two RRs into com TLD server: %�����������������&"���'������������������&"(�) %���'������������������&"$'$�$'$�$'$�'&"*) � create authoritative server Type A record for www.networkuptopia.com; Type MX record for networkutopia.com � How do people get IP address of your Web site? 2: Application Layer ��

  59. Chapter 2: Application layer � 2.1 Principles of � 2.6 P2P applications network applications � 2.7 Socket programming � app architectures with TCP � app requirements � 2.8 Socket programming � 2.2 Web and HTTP � 2.2 Web and HTTP with UDP with UDP � 2.4 Electronic Mail � SMTP, POP3, IMAP � 2.5 DNS 2: Application Layer ��

  60. Pure P2P architecture � no always#on server � arbitrary end systems directly communicate peer#peer � peers are intermittently connected and change IP connected and change IP addresses � Three topics: � File distribution � Searching for information � Case Study: Skype 2: Application Layer ��

  61. File Distribution: Server#Client vs P2P Question : How much time to distribute file from one server to N peers ? � � � �������������� ����!���� Server � � � �������������� ����!���� ����!���� � � � � � � � � � � � � � ���������!������ File, size F ����!���� � � Network (with abundant bandwidth) � � 2: Application Layer ��

  62. File distribution time: server#client Server � server sequentially F � � � � � � sends N copies: � � � � � NF/u s time Network (with � � abundant bandwidth) � client i takes F/d i � client i takes F/d i � � � � time to download time to download Time to distribute F = d cs = max { NF/u s , F/min(d i ) } to N clients using i client/server approach increases linearly in N (for large N) 2: Application Layer ��

  63. File distribution time: P2P Server � server must send one F � � � � � � copy: F /u s time � � � � � client i takes F/d i time Network (with � � to download abundant bandwidth) � � � � � NF bits must be � NF bits must be downloaded (aggregate) � fastest possible upload rate: u s + Σ u i d P2P = max { F/u s , F/min(d i ) , NF/(u s + Σ u i ) } i 2: Application Layer ��

  64. Server#client vs. P2P: example Client upload rate = u, F/u = 1 hour, u s = 10u, d min ≥ u s A�0 . �������������� A 4�����-2����� .�0 1�������;���������� . *�0 * /�0 / / 0 */ *0 ./ .0 A/ A0 = 2: Application Layer ��

  65. File distribution: BitTorrent � P2P file distribution torrent: group of tracker: tracks peers peers exchanging participating in torrent chunks of a file obtain list of peers trading chunks peer 2: Application Layer ��

  66. BitTorrent (1) � file divided into 256KB chunks . � peer joining torrent: � has no chunks, but will accumulate them over time � registers with tracker to get list of peers, connects to subset of peers (“neighbors”) � while downloading, peer uploads chunks to other peers. � peers may come and go � once peer has entire file, it may (selfishly) leave or (altruistically) remain 2: Application Layer ��

  67. BitTorrent (2) Sending Chunks: tit#for#tat � Alice sends chunks to four Pulling Chunks neighbors currently � at any given time, sending her chunks at the different peers have highest rate different subsets of � re#evaluate top 4 every file chunks 10 secs 10 secs � periodically, a peer periodically, a peer � every 30 secs: randomly (Alice) asks each select another peer, neighbor for list of starts sending chunks chunks that they have. � newly chosen peer may � Alice sends requests join top 4 for her missing chunks � “optimistically unchoke” � rarest first 2: Application Layer ��

  68. 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 With higher upload rate, can find better trading partners & get file faster! 2: Application Layer ��

  69. Distributed Hash Table (DHT) � DHT = distributed P2P database � Database has (key, value) pairs; � key: ss number; value: human name � key: content type; value: IP address � key: content type; value: IP address � Peers query DB with key � DB returns values that match the key � Peers can also insert (key, value) peers

  70. DHT Identifiers � Assign integer identifier to each peer in range [0,2 n #1]. � Each identifier can be represented by n bits. � Require each key to be an integer in same range. Require each key to be an integer in same range. � To get integer keys, hash original key. � eg, key = h(“Led Zeppelin IV”) � This is why they call it a distributed “hash” table

  71. How to assign keys to peers? � Central issue: � Assigning (key, value) pairs to peers. � Rule: assign key to the peer that has the closest ID. closest ID. � Convention in lecture: closest is the immediate successor of the key. � Ex: n=4; peers: 1,3,4,5,8,10,12,14; � key = 13, then successor peer = 14 � key = 15, then successor peer = 1

  72. Circular DHT (1) 1 3 15 4 12 12 5 10 8 � Each peer only aware of immediate successor and predecessor. � “Overlay network”

  73. Circle DHT (2) 0001 O(N) messages Who’s resp on avg to resolve for key 1110 ? I am query, when there 0011 are N peers 1111 ***/ 0100 ***/ ***/ 1100 0101 ***/ ***/ Define closest ***/ 1010 as closest 1000 successor

  74. Circular DHT with Shortcuts 1 Who’s resp for key 1110? 3 15 4 12 12 5 5 10 8 � Each peer keeps track of IP addresses of predecessor, successor, short cuts. � Reduced from 6 to 2 messages. � Possible to design shortcuts so O(log N) neighbors, O(log N) messages in query

  75. Peer Churn 1 D To handle peer churn, require 3 each peer to know the IP address 15 of its two successors. D Each peer periodically pings its 4 two successors to see if they are still alive . 12 12 5 5 10 8 � Peer 5 abruptly leaves � Peer 4 detects; makes 8 its immediate successor; asks 8 who its immediate successor is; makes 8’s immediate successor its second successor. � What if peer 13 wants to join?

  76. P2P Case study: Skype Skype clients (SC) � inherently P2P: pairs of users communicate. � proprietary Skype Supernode application#layer login server (SN) (SN) protocol (inferred via protocol (inferred via reverse engineering) � hierarchical overlay with SNs � Index maps usernames to IP addresses; distributed over SNs 2: Application Layer ��

  77. Peers as relays � Problem when both Alice and Bob are behind “NATs”. � NAT prevents an outside peer from initiating a call to insider peer to insider peer � Solution: � Using Alice’s and Bob’s SNs, Relay is chosen � Each peer initiates session with relay. � Peers can now communicate through NATs via relay 2: Application Layer ��

  78. Chapter 2: Application layer � 2.1 Principles of � 2.6 P2P applications network applications � 2.7 Socket programming � 2.2 Web and HTTP with TCP � 2.3 FTP � 2.8 Socket programming with UDP with UDP � 2.4 Electronic Mail � 2.4 Electronic Mail � SMTP, POP3, IMAP � 2.5 DNS 2: Application Layer ��

  79. Socket programming Goal: learn how to build client/server application that communicate using sockets Socket API socket � introduced in BSD4.1 UNIX, a host#local , 1981 application#created , application#created , � explicitly created, used, explicitly created, used, OS#controlled interface released by apps (a “door”) into which � client/server paradigm application process can both send and � two types of transport receive messages to/from service via socket API: another application � unreliable datagram process � reliable, byte stream# oriented 2: Application Layer ��

  80. Socket#programming using TCP Socket: a door between application process and end# end#transport protocol (UCP or TCP) TCP service: reliable transfer of ����� from one process to another controlled by controlled by process application process application developer socket developer socket TCP with controlled by TCP with controlled by buffers, operating buffers, operating internet system variables system variables host or host or server server 2: Application Layer ��

  81. Socket programming with TCP Client must contact server � When contacted by client, server TCP creates new � server process must first socket for server process to be running communicate with client � server must have created � allows server to talk with socket (door) that multiple clients welcomes client’s contact � source port numbers source port numbers Client contacts server by: used to distinguish � creating client#local TCP clients (more in Chap 3) socket � specifying IP address, port application viewpoint number of server process TCP provides reliable, in#order � When client creates transfer of bytes (“pipe”) socket: client TCP between client and server establishes connection to server TCP 2: Application Layer ��

  82. Client/server socket interaction: TCP Server (running on ������ ) Client �������������� ����E 2 ����� �����������F����� !������2������E� 2�����2������� TCP �������������� !���������������� !���������������� connection setup connection setup ����������� ������ ������E 2 ����������� ������ ������E 2 �������������F���� ������2������E� ����������2������E 2������� !������2�������������� �������F���������� �������F��������� ������2����� ����������2����� !������������� ����������2����� ��������������� ������2����� ����� ����� ����������2����� ������2����� 2: Application Layer ��

  83. Stream jargon �������� ������� � A stream is a sequence of characters that flow into ��&���:��� or out of a process. ����� ������ � An input stream is Client ������ attached to some input process source for the process, source for the process, e.g., keyboard or socket. � An output stream is attached to an output ��&���2����� �����2����� ������ ����� source, e.g., monitor or ������ ������ socket. client TCP ������2����� socket �4 ������ ������!��� ��������!��� 2: Application Layer ��

  84. Socket programming with TCP Example client#server app: 1) client reads line from standard input ( ��<������� stream) , sends to server via socket ( �����.��/�� stream) stream) 2) server reads line from socket 3) server converts line to uppercase, sends back to client 4) client reads, prints modified line from socket ( ��<���.��/�� stream) 2: Application Layer ���

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend