Computer Networking Principles Protocols and Practice Part 2

Computer Networking : Principles, Protocols and Practice Part 2 : Applications Olivier Bonaventure http: //inl. info. ucl. ac. be/ CNP 3/2008. 2. © O. Bonaventure 2008

The Application Layer Contents l l The client-server model l Name to address resolution l email l world wide web l peer-to-peer applications CNP 3/2008. 2. © O. Bonaventure 2008

The client server model Queries Client Server Responses Service provider (“the network”) Client l interacts with server through transport layer sends queries or commands l l l Server l l l Answers the queries received from clients Executes the commands from clients Many clients can use the same server l Example : email, www, . . . CNP 3/2008. 2. © O. Bonaventure 2008

The client server model (2) Client Queries Responses Server Service provider (“the network”) l l u CNP 3/2008. 2. Client and servers interact with service provider Both the client and the server must speak the same language Application-level protocol : set of syntactical and semantical rules that define the messages exchanged between the client and the server and their ordering © O. Bonaventure 2008

Transport service on the Internet On the Internet, applications can use two different transport services l The service provided by the User Datagram Protocol (UDP) l unreliable connectionless service with error detection u The service provided by the Transmission Control Protocol (TCP) l u CNP 3/2008. 2. reliable bytestream connection-oriented service © O. Bonaventure 2008

UDP service Applic. 2 Applic. 1 UDP service Identification: IP address : 2001: 6 a 8: 3080: 2: 217: f 2 ff: fed 6: 65 c 0 Protocol : UDP Port : 1234 Identification of an application l u l Identification IP address : 2001: 4860: a 005: : 68 Protocol : UDP Port : 53 IP address + UDP + port number Characteristics of UDP service connectionless unreliable u u u CNP 3/2008. 2. messages can be lost transmission errors can be detected but not recovered sequence is not preserved Maximum size of messages : almost 64 Kbytes © O. Bonaventure 2008

TCP service Applic. 2 Applic. 1 Identification: IP address : 138. 48. 32. 107 Protocol : TCP Port : 9876 TCP service Identification of an application l u l IP address + UDP + port number Characteristics of TCP service connection-oriented bidirectional reliable byte stream connection release u u u u CNP 3/2008. 2. Identification IP address: 139. 165. 16. 12 Protocol : TCP Port : 80 abrupt if initiated by service provider graceful or abrupt if initiated by user © O. Bonaventure 2008

Internet applications Contents l l The client-server model l Name to address resolution l email l world wide web l peer-to-peer applications CNP 3/2008. 2. © O. Bonaventure 2008

Names and addresses Address of a server l IP Address of the host on which the server is running port number (TCP or UDP) l usually well known port number u Drawback l Difficult to remember an IP address for a human l Idea l Replace IP address by a hostname Easier for humans l l but IP address is necessary to contact server u l How to translate a hostname in an IP address ? CNP 3/2008. 2. © O. Bonaventure 2008

Names and addresses (2) l l l hosts. txt file contains the name-address table must be updated regularly # # Internet host # 127. 0. 0. 1 138. 48. 32. 99 138. 48. 32. 100 138. 48. 32. 1 138. 48. 32. 92 138. 48. 32. 107 138. 48. 20. 152 138. 48. 32. 137 138. 48. 32. 170 l table localhost babbage leibniz routeur corneille backus arzach almin 01 duke cannot be used in a large network CNP 3/2008. 2. © O. Bonaventure 2008

Hostnames Requirement l Host names should be unique l How to achieve this in a scalable manner ? l Introduce hierarchy Each hostname is composed of two parts l l u u How to uniquely distribute domain names ? l u u u CNP 3/2008. 2. domain name (globally unique) hostname (unique within a given domain) Introduce hierarchy A small number of top-level domain names Inside each top-level domain, allocate uniquely second level domain names Inside each seconde-level domain, allocate uniquely either third-level domain names or host names, . . . © O. Bonaventure 2008

Host names and domain names l Tree of all host names edu com Sun java net apple eng gov mil fbi whitehouse mail www be ac fundp info rtbf cec ulg de inria ucl lihd scf Pollux backus leibniz CNP 3/2008. 2. fr Angora siamois spirou © O. Bonaventure 2008

How to translate names into addresses ? How to efficiently translate a host name ? l By using a centralised database l u l there are more than 1 billion host names today By using a distributed database u u u edu DNS : Domain Name System relies on the hierarchy of domain names there is one server responsible for each domain and this server must be queried to translate host names inside this domain com sun java CNP 3/2008. 2. apple net gov mil fbi whitehouse mail www be ac fundp info rtbf ulg lihd scf fr cec de inria ucl © O. Bonaventure 2008

How to translate names into addresses ? Domain Name Service (DNS) l Each DNS server is responsible for a domain and knows l The IP addresses of all host names in this domain The IP addresses of the DNS servers responsible for subdomains u u Examples l edu com sun apple java u u CNP 3/2008. 2. java. sun. com www. ucl. ac. be net gov fbi whitehouse mail www mil be ac fundp rtbf ulg www fr cec de inria ucl info math fsa © O. Bonaventure 2008

DNS resolver To be able to translate name to addresses, a DNS implementation needs l to know actual list of IP addresses of root servers to implement the DNS protocol and traverse the domain names hierarchy Difficult to do this on all endhosts l l l Solution l DNS resolver l one resolver for a set of endhosts maintains up-to-date list of IP addresses of root servers implements DNS protocol u u u endhosts l u u CNP 3/2008. 2. only need to be able to send DNS requests to resolver must know IP address of closest DNS resolvers © O. Bonaventure 2008

DNS : optimisations Reduce risk of failures l several root-servers server DNS servers authoritative for each domain each endhost can send queries to multiple resolvers l l l Improved performance l avoid sending several times the same query cache memory on DNS resolvers containing l l recent name-addresses translations addresses of DNS servers recently contacted u u DNS protocol l usually runs over UDP sometimes is also used over TCP CNP 3/2008. 2. © O. Bonaventure 2008

DNS : message format Each DNS request contains a number that will be returned in the response by the server to allow the client to match the request. 32 bits Identification 12 bytes Flags Number of questions Number of answers Number of authority Number of additional Question/Response l. Recursive question or not l. Authoritative answer or not l. Possible error l Questions (variable number of resource records) Answers (variable number of resource records) Authority (variable number of resource records) Additional information (variable number of resource records) CNP 3/2008. 2. © O. Bonaventure 2008

DNS : resource records Each DNS messages is composed of resource records (RR) encoded as TLV l l l u < Name, Value, Type, TTL> Types de RR Lifetime of the A (Address) u u u Name is a hostname and Value an IPv 4 address AAAA (Address) Name is a hostname and Value an IPv 6 address NS (Name. Server) Name is a domain name and Value is the hostname of the DNS server responsible for this domain MX (Mail Exchange) u u Name is a domain name and Value is the name of the SMTP server that must be contacted to send emails to this domain Type CNAME u u CNP 3/2008. 2. RR in server’s cache Alias © O. Bonaventure 2008

Internet applications Contents l l The client-server model l Name to address resolution l email l world wide web l peer-to-peer applications CNP 3/2008. 2. © O. Bonaventure 2008

Email Simplified model l l Alice sends an email to Bob Alice@a. net Alice’s email server b. net ‘s email server Bob@b. net Bob retrieves message Alice sends her email from his server to local mail forwarder Alice’s server sends email to b. net’s MX CNP 3/2008. 2. © O. Bonaventure 2008

Email message format From: president@abc. be To: ceo@def. com Subject: Hello Date : 27 Sept. 1999 0901 Exp: ABC S. A. Rue de Fer 10 5000 Namur DEF Corp. Steel street 9 WA 78 AX London Grande Bretagne CNP 3/2008. 2. Header Dear Sir, Bla Bla. . . Message body © O. Bonaventure 2008

Message format (2) Header format l Contains only US-ASCII (7 bits) characters At least three lines that end with <CRLF> l l From: sender@domain To: recipient@domain Date: <creation date of message> u u Optional fields l u u u l example : 26 Aug 199 1445 EDT Subject: subject of message cc: copy@domain Message-ID: <number@domain> Received: information on path followed by message In-Reply-To: <message-ID> Header ends with empty line (<CRLF>) CNP 3/2008. 2. © O. Bonaventure 2008

MIME Internet email was designed for US-ASCII l l l How to transmit more complex messages ? Multipurpose Internet Mail Extensions Improved email message format Constraints l l must remain compatible with old email servers u u u u most of them only support US-ASCII and short lines must support non-English text character set must be beyond 7 bits US-ASCII must support various formats in a single message body, attachments, . . . must allow to transmit audio, video, . . . need to identify the type of content Solution l l l add new optional fields in header add optional fields inside message body when necessary CNP 3/2008. 2. © O. Bonaventure 2008

MIME (2) New header fields l MIME-Version: l u u l u l version of MIME used to encode message current version : 1. 0 Content-Description: comment describing the content of the message Content-Type: type of information inside message Content-Transfer-Encoding: how the message has been encoded Content-Id: u CNP 3/2008. 2. unique identifier for the content © O. Bonaventure 2008

MIME: Content-Type : type/encoding l type of content l u u l text, image, video, application multipart encoding of content text/plain , text/html image/gif, image/jpeg audio/basic video/mpeg, video/quicktime application/octet-stream, application/postscript multipart/alternative u u u u multipart/mixed u u CNP 3/2008. 2. message contains several times the same information with different encodings message contains several information of different types u example : text of message body and attachment © O. Bonaventure 2008

Character sets and content encoding How to support rich character sets ? l Content-Type: text/plain; charset=us-ascii l u l ASCII 7 bits, default Content-Type: text/plain; charset=iso-8859 -1 Character set suitable for Western European languages, defined by ISO, 8 bits per character Content-Type: text/plain; charset=unicode Universal character set, defined by ISO, 16 bits per character u u u How to encode non-text data ? l data must be encoded in US-ASCII 7 bits characters Base 64 uses ASCII characteres A. . . Z, a. . . z, 0. . . 9, "+" et "/" l l l u l A=0, B=1, C=2, . . . +=62 et /=63 Each character is used to encode 6 bits 24 bits from initial message -> 4 ASCII characters Special character “=” used for padding CNP 3/2008. 2. © O. Bonaventure 2008

Multipart/mixed How to place different contents and encoding in a single message ? l l We need a delimiter between the different content types placed inside message body Date: Mon, 20 Sep 1999 16: 33: 16 +0200 From: Nathaniel Borenstein <nsb@bellcore. com> To: Ned Freed <ned@innosoft. com> Subject: Test MIME-Version: 1. 0 Content-Type: multipart/mixed; boundary="simple boundary" preamble, to be ignored --simple boundary Content-Type: text/plain; charset=us-ascii partie 1 --simple boundary Content-Type: text/plain; charset=us-ascii partie 2 --simple boundary CNP 3/2008. 2. © O. Bonaventure 2008

Email transmission SMTP : Simple Mail Transfer protocol l uses TCP service Address of SMTP server l l IP address of server + TCP + port number: 25 u u RR of type MX can be used to find the SMTP server responsible for a given domain SMTP Alice@a. net CNP 3/2008. 2. a. net’s SMTP server b. net’s SMTP server Email retrieval Bob@b. net © O. Bonaventure 2008

SMTP Client-server model l Server waits for email messages to relay/deliver Client sends email messages through server l l Application-level protocol l client opens TCP connection Client sends commands composed of l l command parameter <CRLF> u u u HELO MAIL FROM: RCPT TO: DATA QUIT Server answers with one-line replies l numeric_code comment (text) <CRLF> u u u CNP 3/2008. 2. 250 OK 221 closing © O. Bonaventure 2008

SMTP (2) l Three phases of SMTP 1. Establishment of an SMTP association u u u TCP connection established upon request from client Server greetings HELO command from client u u u MAIL FROM: <user@domaine> RCPT TO: <user@domaine> DATA 2. Message transfer u u transmission of entire message including headers one line containing only the dot “. ” characters marks end of message 1. Other subsequent messages can be transmitted after u u 1. QUIT Closing message from server TCP connection is closed l Release of the SMTP association CNP 3/2008. 2. © O. Bonaventure 2008

Retrieval of email messages l In the old days 1. Destination is always connected to the Internet email addresses are username@hostname When an email arrives, it is stored in a file that belongs to the user, e. g. /var/mail on Unix u u u Today u u Most networks have one or a few SMTP servers used to receive emails, but also detect spam, viruses, . . . Endusers retrieve their emails from this server 1. u u CNP 3/2008. 2. Post Office Protocol (POP) Internet Mail Access Protocol (IMAP) Webmail © O. Bonaventure 2008

POP Goal l Allow authenticated users to retrieve email messages from server l Operation l POP uses TCP service Address of POP server l l u u l Host address + TCP + port number : 110 Client send commands command : one ASCII line ending with <CRLF> USER, PASS, STAT, RETR, DELE, QUIT server replies with +OK if command was successful u u u CNP 3/2008. 2. email messages follow some +OK replies -ERR in case of errors © O. Bonaventure 2008

POP (2) l Three phases of the protocol 1. Authorisation : checking the user credentials u u USER <username> PASS <password> u u retrieval and removal of messages STAT 2. Transaction u u list headers of stored messages RETR <n> 1. retrieval of the nth message u the nth message is marked for deletion DELE <n> u 3. Update End of the retrieval phase u u u CNP 3/2008. 2. Messages marked for deletion are removed from server TCP connection is closed © O. Bonaventure 2008

Internet applications Contents l l The client-server model l Name to address resolution l email l world wide web l peer-to-peer applications CNP 3/2008. 2. © O. Bonaventure 2008

FTP : File Transfer Protocol from the old days l allows a client to send/retrieve files from a server l Problems solved by FTP l User authentication l u l u username, password Filesystem traversal browse directories on server and locate files file transfer to or from the server Client Server Commands Ftp-control : port 21 Responses Ftp-data : port 20 CNP 3/2008. 2. © O. Bonaventure 2008

FTP : main commands Main commands l USER <user> l u l u CNP 3/2008. 2. username, ftp for anonymous access PASS <pass> allows user to send password associated to username SYST information about type of server CWD <path> directory traversal STOR <file> save file in the current directory on server RETR <file> retrieve file from current directory on server PORT <B 1, B 2, B 3, B 4, B 5, B 6> use TCP connection on port B 5*256+B 6 on B 1. B 2. B 3. B 4 © O. Bonaventure 2008

World Wide Web Goals l l Allow browsers to browse hypertext documents stored on multiple servers Server www. machin. be Server www. truc. fr Query Information Client (browser) Server www. stuff. com CNP 3/2008. 2. © O. Bonaventure 2008

World Wide Web (2) l The five key elements of www 1. An addressing scheme that allows to identify any document stored on a server u URL : Uniform Resource Locator u HTML : Hyper. Text Markup Language u HTTP : Hyper. Text Transfer Protocol 2. An hypertext language that allows to easily write documents with hypertext links 3. An efficient and lightweight application-level protocol to exchange documents l Servers 1. Clients (browsers) CNP 3/2008. 2. © O. Bonaventure 2008

Uniform Resource Locator (URL) l generic syntax : <protocol>: //<document> l protocol used to retrieve document from server u u http is the most common one but others are frequently used document indicates the server and the location of the document <user>: <password>@<server>: <port>/<path> u u u examples u u u CNP 3/2008. 2. <user> : optional username <password> : optional password <machine> : hostname or IP address of the server that hosts the document <port> : optional port number <path> : document location on server http: //www. info. ucl. ac. be http: //alice: secret@inl. info. ucl. ac. be: 80/index. html © O. Bonaventure 2008

HTML Hyper. Text Markup Langage l l Language used to encode documents on the web l Keywords u u u u CNP 3/2008. 2. <HTML>. . . </HTML> <HEAD>. . . </HEAD> <BODY>. . . </BODY> <TITLE>. . </TITLE> <B>. . . </B> <I>. . . </I> <H 1>. . . </H 1> <P> <HR> <UL>. . . </UL> <OL>. . . </OL> <IMG SRC="URL"> <A HREF="URL">text anchor</A> © O. Bonaventure 2008

HTML (2) l Example <HTML> Header Body <HEAD> <TITLE>HTML test page</TITLE> </HEAD> <BODY> <IMG SRC="http: //www. images. be/logo. gif"> <H 1>Web servers from UCL<P></H 1> First level <HR> <UL> <LI><A HREF="http: //www. uclouvain. be">UCL</A> <LI><A HREF="http: //www. info. ucl. ac. be">CSE Dept. </A> <LI><A HREF="http: //www. math. ucl. ac. be">Math</A> </UL> </BODY> </HTML> CNP 3/2008. 2. Image on remote server title External hypertext link © O. Bonaventure 2008

Information transfer www HTTP 1. 0 - non-persistent connection l Principle l u u relies on TPC service (default port : 80) Client sends request, server sends reply Client CONNECT. request CONNECT. confirm DATA. request(Request) Server CONNECT. indication CONNECT. response DATA. ind(Request) DATA. req(Response) DATA. ind(Response) DISCONNECT. ind DISCONNECT. req CNP 3/2008. 2. DISCONNECT. req DISCONNECT. ind © O. Bonaventure 2008

HTTP Header contains additional information about request sent by client Method GET l. POST l. . . Request Client Method Header CRLF MIME Document Server Response Status line Header CRLF MIME Document Success or failure Header contains information about server and optional parameters specific to response HTTP is a stateless protocol, server does not maintain any state from one request to another l. POP, FTP, SMTP are examples of stateful protocols in contrast © O. Bonaventure 2008 CNP 3/2008. 2.

HTTP : Example Request GET /index. html HTTP/1. 1 Host: www. info. fundp. ac. be CRLF Server www. info. fundp. ac. be Client Response HTTP/1. 1 200 OK Date: Fri, 10 Sep 1999 14: 29: 19 GMT Server: Apache/1. 3. 0 (Unix) Apache. JServ/1. 0 b 5 Last-Modified: Thu, 02 Sep 1999 11: 50 GMT Content-Length: 1224 Content-Type: text/html CRLF <HTML>. . . </HTML> CNP 3/2008. 2. © O. Bonaventure 2008

HTTP : Methods l Methods GET l method used to request a "document" stored on server u u GET <document> example GET /index. html HTTP/1. 0 POST l method used to send a "document" to a server u u CNP 3/2008. 2. document is part of the request and encoded as a MIME document © O. Bonaventure 2008

HTTP : Request headers l Request headers Allow to add information about the client or the request Host: <name> l l u l Name of the server where the document is stored Authorization allows to perform access control If-Modified-Since: <date> server will only send the requested document if the document is more recent than date u Referer: <url> l u Information, indicates the URL visited by the client before this request User-Agent: <agent> l u CNP 3/2008. 2. information, indicates the browser used on the client © O. Bonaventure 2008

HTTP : Status line Status liine l Format : Version_HTTP Code Comment Success/Failure l l 1 xx : For information (unused) 2 xx : Success u u u Example : HTTP/1. 0 200 OK 3 xx : Redirection Request could not be handled on local server and should be sent to another server Example : u HTTP/1. 0 301 Moved permanently u attached MIME document will contain URL of document 4 xx : Client-side error u u examples u syntax error, unreachable URL, unauthorised, . . . 5 xx : Server-side error u u CNP 3/2008. 2. examples : u internal error, method not implemented on server, . . . © O. Bonaventure 2008

HTTP : Response headers Header l Optional information about the server, the response or the document attached to the response Date l l date of the document attached to response example : Date: Wed, 05 Sep 2001 13: 27: 34 GMT u u Server l Name and version of http server used example : u u Server: Apache/1. 3. 20 (Unix)Apache. JServ/1. 1. 2 PHP/4. 0. 6 Content-* l u u CNP 3/2008. 2. MIME header of the attached document example : Content-Length: 5891 Content-Type: text/html © O. Bonaventure 2008

HTTP 1. 1 HTTP 1. 0 l a single TCP connection used to transmit a single document (html file, image, . . . ) l u the establishment and release of the TCP connection induce a significant overhead, in particular for small pages HTTP 1. 1 l uses a single persistent TCP connection l u u u CNP 3/2008. 2. This TPC connection can be used for several requests and the corresponding responses the cost of establishing and releasing the TCP connection is amortised over multiple requests Although HTTP 1. 1 uses a single TCP connection for multiple requests, HTTP 1. 1 remains stateless © O. Bonaventure 2008

HTTP 1. 1 : Persistent connection Server Client CONNECT. request CONNECT. indication CONNECT. confirm CONNECT. response GET / HTTP 1. 1 Connection: Keep-Alive. . . GET /images/logo. gif HTTP 1. 1 Connection: Keep-Alive. . . DISCONNECT. ind DISCONNECT. req CNP 3/2008. 2. HTTP/1. 1 200 OK Keep-Alive: timeout=15, max=100 Connection: Keep-Alive. . . HTTP/1. 1 200 OK Keep-Alive: timeout=15, max=99 Connection: Keep-Alive. . . DISCONNECT. req DISCONNECT. ind © O. Bonaventure 2008

Improving performance Observation l Many pages are requested multiple times or from close endhosts l Solution l local cache on each client l u l if-modified-since header helps one cache for multiple endhosts Server. A Client 1 Serveur. B Client. N Proxy CNP 3/2008. 2. © O. Bonaventure 2008

HTTP Authentication l Example Client GET / HTTP 1. 1. . . Browser asks user/password to user GET / HTTP 1. 1 Authorization: User-password. . . Server HTTP/1. 0 401 Authorization req WWW authenticate: machin. . . HTTP/1. 1 200 OK. . . GET /images/t. gif HTTP 1. 1 Authorization: User-password. . . Browser sends user/password in each request CNP 3/2008. 2. © O. Bonaventure 2008

HTTP Cookies l Example Client GET / HTTP 1. 1. . . Browser saves cookie GET /doc HTTP 1. 1 Cookie: machin. . . GET /images/t. gif HTTP 1. 1 Cookie: machi. . . Server HTTP/1. 0 200 OK Set-Cookie: machin. . . Normal response HTTP/1. 1 200 OK. . . Response is function of URL and cookie Browser sends cookie in all requests sent to server CNP 3/2008. 2. © O. Bonaventure 2008

Internet applications Contents l l The client-server model l Name to address resolution l email l world wide web l peer-to-peer applications CNP 3/2008. 2. © O. Bonaventure 2008

Predicted IP traffic growth CNP 3/2008. 2. © O. Bonaventure 2008

Predicted IP traffic growth CNP 3/2008. 2. © O. Bonaventure 2008

Predicted IP traffic growth (3) CNP 3/2008. 2. © O. Bonaventure 2008

Peer-to-peer file sharing l Evolution of file sharing on the Internet l Servers using ftp protocol A single server that serves all files on disk A set of mirror serves serving the same content l l The innovation introduced by Napster l How to distribute many files from many nodes ? l Keep the files on their source nodes Central Napster server stores description and URL of each shared file Users willing to obtain a file consult central server to obtain file URL and then download file from their respective source nodes u u u CNP 3/2008. 2. server remains simple and can index large number of files server does not directly participate in file transfer © O. Bonaventure 2008

Peer-to-peer file sharing (2) Limitations of the Napster approach l a single server indexes all files if a source node fails, then the ongoing file transfers must be restarted l l u completely or partially depending on the file transfer protocol begin used for the transfer performance of file transfer is function of performance of the corresponding source node l u if source node is connected via ADSL, performance will be severely limited How to improve ? l Divide the file in blocks Each block can be served by multiple nodes l l u CNP 3/2008. 2. provides redundancy Download from several nodes at the same time one TCP connection may be slow and others faster © O. Bonaventure 2008

Distributed Hash Table based P 2 P How to scale file sharing to a very large number n of nodes ? Principle of the solution l l Use a hash function such as SHA-1 Each node has one identifier, id=hash(IPaddress) and a pointer to its successor on the Chord ring Node 15 Node 12 CNP 3/2008. 2. Node 7 © O. Bonaventure 2008

How to store files ? Principle l File FOOBAR is stored on the node whose id is the successor of hash(“FOOBAR”) on the ring A node on the ring uses its successors to find the responsible node for a given file l l u Examples Node 15 Hash(FOOBAR)=13 Hash(BARFOO)=5 Node 12 Node 7 CNP 3/2008. 2. © O. Bonaventure 2008

How to find files faster ? Performance of file lookup l O(n) l worst case is to follow linked list of n nodes u How to improve ? l Allow nodes to know addition pointers to other nodes on the Chord ring to speedup lookup l m = number of bits in the key/node identifiers Each node maintains routing table of m entries The ith entry in the table at node n contains the identity of the first node, s, that succeeds n by at least 2^i− 1 on the identifier circle, i. e. , s = successor(n + 2^i− 1 ) u u u CNP 3/2008. 2. arithmetic modulo 2^m is used A finger table entry includes both the Chord identifier and the IP address (and port number) of relevant node. © O. Bonaventure 2008

Scalable lookup with Chord Example l m=8 l Node 57 Node 8 Node 51 Node 13 Node 46 Node 29 Node 37 N 8+1 N 13 N 8+2 N 13 N 8+4 N 13 N 8+8 N 29 N 8+16 N 29 N 8+32 N 46+1 N 51 N 46+2 N 51 N 46+4 N 51 N 46+8 N 57 N 46+16 N 57 l How to find key 53 from node 8 ? CNP 3/2008. 2. N 46+32 N 8 © O. Bonaventure 2008

Summary l Client-server model l UDP and TCP services l Application-level protocols DNS l u l u l relies on UDP, stateless SMTP, POP, FTP rely on TCP, statefull HTTP relies on TCP, stateless Peer-to-peer applications CNP 3/2008. 2. © O. Bonaventure 2008