Layer Layer 2-1 August 26, 2015. Application Layer Computer Networks Shahrood.

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-1 August 26, 2015. Application Layer Computer Networks Shahrood University of Technology Department of Computer Engineering & IT

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-2 August 26, 2015  2.1 Principles of app layer protocols  clients and servers  app requirements  2.2 Web and HTTP  2.3 FTP  2.4 Electronic Mail  SMTP, POP3, IMAP  2.5 DNS  2.6 Socket programming with TCP  2.7 Socket programming with UDP  2.8 Building a Web server  2.9 Content distribution  Network Web caching  Content distribution networks  P2P file sharing Chapter 2 Outline

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-3 August 26, 2015  within same host, two processes communicate using inter-process communication (defined by OS).  processes running in different hosts communicate with an application-layer protocol  implements user interface & application-level protocol  Web: browser  E-mail: mail reader  streaming audio/video: media player Process: program running within a host. user agent: interfaces with user “above” and network “below”. Network Applications

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-4 August 26, 2015 Application Program Interface (API) Communication Software & Hardware Platform (OS + Hardware) Application Software (API) App. Software transport network link physical application Controlled by OS Controlled by App. Soft. Application-layer protocols: one “piece” of the application; define messages exchanged by apps and actions taken. the application From Application Viewpoint

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-5 August 26, 2015 Application process Application Program Interface (API) Communication Software & Hardware CommunicationNetwork Platform (OS + Hardware) Application Process (Client Side) Application Process (Server Side)  Server Agents Examples:  Internet Information Sever, Appachi  SQL query engines  Communication Software Examples: TCP, UDP; IP… Client/Server Applications

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-6 August 26, 2015 application transport network data link physical modem application transport network data link physical application transport network data link physical Application: communicating, distributed processes  e.g., e-mail, Web, P2P file sharing, instant messaging  running in end systems (hosts)  exchange messages to implement application Application-layer protocols  one “piece” of an app  define messages exchanged by apps and actions taken  use communication services provided by lower layer protocols (TCP, UDP) Applications and Application-Layer Protocols

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-7 August 26, 2015  Types of messages exchanged: request & response messages  Syntax of message types: what fields in messages & how fields are delineated  Semantics of the fields: meaning of information in fields  Rules for when and how processes send & respond to messages Public-domain protocols:  defined in RFCs  allows for interoperability  eg, HTTP, SMTP Proprietary protocols:  eg, Napster, KaZaA, … Application-Layer Protocols

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-8 August 26, 2015 modem Typical network app has two pieces: client and server Client:  initiates contact with server (“speaks first”)  typically requests service from server,  Web: client implemented in browser; e-mail: in mail reader reply Server:  provides requested service to client  e.g., Web server sends requested Web page, mail server delivers e-mail application transport network data link physical application transport network data link physical request Client-Server Paradigm

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-9 August 26, 2015 Pure P2P architecture  no always on server  arbitrary end systems  directly communicate  peers are intermittently  connected and change IP  addresses  example: Gnutella  Highly scalable  But difficult to manage modem

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-10 August 26, 2015 Hybrid of client-server and P2P Napster  File transfer P2P  File search centralized:  Peers register content at central server  Peers query same central server to locate content Instant messaging  Chatting between two users is P2P  Presence detection/location centralized:  User registers its IP address with central server when it comes online  User contacts central server to find IP addresses of buddies

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-11 August 26, 2015  process sends/receives messages to/from its socket  socket analogous to door  sending process pushes message out door  sending process assumes transport infrastructure on other side of door which brings message to socket at receiving process process TCP with buffers, variables socket host or server process TCP with buffers, variables socket host or server Internet controlled by OS controlled by app developer  API: (1) choice of transport protocol; (2) ability to fix a few parameters (lots more on this later) Processes Communicating Across Network Sockets: doors between process and host

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-12 August 26, 2015  For a process to receive messages, it must have an identifier  Every host has a unique 32-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 server: 80  Mail server: 25  Example IP address:  113.45.12.201  Example Identifier:  (80; 113.45.12.201) Process Identifier

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-13 August 26, 2015 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” Throughput  some apps (e.g., multimedia) require minimum amount of bandwidth to be “effective”  other apps (“elastic apps”) make use of whatever bandwidth they get What transport service does an app need?

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-14 August 26, 2015 ApplicationData lossThroughputTime Sensitive file transferno losselasticno e-mailno losselasticno web documentsno losselastic (few kbps)no real-time audio/video loss- tolerant audio: few kbps-1Mbps video:10kbps-5Mbps yes, 100s of msec stored audio/video loss- tolerant same as aboveyes, few sec interactive games loss- tolerant few kbps-10kbpsyes, 100s of msec instant messaging no losselasticyes and no Requirements of Selected Network Applications

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-15 August 26, 2015 TCP service:  connection-oriented: setup required between client and server processes  reliable transport between sending and receiving process  flow control: sender won’t overwhelm receiver  congestion control: throttle sender when network overloaded  no guarantee on: timing, minimum bandwidth UDP service:  unreliable data transfer between sending and receiving process  does not provide: connection setup, reliability, flow control, congestion control, timing, or bandwidth guarantee Q: Why is there a UDP? Internet Transport Protocols Services

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-16 August 26, 2015 Internet apps: application, transport protocols applicationsapplication-layer protocol underlying transport protocol e-mailSMTP [RFC 2821]TCP remote terminal accessTelnet [RFC 854]TCP webHTTP [RFC 2616]TCP file transferFTP [RFC 959]TCP remote file serverNFS [McKusik]UDP or TCP streaming multimediaproprietary (e.g., Dialpad) UDP or TCP internet telephony proprietary (e.g., Dialpad) Typically UDP

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-18 August 26, 2015 What is a Web Browser  It is a software application that enables a user to display and interact with html, text, images, audio, and other information typically located on a web page at a web server.  Text and images on a web page can contain hyperlinks to other web pages at the same or different websites.  Web browsers allow a user to quickly and easily access information provided on many web pages at many websites by traversing these links.  Web browser hides http underneath a nice GUI.  Browser must handle server error messages in some elegant way.

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-19 August 26, 2015 Web Browsers  Deepnet Explorer  Internet Expolrer  Mozilla Firefox  Netscape  Opera  Safari RSS

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-20 August 26, 2015 What is a Web Server?  The term Web server can mean one of two things:  A computer or A program that is:  responsible for accepting HTTP requests from clients, which are known as Web browsers, and serving them HTTP responses along with optional data contents, which usually are Web pages such as HTML documents and linked objects (images, etc.).

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-21 August 26, 2015 Modern Web Servers  On client side, higher-end client capabilities:  Java applets  DHTML (css, xml, javascript, etc).  Increased form support in http  multimedia (flash, etc.)  On server side, this led to:  dynamic web pages – asp, jsp, servlets, Cold Fusion, PHP, etc.  improvements in cgi

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-22 August 26, 2015 Market Share for Top Servers Across All Domains Source: http://news.netcraft.com/

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-23 August 26, 2015  Web page consists of objects  Object can be HTML file, JPEG image, Java applet, audio file,…  Web page consists of base HTML-file which includes several referenced objects  Each object is addressable by a URL  Example URL: www.shahroodut.ac.ir/computer/home.html host name path name Web and HTTP

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-24 August 26, 2015 HTTP: hypertext transfer protocol  Web’s app layer protocol  client/server model  client: browser that requests, receives, “displays” Web objects  server: Web server sends objects in response to requests  HTTP 1.0: RFC 1945  HTTP 1.1: RFC 2068 PC running Explorer Server running Apache Web server Mac running Navigator HTTP request HTTP response Storage contents: base files, objects HTTP Overview

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-25 August 26, 2015 Uses TCP:  client initiates TCP connection (creates socket) to server, port 80  server accepts TCP connection from client  HTTP messages (application- layer protocol messages) exchanged between browser (HTTP client) and Web server (HTTP server)  TCP connection closed HTTP is “stateless”  server maintains no information about past client requests Protocols that maintain “state” are complex!  past history (state) must be maintained  if server/client crashes, their views of “state” may be inconsistent, must be reconciled aside HTTP Overview (cont.)

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-26 August 26, 2015 Nonpersistent HTTP  At most one object is sent over a TCP connection.  HTTP/1.0 uses nonpersistent HTTP Persistent HTTP  Multiple objects can be sent over single TCP connection between client and server.  HTTP/1.1 uses persistent connections in default mode HTTP Connections

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-27 August 26, 2015 Suppose user enters URL www.shahroodut.ac.ir/computer/home.html 1. HTTP client initiates TCP connection to HTTP server (process) at www.shahroodut.ac.ir on port 80 3. HTTP client sends HTTP request message (containing URL) into TCP connection socket. Message indicates that client wants object Computer//home.html 2. HTTP server at host www.shahroodut.ac.ir waiting for TCP connection at port 80. “accepts” connection, notifying client 4. HTTP server receives request message, forms response message containing requested object, and sends message into its socket time (contains text, references to 10 jpeg images) Non-persistent HTTP

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-28 August 26, 2015 5. HTTP client receives response message containing html file, displays html. Parsing html file, finds 10 referenced jpeg objects 7. Steps 1-6 repeated for each of 10 jpeg objects 6. HTTP server closes TCP connection. time 4. … Non-persistent HTTP (cont.)

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-29 August 26, 2015 Definition of RTT: time to send a small packet to travel from client to server 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 time to transmit file initiate TCP connection RTT request file RTT file received time Response Time Modeling

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-30 August 26, 2015 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  server leaves connection open after sending response  subsequent HTTP messages between same client/server are sent over connection Persistent without pipelining:  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 Persistent HTTP

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-31 August 26, 2015 methodSPURLSPversionCRLF header field name:valueCRLF ---- header field name:valueCRLF CRLF request line header lines Entity Body HTTP Request Message: General Format

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-32 August 26, 2015 versionSPstatus codeSPphraseCRLF header field name:valueCRLF ---- header field name:valueCRLF CRLF status line header lines Entity Body HTTP Response Message: General Format

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-33 August 26, 2015 HTTP request message: ASCII (human-readable format) GET /somedir/page.html HTTP/1.1 Host: www.someschool.edu User-agent: Mozilla/4.0 Connection: close Accept-language:fr If-modified-since:Sat, 2 Nov 2002 13:45:12 (carriage return, line feed) request line (GET, POST, HEAD commands) header lines Carriage return, line feed indicates end of message HTTP Request Message

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-34 August 26, 2015 HTTP/1.1 200 OK Connection: close Date: Thu, 06 Aug 1998 12:00:15 GMT Server: Apache/1.3.0 (Unix) Last-Modified: Mon, 22 Jun 1998 …... Content-Length: 6821 Content-Type: text/html data data data data data... status line (protocol status code status phrase) header lines data, e.g., requested HTML file MIME lines HTTP Response Message

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-35 August 26, 2015 GET The GET method means retrieve whatever information (in the form of an entity) is identified by the Request-URL. The semantics of the GET method changes to a "conditional GET" if the request message includes an If-Modified-Since header field.HEAD The HEAD method is identical to GET except that the server must not return any Entity-Body in the response. There is no"conditional HEAD"request analogous to the conditional GET. GET and HEAD Commands

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-36 August 26, 2015 Goal: don’t send object if client has up-to-date cached version  client: specify date of cached copy in HTTP request If-modified-since:  server: response contains no object if cached copy is up-to-date: HTTP/1.0 304 Not Modified client server HTTP request msg If-modified-since: HTTP response HTTP/1.0 304 Not Modified object not modified HTTP request msg If-modified-since: HTTP response HTTP/1.0 200 OK object modified Conditional GET: Client-Side Caching

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-37 August 26, 2015 POST The POST method is used to request that the destination server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URL in the Request-Line. POST is designed to allow a uniform method to cover the following functions:  Annotation of existing resources;  Posting a message to a bulletin board, newsgroup, mailing list,or similar group of articles;  Providing a block of data, such as the result of submitting a form, to a data-handling process;  Extending a database through an append operation. POST Command

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-38 August 26, 2015 Get method:  Web page often includes form input  Input is uploaded to server in URL field of request line: Post method:  Web page often includes form input  Input is uploaded to server in entity body www.somesite.com/cgi.bin/form.cgi ?firstname=ali&lastnme=doostmohammadi URL Encoded data URL encodingA-Za-z0-9 *-_ Space + Others %HEX Uploading Form Input

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-39 August 26, 2015  HTTP/1.0  GET  POST  HEAD  asks server to leave requested object out of response  HTTP/1.1  GET, POST, HEAD  PUT  uploads file in entity body to path specified in URL field  DELETE  deletes file specified in the URL field Other Methods OPTIONS, PATCH, COPY, MOVE, DELETE, LINK, UNLINK, TRACE, WRAPPED, extension method. Method Types

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-40 August 26, 2015 1. General Header Fields 2. Request Header Fields 3. Response Header Fields 4. Entity Body Header Fields Header Fields

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-41 August 26, 2015 1. General Header Fields  Keep-Alive  Upgrade  Connection  Forwarded  Cache-Control  MIME- Version  Data  Pragma Type Application Text Image Audio Multipart Video Subtypes  Postscript, msword, Msexel,…  Html, plain(ASCII),…  Jpeg, gif, ief,…  Basic, x-pn-realaudio,…  mixed  mpeg,quicktime Multipurpose Internet Mail Extensions (rfcs822obs, 2045, 2046, 2077) Header Fields

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-42 August 26, 2015 2. Request Header Fields  Accept:  Accept-Language:  Authorization:  From:  Host:  If-Modified-Since:  Proxy-Authorization:  Range:  Refer:  Unless:  User-Agent:  Accept-Encoding:  Cookie: Header Fields

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-43 August 26, 2015 3. Response Header Fields  Location:  Proxy-Authentication:  Public:  Retry-After:  Server:  WWW-Authenticate:  Set-Cookie: Header Fields

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-44 August 26, 2015 4. Entity Body Header Fields  Allow  Content-Encoding  Content-Language  Content-Length  Content-Range  Content-Type  Content-Version  Content-MD5  Derived-From  Expires  Last-Modified  Link  Title  Transfer-Encoding  URL-Header  extension-header Header Fields (cont.)

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-45 August 26, 2015 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 server 404 Not Found  requested document not found on this server In first line in server -> client response message. A few sample codes: HTTP Response Status Codes

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-46 August 26, 2015 Status Codes Categories  Response Categories  Informational:1xx  Successful:2xx  Redirection:3xx  Client Error:4xx (eg. 404 Not found)  Server Error:5xx

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-47 August 26, 2015 Status-Codes  "201" ; Created  "202" ; Accepted  "204" ; No Content  "301" ; Moved Permanently  "200" ; OK  "302" ; Moved Temporarily  "304" ; Not Modified  "400" ; Bad Request  "401" ; Unauthorized  "403" ; Forbidden  "404" ; Not Found  "500" ; Internal Server Error  "501" ; Not Implemented  "502" ; Bad Gateway  "503" ; Service Unavailable  “505” ; HTTP Version Not Supported Status Codes

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-48 August 26, 2015 1. Telnet to your favorite Web server: Opens TCP connection to port 80 (default HTTP server port) at www.eurecom.fr. Anything typed in sent to port 80 at www.eurecom.fr telnet www.eurecom.fr 80 2. Type in a GET HTTP request: GET /~ross/index.html HTTP/1.0 By typing this in (hit carriage return twice), you send this minimal (but complete) GET request to HTTP server 3. Look at response message sent by HTTP server! Trying out HTTP (client side) for Yourself

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-49 August 26, 2015 Authorization : control access to server content  authorization credentials: typically name, password  stateless: client must present authorization in each request  authorization: header line in each request  if no authorization: header, server refuses access, sends WWW authenticate: header line in response client server usual http request msg 401: authorization req. WWW authenticate: usual http request msg + Authorization: usual http response msgusual http request msg + Authorization: usual http response msg time User-Server Interaction: Authorization

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-50 August 26, 2015 Cookies: Keeping “State”-RFC2109  Some Web sites store information in a small text file on your computer. This file is called a cookie.  There are several types of cookies,  you can choose whether to allow some, none, or all of them to be saved on your computer.  If you do not allow cookies at all, you may not be able to  view some Web sites or  take advantage of customization features (such as local news and weather, or stock quotes).

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-51 August 26, 2015 How cookies are used  Created by an Internet site to store information on your computer.  Example, you visit a Web site, it saves a record of the pages you looked at, to help the site customize the view for you the next time you visit.  Cookies can also store personally identifiable information, that can be used to identify or contact you, such as  your name,  e-mail address, or  telephone number.  A Web site only has access to the information you provide.  Once a cookie is saved on your computer, only the Web site that created the cookie can read it.

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-52 August 26, 2015 Persistent/Temporary Cookies  A persistent cookie is one stored as a file on your computer, and it remains there when you close Internet browser.  A temporary or session cookie is stored only for your current browsing session, and is deleted from your computer when you close Internet browser.

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-53 August 26, 2015 First-Party vs. Third-Party cookies  A first-party cookie either originates on or is sent to the Web site you are currently viewing.  A third-party cookie either originates on or is sent to a Web site different from the one you are currently viewing.  Third-party Web sites usually provide some content on the Web site you are viewing. For example, many sites use advertising from third-party Web sites and those third- party Web sites may use cookies.  A common use for this type of cookie is to track your Web page use for advertising or other marketing purposes.  Third-party cookies can either be persistent or temporary.

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-54 August 26, 2015 Unsatisfactory Cookies  Unsatisfactory cookies are cookies that might allow access to  personally identifiable information that  could be used for a secondary purpose without your consent.

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-55 August 26, 2015 What cookies can bring:  authorization  shopping carts  recommendations  user session state (Web e-mail) Cookies and privacy:  cookies permit sites to learn a lot about you  you may supply name and e-mail to sites  search engines use redirection & cookies to learn yet more  advertising companies obtain info across sites aside Cookies and Privacy

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-56 August 26, 2015 There are four components: 1) cookie header line in the HTTP response message 2) cookie header line in HTTP request message 3) cookie file kept on user’s host and managed by user’s browser 4) back-end database at Web site  Example:  Ali access Internet always from same PC  He visits a specific e- commerce site for first time  When initial HTTP requests arrives at site, site creates a unique ID and creates an entry in backend database for ID Many major Web sites use cookies HTTP and Cookies

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-57 August 26, 2015 client server usual http request msg usual http response + Set-cookie: 1678 usual http request msg cookie: 1678 usual http response msgusual http request msg cookie: 1678 usual http response msg cookie- specific action cookie- specific action server creates ID 1678 for user entry in backend database access Cookie file amazon: 1678 ebay: 8734 Cookie file ebay: 8734 Cookie file amazon: 1678 ebay: 8734 one week later:Example Cookie File Samples

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-58 August 26, 2015 HTTP TCP IP Routers Files packets Routers HTTP over TCP

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-60 August 26, 2015  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 file transfer FTP server FTP user interface FTP client local file system remote file system user at host FTP: the File Transfer Protocol

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-61 August 26, 2015 File Transfer and Access Protocols (FTP, TFTP, SFTP, NFS) RFCs1  2640 –Internationalization of the File Transfer Protocol  2624 –NFS Version 4 Design Considerations  2623 –NFS Version 2 and Version 3 Security Issues and the NFS Protocol’s Use of RPCSEC_GSS and Kerberos V5  2577 –FTP Security Considerations

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-62 August 26, 2015 File Transfer and Access Protocols (FTP, TFTP, SFTP, NFS) RFCs1  2428 –FTP Extensions for IPv6 and NATs  2389 –Feature negotiation mechanism for the File Transfer Protocol  2349, 1784 - TFTP Timeout Interval and Transfer Size Options  2348, 1783 - TFTP Blocksize Option

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-63 August 26, 2015 File Transfer and Access Protocols (FTP, TFTP, SFTP, NFS) RFCs2  2347, 1782 - TFTP Option Extension  2228 –FTP Security Extensions  2224 –NFS URL Scheme  2204 –ODETTE File Transfer Protocol  2090 –TFTP Multicast Option  2055 –WebNFS Server Specification  2054 –WebNFS Client Specification

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-64 August 26, 2015 File Transfer and Access Protocols (FTP, TFTP, SFTP, NFS) RFCs3  1986 –Experiments with a Simple File Transfer Protocol for Radio Links using Enhanced Trivial File Transfer Protocol (ETFTP)  1813 –NFS Version 3 Protocol Specification  1785 –TFTP Option Negotiation Analysis  1639, 1545 - FTP Operation Over Big Address Records (FOOBAR)  1635 –How to Use Anonymous FTP  1579 –Firewall-Friendly FTP

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-65 August 26, 2015 File Transfer and Access Protocols (FTP, TFTP, SFTP, NFS) RFCs4  1440 –SIFT/UFT: Sender-Initiated/Unsolicited File Transfer  1415 –FTP-FTAM Gateway Specification  1350, 783 - The TFTP Protocol (Revision 2) 1282,  1258 - BSD Rlogin  1235 –Coherent File Distribution Protocol  1094 –NFS: Network File System Protocol specification  1068 –Background File Transfer Program (BFTP)  1037 –NFILE - a file access protocol

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-66 August 26, 2015 File Transfer and Access Protocols (FTP, TFTP, SFTP, NFS) RFCs5  959, 765, 542, 354, 265, 172, 114 - File Transfer Protocol.  949 – FTP unique-named store command.  913 – Simple File Transfer Protocol.  906 – Bootstrap loading using TFTP.  775 – Directory oriented FTP commands.  743 – FTP extension: XRSQ/XRCP.  737 – FTP extension: XSEN.

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-67 August 26, 2015 File Transfer and Access Protocols (FTP, TFTP, SFTP, NFS) RFCs6  697 – CWD command of FTP  691 – One more try on the FTP  686 – Leaving well enough alone  683 – FTPSRV - Tenex extension for paged files  662 – Performance improvement in ARPANET file transfers from Multics  640 – Revised FTP reply codes  630 – FTP error code usage for more reliable mail service

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-68 August 26, 2015 File Transfer and Access Protocols (FTP, TFTP, SFTP, NFS) RFCs7  624 – Comments on the File Transfer Protocol  614 – Response to RFC 607: "Comments on the File Transfer Protocol"  607 – Comments on the File Transfer Protocol  571 – Tenex FTP problem  535 – Comments on File Access Protocol  532 – UCSD-CC Server-FTP facility  520 – Memo to FTP group: Proposal for File Access Protocol

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-69 August 26, 2015 File Transfer and Access Protocols (FTP, TFTP, SFTP, NFS) RFCs8  506 – FTP command naming problem  505 – Two solutions to a file transfer access problem  501 – Un-muddling "free file transfer" 487 – Free file transfer  486 – Data transfer revisited  480 – Host-dependent FTP parameters  479 – Use of FTP by the NIC Journal  478 – FTP server-server interaction - II

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-70 August 26, 2015 File Transfer and Access Protocols (FTP, TFTP, SFTP, NFS) RFCs9  468 – FTP data compression  463 – FTP comments and response to RFC 430  448 – Print files in FTP  438 – FTP server-server interaction  430 – Comments on File Transfer Protocol  418 – Server file transfer under TSS/360 at NASA Ames  414 – File Transfer Protocol (FTP) status and further comments

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-71 August 26, 2015 File Transfer and Access Protocols (FTP, TFTP, SFTP, NFS) RFCs10  412 – User FTP Documentation  385 – Comments on the File Transfer Protocol  310 – Another Look at Data and File Transfer Protocols  294 – The Use of "Set Data Type" Transaction in File Transfer Protocol  281 – Suggested addition to File Transfer Protocol  269 – Some Experience with File Transfer  264, 171 - The Data Transfer Protocol

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-72 August 26, 2015 File Transfer and Access Protocols (FTP, TFTP, SFTP, NFS) RFCs11  250 – Some thoughts on file transfer  242 – Data Descriptive Language for Shared Data  238 – Comments on DTP and FTP proposals  163 – Data transfer protocols  141 – Comments on RFC 114: A File Transfer Protocol  133 – File Transfer and Recovery

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-73 August 26, 2015  FTP client contacts FTP server at port 21, specifying TCP as transport protocol.  Client obtains authorization over control connection. remote directory  Client browses remote directory by sending commands over control connection.  When server receives a command for a file transfer, server opens a TCP data conn. to client at port 20. FTP client FTP server TCP control connection port 21 (persistent) TCP data connection port 20(nonpersistent) FTP: Separate Control, Data Connections1

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-74 August 26, 2015 USER FILE SYSTEM USER INTERFACE USER PI USER DTP SERVER DTP FILE SYSTEM SERVER PI FTP REPLIES FTP COMMANDS DATA CONNECTION PI: Protocol Interpreter DTP: Data Transfer Process FTP MODEL1

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-75 August 26, 2015  In the model, the user-protocol interpreter (PI) initiates the control connection.  The control connection follows the Telnet protocol.  FTP commands are generated by the user-PI and transmitted to the server process via the control connection.  Standard replies are sent from the server-PI to the user-PI over the control connection in response to the commands. Control Connection Initiation

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-76 August 26, 2015  The FTP commands specify the parameters for the data connection  (data port, transfer mode, representation type, and structure) and  the nature of file system operation (store, retrieve, append, delete, etc.).  The user-DTP should "listen" on the specified data port, and the server initiate the data connection and data transfer in accordance with the specified parameters.  Note that the data connection may be used for simultaneous sending and receiving. Data Connection Initiation

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-77 August 26, 2015  The FTP uses the Telnet protocol on the control connection.  This can be achieved in two ways:  First, the user-PI or the server-PI may implement the rules of the Telnet Protocol directly in their own procedures; or,  Second, the user-PI or the server-PI may make use of the existing Telnet module in the system. Relationship between FTP and Telnet

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-78 August 26, 2015  After transferring a file, server closes port 20.  Server opens a second TCP data connection to transfer the next file.  Control connection: “out of band”  (http is also a file transfer protocol. It is stateless, in-band and a push/pull protocol. FTP is also a push/pull one)  FTP server maintains “state”: current directory, earlier authentication FTP: Separate Control, Data Connections

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-79 August 26, 2015 Sample commands:  sent as ASCII text over control channel (4 uppercase ASCII characters)  USER username  PASS password  LIST return list of file in current directory  RETR filename retrieves (gets) file  STOR filename stores (puts) file onto remote host Sample return codes  status code and phrase (as in HTTP)  331 Username OK, password required  125 data connection already open; transfer starting  425 Can’t open data connection  452 Error writing file ftp://ftpserver.shahroodut.ac.ir/dir1/filename.extension FTP Commands, Responses

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-80 August 26, 2015  2.1 Principles of app layer protocols  clients and servers  app requirements  2.2 Web and HTTP  2.3 FTP  2.4 Electronic Mail  SMTP, POP3, IMAP, HTTP  2.5 DNS  2.6 Socket programming with TCP  2.7 Socket programming with UDP  2.8 Building a Web server  2.9 Content distribution  Network Web caching  Content distribution networks  P2P file sharing Chapter 2 Outline

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-81 August 26, 2015 Three major components:  user agents  mail servers  simple mail transfer protocol: SMTP User Agent  Sometimes is called: “mail reader”  composing, editing, reading mail messages  e.g., Eudora, Outlook, elm, Netscape Messenger  outgoing, incoming messages stored on server user mailbox outgoing message queue mail server user agent user agent user agent mail server user agent user agent mail server user agent SMTP Electronic Mail

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-82 August 26, 2015 Mail Servers  mailbox contains incoming messages for user  message queue of outgoing (to be sent) mail messages  SMTP protocol between mail servers to send email messages  “client”: sending mail server (sending agent)  “server”: receiving mail server (receiving agent) mail server user agent user agent user agent mail server user agent user agent mail server user agent SMTP Electronic Mail: Mail Servers

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-83 August 26, 2015  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  closure  command/response interaction  commands: ASCII text  response: status code and phrase  messages must be in 7-bit ASCII Electronic Mail: SMTP [RFC 2821]

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-84 August 26, 2015 1) User1 (sender) uses UA to compose message to user2@yahoo.com. 2) User1’s UA sends message to his mail server; message placed in message queue. 3) Client side of SMTP opens TCP connection with User2’s mail server. 4) SMTP client sends User1’s message over the TCP connection. 5) User2’s mail server places the message in User2’s mailbox. 6) User2 invokes his/her user agent to read message. UA: User Agent Scenario: User1 sends message to User2 user agent mail server mail server user agent 1 2 3 4 5 6 User1 User2 user2@yahoo.com user1@webmail.shahroodut.ac.ir webmail.shahroodut.ac.ir yahoo.com

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-85 August 26, 2015  telnet servername 25  see 220 reply from server  enter HELO, MAIL FROM, RCPT TO, DATA, QUIT commands above lets you send email without using email client (reader) Try SMTP Interaction for Yourself:

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-86 August 26, 2015  SMTP uses persistent connections.  SMTP requires message (header & body) to be in 7-bit ASCII  SMTP server uses CRLF.CRLF to determine end of message Comparison with HTTP:  HTTP: pull  SMTP: push  both have ASCII command/response interaction, status codes.  HTTP: each object encapsulated in its own response message.  SMTP: multiple objects sent in multipart message. SMTP: Final Words

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-87 August 26, 2015 SMTP: protocol for exchanging email 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 Mail Message Format.

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-88 August 26, 2015 Mail Massage smsrms: TCP connection establishment on port 25 smsrms: SMTP handshake (HELO, MAIL, FROM, RCPT TO, DATA, commands, and 220, 250, 354, 221 status codes) smsheader body. smsQUIT rms221 yahoo.com closing connection SMTP Message Transfer Between Mail Servers sms = sending mail server rms = receiving mail server

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-89 August 26, 2015Example user agent mail server mail server user agent 1 2 3 4 5 6 User1 User2 user2@yahoo.com user1@webmail.shahroodut.ac.ir webmail.shahroodut.ac.ir yahoo.com

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-90 August 26, 2015 Mail Massage user1 user2 from user1 to user2 sms: TCP connection request on port 25 rms: 220 yahoo.com accepts connection sms: HELO webmail.shahroodut.ac.ir is ready rms: 250 Hello webmail.shahroodut.ac.ir sms: MAIL FROM: rms: 250 user1@webmail.shahroodut.ac.ir... Sender ok sms: RCPT TO: rms: 250 user2@yahoo.com... Recipient ok sms: DATA rms: 354 Enter mail, end with "." on a line by itself sms: From: user1@webmail.shahroodut.ac.ir sms: To: user2@yahoo.com. sms:. rms: 250 Message accepted for delivery sms: QUIT rms: 221 yahoo.com closing connection Example: SMTP Interaction

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-91 August 26, 2015  MIME: Multipurpose Internet Mail Extension RFC 2045, 2056  additional lines in message header declare MIME content type From: User1@webmail.shahroodut.ac.ir To: User2@yahoo.com Subject: Picture of shahroodut cc: User3@tu.ac.ir MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Type: image/jpeg base64 encoded data....................................base64 encoded data. MIME version method used to encode data multimedia datatype, subtype, parameter declaration encoded data Message Format: Multimedia Extensions

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-92 August 26, 2015 Text  example subtypes: plain, html Image  example subtypes: jpeg, gif Audio  example subtypes: basic (8-bit mu-law encoded), 32kadpcm (32 kbps coding) Video  example subtypes: mpeg, quicktime Application  other data that must be processed by reader before “viewable”  example subtypes: msword, octet-stream MIME (RFCs2045, 2046, 2077) Types Content-Type: type/subtype; parameters 204520462077204520462077

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-93 August 26, 2015 From: user1@webmail.shahroodut.ac.ir To: user2@yahoo.com Subject: photo of shahroodut. MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=StartOfNextPart --StartOfNextPart Dear User1, Hear is a photo of shahroodut in 1388 winter. --StartOfNextPart Content-Transfer-Encoding: base64 Content-Type: image/jpeg base64 encoded data....................................base64 encoded data --StartOfNextPart Do you like to receive more pictures?. Multipart Type

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-94 August 26, 2015  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 messages on server  HTTP: Hotmail, Yahoo! Mail, Shahroodut, etc. user agent sender’s mail server user agent SMTP access protocol receiver’s mail server Sender Receiver Mail Access Protocols

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-95 August 26, 2015  RFC 1939 / Std 53  To retrieve emails from server (POP3 server)  Server port number: 110  Three states  Authorization State  Transaction State  Update State POP3-Post Office Protocol - Version 3

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-96 August 26, 2015 POP3 Commands  Authorization State  USER username  PASS password  APOP name digest  Transaction State  STAT  LIST [msgNo]  RETR msgNo  DELE msgNo  NOOP  RSET  TOP msgNo line  UIDL [msgNo]  Update State  QUIT

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-97 August 26, 2015 authorization phase  client commands:  user: declare username  pass: password  server responses  +OK  -ERR transaction phase, client:  list: list message numbers  retr: retrieve message by number  dele: delete  quit C: list S: 1 498 S: 2 912 S:. C: retr 1 S: S:. C: dele 1 C: retr 2 S: S:. C: dele 2 C: quit S: +OK POP3 server signing off S: +OK POP3 server ready C: user USER1 S: +OK C: pass zxcdvf S: +OK user successfully logged on POP3 Protocol

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-98 August 26, 2015 More about POP3  Previous example uses “download and delete” mode.  “Download” brings the mail into client computer.  “Delete” removes the mail from the mail server. User1 cannot re-read e-mail if he/she changes client computer.  “Download-and-keep”: leaves the message on the mail server.  POP3 is stateless across sessions. IMAP  Keep all messages in one place: the server  Allows user to organize messages in folders  IMAP keeps user state across sessions:  names of folders and mappings between message IDs and folder name POP3 (more) and IMAP

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-99 August 26, 2015  2.1 Principles of app layer protocols  clients and servers  app requirements  2.2 Web and HTTP  2.3 FTP  2.4 Electronic Mail  SMTP, POP3, IMAP, HTTP  2.5 DNS  2.6 Socket programming with TCP  2.7 Socket programming with UDP  2.8 Building a Web server  2.9 Content distribution  Network Web caching  Content distribution networks  P2P file sharing Chapter 2 Outline

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-100 August 26, 2015 DNS RFCs1  2673 –Binary Labels in the Domain Name System.  2672 –Non-Terminal DNS Name Redirection.  2671 –Extension Mechanisms for DNS (EDNS0).  2606 –Reserved Top Level DNS Names.  2541 –DNS Security Operational Considerations.  2540 –Detached Domain Name System (DNS) Information.  2539 –Storage of Diffie-Hellman Keys in the Domain Name System (DNS).

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-101 August 26, 2015 DNS RFCs2  2535 –Domain Name System Security Extensions.  2517 –Building Directories from DNS: Experiences from WWWSeeker.  2352, 2240 - A Convention For Using Legal Names as Domain Names.  2317 –Classless IN-ADDR.ARPA delegation.  2308 –Negative Caching of DNS Queries (DNS. NCACHE) 2230 –Key Exchange Delegation Record for the DNS.  2219 –Use of DNS Aliases for Network Services.  2182 –Selection and Operation of Secondary DNS Servers.

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-102 August 26, 2015 DNS RFCs3  2181 –Clarifications to the DNS Specification.  2137 –Secure Domain Name System Dynamic Update.  2136 –Dynamic Updates in the Domain Name System (DNS UPDATE).  2065 –Domain Name System Security Extensions.  2052 –A DNS RR for specifying the location of services (DNS SRV).  2010 –Operational Criteria for Root Name Servers.  1996 –A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY).  1995 –Incremental Zone Transfer in DNS.

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-103 August 26, 2015 DNS RFCs4  1982 –Serial Number Arithmetic.  1912, 1537 - Common DNS Operational and Configuration Errors.  1876 –A Means for Expressing Location Information in the Domain Name System.  1794 –DNS Support for Load Balancing.  1713 –Tools for DNS debugging.  1712 –DNS Encoding of Geographical Location.  1706, 1637, 1348 - DNS NSAP Resource Records.  1591 –Domain Name System Structure and Delegation.

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-104 August 26, 2015 DNS RFCs5  1536 –Common DNS Implementation Errors and Suggested Fixes.  1535 –A Security Problem and Proposed Correction With Widely Deployed DNS Software  1480, 1386 - The US Domain.  1464 –Using the Domain Name System To Store Arbitrary String Attributes.  1394 –Relationship of Telex Answerback Codes to Internet Domains.  1183 –New DNS RR Definitions.  1101 –DNS encoding of network names and other types.  1035 –Domain names - implementation and specification.

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-105 August 26, 2015 DNS RFCs6  1034 –Domain names - concepts and facilities  1033 –Domain administrators operations guide  1032 –Domain administrators guide  1031 –MILNET name domain transition  973 – Domain system changes and observations  953, 811 - Hostname Server  921, 897 - Domain name system implementation schedule - revised  920 – Domain requirements

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-106 August 26, 2015 DNS RFCs7  883 – Domain names: Implementation specification  882 – Domain names: Concepts and facilities  881 – Domain names plan and schedule  830 – Distributed system for Internet name service  819 – Domain naming convention for Internet user applications  799 – Internet name domains  756 – NIC name server - a datagram-based information utility  752 – Universal host table

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-107 August 26, 2015 People: many identifiers:  SSN, name, passport # Internet hosts, routers:  IP address (32 bit) - used for addressing datagrams  “name”, e.g., www.shahroodut.ac.ir - used by humans Q: map between IP addresses and name ? Domain Name System:  distributed database implemented in hierarchy of many name servers  application-layer protocol host, routers, name servers to communicate to resolve names (address/name translation)  note: core Internet function, implemented as application-layer protocol  complexity at network’s “edge” DNS: Domain Name System RFC1034

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-108 August 26, 2015 Why DNS  Although DNS is most commonly associated with the Internet, private networks also use DNS because of the following benefits:  Convenience: User-friendly names are easier for people to remember than numerical IP addresses.  Consistency: IP addresses may change, but the server names can remain constant.  Simplicity: Users need to learn only one naming convention to find resources on either the Internet or on an intranet.

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-109 August 26, 2015 DNS: Domain Name System  The Domain Name System is a distributed database system that can serve as the foundation for name resolution in a TCP/IP network.  DNS is used by most internetworking software, such as web browsers and electronic mail programs, to locate servers and to resolve, or map, a user-friendly name of a computer to its IP address.

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-110 August 26, 2015 DNS Components  To understand how DNS maps names to IP addresses, you will need to understand the following five components:  1. Domain Name Space  Name Structure,  2. Zone  Zone data base file,  3. Name Server (DNS Server)  DNS Root Servers,  4. DNS Resolver,  5. Protocol  Forward Lookup Query  Caching.

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-111 August 26, 2015 1. Domain Name Space  The domain name space has a hierarchical structure.  The root domain is at the top, and it is represented by a period.  Below the root domain, the top-level, or 1st-level domains can be an organizational type, such as com or edu., or a geographic location, such as ir. for IRAN.  Second-level domains are registered to individuals or organizations, such as microsoft.com, the Microsoft Corporation domain.  Second-level domains can have many sub domains. …and any domain can have hosts.

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-112 August 26, 2015 1. Domain Name Space “.” Root Domain Top Level or First Level Domain org. edu. com. ir. Second Level Domain (Registered to Individuals or Organizations) ac.ir. sut.ac.ir. ce.sut.ac.ir.  Any domain can have hosts.  A host is a specific computer within a domain.  Shahrood University of Technology ‘s Domain: sut.ac.ir. host subdomain 2nd-level domain top-level domain webmail. sut. ac. ir. root fully qualified domain name, or FQDN

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-113 August 26, 2015 1. Domain Name Space: Name Structure Host name. …. Subdomain-name. 2 nd -level –name. 1 st -level-name. Max: 255 Characters Max: 63 Characters  ICANN: Internet Corporation For Assigned Names and Numbers) http://icann.org  Level m -name authority appoints level m-1 -names.  Example:  ir. is controlled by ( فيزيک نظری )  shahroodut.ir. is appointed by ( فيزيک نظری ) and controlled by Shahrood University of Technology. Root

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-114 August 26, 2015 Names are Valuable new

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-115 August 26, 2015 1. Domain Name Space: Top Levels  com: commercial  edu: educational institute  ac: Academic, research institute  int: international organization  gov: US federal goverment  org: US armed forces  net: network providers  biz: business  name: people’s name  pro: professions  tv: TV stations and networks  …  ir: Iran  nl: Netherlands  jp: Japan  uk: England  … For the most up-to-date information about new top level domains, consult: http://www.icann.org/tlds

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-116 August 26, 2015  For administrative purposes, domains can be organized into zones.  As you can see in this example, a zone is a discrete and contiguous area of the domain name space.  One reason to divide a name space into zones is to delegate authority for different portions of it.  One very large domain could be difficult to administer.  The name-to-IP address data for computers located in a zone, is stored in a zone database file on a DNS name server. 2. Zones ir. ac.ir. Name Server Name Server Name Server Zone Database File Zone Database File Zone Database File

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-117 August 26, 2015  A zone database storing resource records (RR) of the zone for which a server is authoritative.  Type=NS  name is domain (e.g. shahroodut.ac.ir)  value is IP address of authoritative name server for this domain  Type=A  name is hostname  value is IP address  Type=CNAME  name is alias name for some “canonical” (the real) name www.ibm.com is really servereast.backup2.ibm.com  value is canonical name  Type=MX  value is name of mail-server associated with name 2. Zone Database File RR format: (Name, TTL, Class, Type, Value)

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-118 August 26, 2015 2. Zone Database File: Type Description Example Resource Record Format DescriptionTypeNumber www 1D IN A 10.1.1.1Network addressA1 @ 1D IN NS na.av.comAuthoritative name server NS2 Mail destination; now replaced by MXMD3 Mail forwarder; now replaced by MXMF4 Canonical alias nameCNAME5 Start of zone authoritySOA6 Mailbox domain nameMB7 Mailbox memberMG8 Mail rename domainMR9 Null resource recordNULL10 Well-Known serviceWKS11 RR format: (Name, TTL, Class, Type, Value)

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-119 August 26, 2015 2. Zone Database File: Type Description Example Record FormatDescriptionTypeNumber Pointer to a domain namePTR12 www 1D IN HINFO SolarisHost informationHINFO13 Mailbox informationMINFO14 Mail exchangeMX15 System 1 IN TXT “This is a new system” Text stringsTXT16 Responsible personRP17 AFS-type servicesAFSDB18 X.25 addressX.2519 ISDN addressISDN20 Route throughRT21 RR format: (Name, TTL, Class, Type, Value)

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-120 August 26, 2015 2. Zone Database File: Example mail.sut.ac.ir 1 D IN HINFO Sun Unix mail.sut.ac.ir 1 D IN A 130.37.16.112 mail.sut.ac.ir 1 D IN A 192.31.231.165 mail.sut.ac.ir 1 D IN MX 1 mail.sut.ac.ir mail.sut.ac.ir 1 D IN MX 2 ms.sut.ac.ir post.sut.ac.ir. 1 D IN CNAME mail.sut.ac.ir ftp.sut.ac.ir. 1 D IN CNAME file.sut.ac.irNameTTLClassTypeValue Canonical NamesReal names Primary mail server Secondary mail server Host Information

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-121 August 26, 2015  A DNS server is a computer that runs a DNS server program, such as Berkeley Internet NAME Domain (BIND).  DNS Servers contain DNS database files.  They resolve name resolution queries issued by DNS clients. Why not centralize DNS?  single point of failure  traffic volume  distant centralized database  maintenance doesn’t scale!  no server has all name- to-IP address mappings. does scale! 3. DNS Name Servers

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-122 August 26, 2015 Distributed, Hierarchical Database Root DNS Servers org DNS Servers edu DNS Servers com DNS Servers ir DNS Servers ac.ir DNS Servers shahroodut.ac.ir DNS Servers

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-123 August 26, 2015 3. DNS Name Servers  One name server holds the primary zone database file for a zone.  That name server is said to "have authority" for making changes to the zone file.  A copy of the zone file may be stored on other servers to balance network load.  These copies are referred to as secondary zone database files.  The secondary zone database files are updated regularly from the primary zone database file by a process called zone transfer. ir. ac.ir. Name Server Secondary Zone Database File Name Server Primary Zone Database File

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-124 August 26, 2015 Zone Owner’s Responsibilities  Authoritatively maintain the zone’s data.  Arrange for replicated name servers for the zone  Typically, zone data is maintained in a primary file and loaded into a primary server  Replicated servers use TCP-based zone transfers specified in DNS protocol to refresh their data.  Therefore, either servers can answer name resolution queries for that zone.  A name server authoritative for a zone does not have to be in that zone.  A name server can handle any number of zones, which don’t have to be contiguous.

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-125 August 26, 2015 (b) (b) USC-ISI Marina del Rey, CA (l) (l) ICANN Marina del Rey, CA (e) (e) NASA Mt View, CA (f) (f) Internet Software C. Palo Alto, CA (i) (i) NORDUnet Stockholm, Sweden (k) (k) RIPE London, UK (m) (m) WIDE Tokyo, Japan (a) (a) NSI Herndon, VA (c) (c) PSInet Herndon, VA (d) (d) U Maryland College Park, MD (g) (g) DISA Vienna, VA (h) (h) ARL Aberdeen, MD (j) (j) NSI (TBD) Herndon, VA  contacted by local name server that can not resolve name  root name server:  Either, contacts authoritative name server  gets mapping  returns mapping to local name server  Or, introduces authoritative name server to local name server. 13 root name servers worldwide 3. DNS Root Name Servers

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-126 August 26, 2015 13 Root Name Servers  F gets 270,000,000+ hits per day.  Other root servers are comparable.  Top Level Domain servers answer 5,000,000,000 per day.

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-127 August 26, 2015 3. DNS Root Name Servers Root Servers ServerOperatorLocationsIP Addr Home ASN A VeriSign Global Registry Services Dulles VA198.41.0.419836 B Information Sciences Institute Marina Del Rey CA IPv4: 192.228.79.201 IPv6: 2001:478:65::53 tba C Cogent Communications Herndon VA; Los Angeles; New York City; Chicago 192.33.4.122149 D University of MarylandCollege Park MD128.8.10.9027 E NASA Ames Research CenterMountain View CA192.203.230.10297 F Internet Systems Consortium, Inc. Ottawa; Palo Alto; San Jose CA; New York City; San Francisco; Madrid; Hong Kong; Los Angeles; Rome; Auckland; Sao Paulo; Beijing; Seoul; Moscow; Taipei; Dubai; Paris; Singapore; Brisbane; Toronto; Monterrey; Lisbon; Johannesburg;Tel Aviv;Jakarta; Munich; IPv4: 192.5.5.241 IPv6: 2001:500::1035 3557 G U.S. DOD Network Information Center Vienna VA192.112.36.4568

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-128 August 26, 2015 3. DNS Root Name Servers Root Servers ServerOperatorLocationsIP Addr Home ASN H U.S. Army Research LabAberdeen MD IPv4: 128.63.2.53 IPv6:2001:500:1::803f:235 13 I Autonomica/NORDUnet Stockholm; Helsinki; Milan; London; Geneva; Amsterdam; Oslo; Bangkok; Hong Kong; Brussels; Frankfurt; Bucharest; Ankara; Chicago; Washington DC; Tokyo; Kuala Lumpur 192.36.148.1729216 J VeriSign Global Registry Services Dulles VA (2 locations); Mountain View CA; Seattle WA; Amsterdam; Atlanta GA; Los Angeles CA; Miami; Stockholm; London; Tokyo; Seoul; Singapore; Sterling VA (2 locations, standby) 192.58.128.3026415 K Reseaux IP Europeens - Network Coordination Centre London (UK); Amsterdam (NL); Frankfurt (DE); Athens (GR); Doha (QA); Milan (IT) IPv4: 193.0.14.129 IPv6: 2001:7fd::1 25152 L Internet Corporation for Assigned Names and Numbers Los Angeles198.32.64.1220144 M WIDE ProjectTokyo; Seoul (KR); Paris (FR) 202.12.27.33 IPv6: 2001:dc3::35 7500

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-129 August 26, 2015 Autonomous System  On the Internet, an Autonomous System (AS) is the unit of router policy,  Either a single network  Or a group of network that is controlled by a common network administrator (or group of administrators) on behalf of a single administrative entity (such as a university, a business enterprise, or a business division).  An autonomous system is also sometimes referred to as a routing domain.  An autonomous system is assigned a globally unique number, sometimes called an Autonomous System Number (ASN).

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-130 August 26, 2015 4. Resolver  A DNS resolver is a service that uses the DNS protocol to query for information from DNS servers.  Function of DNS resolver is performed by the DNS client service.  DNS service uses UDP in transport layer.

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-131 August 26, 2015 Root name server:  may not know authoritative name server  may know intermediate name server: who to contact to find authoritative name server requesting host www.icann.org root name server local name server dns.shahroodut.ac.ir 1 2 3 4 5 6 authoritative name server dns.icann.org intermediate name server (Top level) dns.org 7 8 5. DNS Protocol: Forward Lookup Query a:answer r:referral q:query q q q a a a a q

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-132 August 26, 2015 recursive query:  puts burden of name resolution on contacted name server  heavy load? iterated query:  contacted server replies with name of server to contact  “I don’t know this name, but ask this server” requesting host www.icann.org root name server local name server dns.shahroodut.ac.ir 1 2 3 4 5 6 authoritative name server dns.icann.org intermediate name server (Top Level) dns.org 7 8 iterated query 5. DNS Protocol: Forward Lookup Query a:answer r:referral q:query a q q q q a r a

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-133 August 26, 2015 5. DNS Protocol: Forward Lookup Query requesting host www.icann.org root name server local name server dns.shahroodut.ac.ir 1 2 3 4 5 6 authoritative name server dns.icann.org intermediate name server (Top Level) dns.org 7 8 iterated query a:answer r:referral q:query a q r q q q r a

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-134 August 26, 2015 5. DNS Protocol: Forward Lookup Query  The query contains the FQDN of the requested computer.  A forward lookup query is a request to map a name to an IP address. “.” org. edu. com. ir. ac.ir. shahroodut.ac.ir. Local Name Server Root Name Server Client www.icann.org. Authorized name server for org. zone Forward Lookup Query: What is IP Address of www.icann.org IP Address of www.icann.org is 142.12.01.23

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-135 August 26, 2015 DNS Resolver and Local DNS Server Application DNS resolver Local DNS server 1 10 DNS cache DNS query 2 DNS response 9 Root server 3 4 Top-level domain server 5 6 Second-level domain server 7 8 Caching based on a time-to-live (TTL) assigned by the DNS server responsible for the host name to reduce latency in DNS translation.

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-136 August 26, 2015  once (any) name server learns mapping, it caches mapping  cache entries timeout (disappear) after some time  Top Level Domain servers typically cached in local name 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 5. DNS Protocol: Caching and Updating Records

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-137 August 26, 2015 DNS protocol : query and reply messages, 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 5. DNS Protocol Messages identificationflags number of questionsnumber of answer RRs number of authority RRsnumber of additional RRs questions (variable number of questions) answers (variable number of resource records) authority (variable number of resource records) additional information (variable number of resource records) 12bytes

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-138 August 26, 2015 identificationflags number of questionsnumber of answer RRs number of authority RRsnumber of additional RRs questions (variable number of questions) answers (variable number of resource records) authority (variable number of resource records) additional information (variable number of resource records) Name, Type fields for a query RRs in response to query records for authoritative servers additional “helpful” info that may be used 5. DNS Protocol Messages 12bytes

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-139 August 26, 2015 Inserting records into DNS  Example: just created startup “Network Utopia”  Register name networkuptopia.com at a registrar (e.g., Network Solutions)  Need to provide registrar with names and IP addresses of your authoritative name server (primary and secondary)  Registrar inserts two RRs into the com TLD server: (networkutopia.com, dns1.networkutopia.com, NS) (dns1.networkutopia.com, 212.212.212.1, A)  Put in authoritative server Type A record for www.networkuptopia.com and Type MX record for networkutopia.com How do people get the IP address of your Web site?

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-140 August 26, 2015 Example: Set Debug Command > set debug > www.goole.com Server: jupitr.shahroodut.ac.ir Address: 194.225.228.4 ------------------------------- Got answer: HEADER: opcode = QUERY, id = 11, rcode = NOERROR header flags: response, want recursion, recursion avail. questions = 1, answers = 4, authority records = 6, additional = 0 QUESTIONS: www.google.com, type = A, class = IN ANSEWRS: ->www.google.com cannonical name = www.1.google.com ttl = 900 ->www.1.google.com internet address = 66.102.9.147 ttl = 176 ->www.1.google.com internet address = 66.102.9.99 ttl = 176 ->www.1.google.com internet address = 66.102.9.104 ttl = 176 AUTHORITY RECORDS: ->1.google.com nameserver = b.1.google.com ttl = 37098 -> 1.google.com nameserver = c.1.google.com ttl = 37098 -> 1.google.com nameserver = d.1.google.com ttl = 37098 -> 1.google.com nameserver = e.1.google.com ttl = 37098 -> 1.google.com nameserver = g.1.google.com ttl = 37098 -> 1.google.com nameserver = a.1.google.com ttl = 37098 -------------------- Non-authoritative answer: Name: www.1.google.com Addresses: 66.102.9.147, 66.102.9.99, 66.102.9.104 Aliases: www.google.com

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-142 August 26, 2015 Using Ports to Identify Services Web server (port 80) Client host Server host 128.2.194.242 Echo server (port 7) Service request for 128.2.194.242:80 (i.e., the Web server) Web server (port 80) Echo server (port 7) Service request for 128.2.194.242:7 (i.e., the echo server) OS Client Client host

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-143 August 26, 2015 Network Application-Communication  Network Applications communicates through a network.  API is a programming means, either a library or part of OS.  API provides the communication functionality for the Network Applications (Processes). Application Program Interface (API) Communication Software & Hardware Platform (OS + Hardware) Application Software (Network Application) OS API comes as a library

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-144 August 26, 2015 API Technologies-Sockets  Sockets (earliest technology)  Low level functions for the communication  Socket,  ServerSocket,  ConnectionSocket,  ClientSocket,  DatagramSocket,  Send,  Read,  Write,  Close,  Accept

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-145 August 26, 2015 API Technologies-RPC  Remote Procedure Call (RPC)  Client code invokes a procedure on a remote server.  RPCs support a wire format common to all platforms.  Client and server translate from their binary format into the wire format.  Each RPC involves four translation:  Client to wire format,  Wire to server format,  Server back to wire (for the return value),  Wire format back to client format.

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-146 August 26, 2015 API Technologies-Components  Components: Components Look and act like objects,  CORBA (common object request Broker Architecture)  COM,  COM +,  DCOM (Distributed Component Object Model)

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-147 August 26, 2015 Socket API  introduced in BSD4.1 UNIX, 1981  explicitly created, used, released by apps  client/server paradigm  two types of transport service via socket API:  unreliable datagram  reliable, byte stream- oriented Goal: learn how to build client/server application that communicate using sockets Socket Programming Socket  a host-local, application- created, OS-controlled interface  a “door” into which application process can both  send and  receive messages to/from another application process

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-148 August 26, 2015 Socket: a door between application process and end- end-transport protocol (UDP or TCP) TCP service: reliable transfer of bytes from one process to another process socket controlled by application developer controlled by operating system client or server process socket controlled by application developer controlled by operating system client or server Network TCP with buffers,variables buffers,variables Socket Programming Using TCP

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

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-150 August 26, 2015Sockets Client socket Connection socket Welcoming socket Three-way handshake Client process Server process Client IP Address & Port Number Server IP Address & Port Number2 Server IP Address & Port Number1 bytes send read write

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-151 August 26, 2015 1) Example client-server app. in Java: 2) Client 1) reads line from standard input (keyboard) ( inFromUser stream) 2) sends to server via socket ( outToServer stream) 3) Server 1) reads line from socket 2) converts line to uppercase, 3) sends back to client 4) Client 1) reads ( inFromServer stream), 2) prints modified line from socket on its standard output (monitor) Example: Socket Programming with TCP

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-152 August 26, 2015 Example: 3 streams and 1 socket Client Process ClientSocket outTOServer inFormUser inFormServer Input Stream Output Stream Input Stream TCP socket To transport layer From transport layer

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-153 August 26, 2015  A stream is a sequence of characters that flow into or out of a process.  An input stream is attached to some input source for the process, eg, keyboard or socket.  An output stream is attached to an output source, eg, monitor or socket.Streams

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-154 August 26, 2015 wait for incoming connection request connectionSocket = welcomeSocket.accept() create socket, port= x, for incoming request: welcomeSocket = ServerSocket() create socket, connect to hostid, port= x clientSocket = Socket() close connectionSocket read reply from clientSocket close clientSocket Server (running on hostid ) Client send request using clientSocket read request from connectionSocket write reply to connectionSocket TCP connection setup Client/Server Socket Interaction: TCP

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-155 August 26, 2015 import java.io.*; import java.net.*; class TCPClient { public static void main(String argv[ ]) throws Exception { String sentence; String modifiedSentence; BufferedReader inFromUser = new BufferedReader(new InputStreamReader(System.in)); Socket clientSocket = new Socket("hostname", 6789); Creates input stream Creates client socket, TCP connection to server Example: TCPClient.java server name server port no. import Statements make Java classes available networking class class: is a collection of data and methods that operate on that data

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-156 August 26, 2015 DataOutputStream outToServer = new DataOutputStream(clientSocket.getOutputStream()); BufferedReader inFromServer = new BufferedReader(new InputStreamReader(clientSocket.getInputStream())); sentence = inFromUser.readLine(); outToServer.writeBytes(sentence + '\n'); modifiedSentence = inFromServer.readLine(); System.out.println ("FROM SERVER: " + modifiedSentence ); clientSocket.close(); } Creates input stream attached to socket Sends line to server Reads line from server Example: TCPClient.java (cont.) Creates output stream attached to socket

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-157 August 26, 2015 Code Descriptions-TCPClient.java import java.io.*;  java.io and java.net are java packages.  The java.io package contains classes for  input (BufferedReader)  output (DataOutputStream) streams. import java.net.*;  The java.net package provides classes for network support.  It contains the  Socket (clientSocket object is derived from the Socket class) and  ServerSocket classes.

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-158 August 26, 2015 Code Descriptions-TCPClient.java class TCPClient { public static void main(String argv[ ]) throws Exception {......} }  First is beginning of a class definition block.  Class definition for the class named TCPClient.  A class contains variables and methods. The class TCPClient has no class variables and exactly one method, the main() method.  Java interpreter executes an application, starts by calling the class's main method. The main method then calls all the other methods required to run the application.

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-159 August 26, 2015 Code Descriptions-TCPClient.java String sentence; String modifiedSentence;  These lines declare objects of type String.  Object sentence is string typed by user and sent to server.  Object modifiedSentence is the string obtained from the server and sent to the user's standard output. BufferedReader inFromUser = new BufferedReader (new InputStreamReader(System.in));  The line creates the stream object inFromUser of type BufferedReader.  Input stream is initialized with System.in, which attaches the stream to standard input.  The command allows the client to read text from its keyboard.

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-160 August 26, 2015 Code Descriptions-TCPClient.java Socket clientSocket = new Socket("hostname", 6789);  The line  creates object clientSocket of type Socket.  performs a DNS look-up on the hostname to obtain the host's IP address.  initiates the TCP connection between client and server.  String "hostname" replaced with host name of server (for example, "fling.seas.upenn.edu").  The number 6789 is the port number. You can use a different port number; but you must make sure that you use the same port number at the server side of the application.

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-161 August 26, 2015 Code Descriptions-TCPClient.java DataOutputStream outToServer =new DataOutputStream(clientSocket.getOutputStream()); BufferedReader inFromServer =new BufferedReader(new inputStreamReader(clientSocket.getInputStream()));  The above two lines create stream objects that are attached to the socket.  outToServer stream provides the process output to the socket.  inFromServer stream provides the process input from the socket.

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-162 August 26, 2015 Code Descriptions-TCPClient.java sentence = inFromUser.readLine();  The above line places a line typed by the user into the string sentence.  The string sentence continues to gather characters until the user ends the line by typing a carriage return.  The line passes from standard input through the stream inFromUser into the string sentence.

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-163 August 26, 2015 Code Descriptions-TCPClient.java outToServer.writeBytes(sentence + '\n');  Line sends the string sentence augmented with a carriage return into the outToServer stream.  The augmented sentence flows through the client's socket and into the TCP pipe.  The client then waits to receive characters from the server. modifiedSentence = inFromServer.readLine();  When characters arrive from the server, they flow through the stream inFromServer and get placed into the string modifiedSentence.  Characters continue to accumulate in modifiedSentence until the line ends with a carriage return character.

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-164 August 26, 2015 Code Descriptions-TCPClient.java System.out.println("FROM SERVER " + modifiedSentence);  The above line prints to the monitor the string modifiedSentence returned by the server. clientSocket.close();  This last line  closes the socket and,  hence, closes the TCP connection between the client and the server.  It causes TCP in the client to send a TCP message to TCP in the server.

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-165 August 26, 2015 import java.io.*; import java.net.*; class TCPServer { public static void main(String argv[]) throws Exception { String clientSentence; String capitalizedSentence; ServerSocket welcomeSocket = new ServerSocket(6789); while(true) { Socket connectionSocket = welcomeSocket.accept(); BufferedReader inFromClient = new BufferedReader(new InputStreamReader(connectionSocket.getInputStream())); Create welcoming socket at port 6789 Wait, on welcoming socket for contact by client Create input stream, attached to socket Example: TCPServer.java

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-166 August 26, 2015 DataOutputStream outToClient = new DataOutputStream (connectionSocket.getOutputStream()); clientSentence = inFromClient.readLine(); capitalizedSentence = clientSentence.toUpperCase() + '\n'; outToClient.writeBytes(capitalizedSentence); } Read in line from socket Create output stream, attached to socket Write out line to socket End of while loop, loop back and wait for another client connection Example: TCPServer.java (cont.)

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-167 August 26, 2015 Code Descriptions-TCPServer.java  TCPServer has many similarities with TCPClient.  The first line in TCPServer that is substantially different from what we saw in TCPClient is: ServerSocket welcomeSocket = new ServerSocket(6789);  Line creates the object welcomeSocket, which is of type ServerSocket.  The WelcomeSocket is a sort of door that waits for a knock from some client.  The port number 6789 identifies the process at the server.

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-168 August 26, 2015 Code Descriptions-TCPServer.java Socket connectionSocket = welcomeSocket.accept();  It creates a new socket, called connectionSocket, when some client knocks on welcomeSocket.  TCP then establishes a direct virtual pipe between clientSocket at the client and connectionSocket at the server.  The client and server can then send bytes to each other over the pipe, and all bytes sent arrive at the other side in order.  With connectionSocket established, the server can continue to listen for other requests from other clients for the application using welcomeSocket.  This version of the program doesn't actually listen for more connection requests, but it can be modified with threads to do so.

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-169 August 26, 2015 Code Descriptions-TCPServer.java  The program then creates several stream objects, analogous to the stream objects created in clientSocket. Now consider: capitalizedSentence = clientSentence.toUpperCase() + '\n';  This command is the heart of the application.  It takes the line sent by the client,  capitalizes it, and  adds a carriage return.  It uses the method toUpperCase().  All the other commands in the program are peripheral; they are used for communication with the client.

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-170 August 26, 2015 Code Descriptions-TCPServer.java  To test the program pair, you install and compile TCPClient.java in one host and TCPServer.java in another host. Be sure to include the proper host name of the server in TCPClient.java.  You then execute TCPServer.class, the compiled server program, in the server. This creates a process in the server that idles until it is contacted by some client.  Then you execute TCPClient.class, the compiled client program, in the client. This creates a process in the client and establishes a TCP connection between the client and server processes.  Finally, to use the application, you type a sentence followed by a carriage return.

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-172 August 26, 2015 UDP: no “connection” between client and server,  no handshaking,  sender explicitly attaches IP address and port of destination to each packet,  server must extract IP address, port of sender from received packet. UDP: transmitted data may be received out of order, or lost. application viewpoint UDP provides unreliable transfer of groups of bytes (“datagrams”) between client and server Socket Programming with UDP

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-173 August 26, 2015 close clientSocket Server (running on hostid ) read reply from clientSocket create socket, clientSocket = DatagramSocket() Client Create, address ( hostid, port=x, send datagram request using clientSocket create socket, port= x, for incoming request: serverSocket = DatagramSocket() read request from serverSocket write reply to serverSocket specifying client host address, port number Client/Server Socket Interaction: UDP

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-174 August 26, 2015 Example: Java Client (UDP ) Output: sends packet (TCP sent “byte stream”) Input: receives packet (TCP received “byte stream”) Process ClientSocket recievepacket sendpacket inFromUser Input Stream UDP datagram packet UDP datagram packet UDP socket To transport layer From transport layer

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-175 August 26, 2015 import java.io.*; import java.net.*; class UDPClient { public static void main(String args[]) throws Exception { BufferedReader inFromUser = new BufferedReader(new InputStreamReader(System.in)); DatagramSocket clientSocket = new DatagramSocket(); InetAddress IPAddress = InetAddress.getByName("hostname"); byte[ ] sendData = new byte[1024]; byte[ ] receiveData = new byte[1024]; String sentence = inFromUser.readLine(); sendData = sentence.getBytes(); Create input stream Create client socket Translate hostname to IP address using DNS Example: UDPClient.java

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-176 August 26, 2015 DatagramPacket sendPacket = new DatagramPacket(sendData, sendData.length, IPAddress, 9876); clientSocket.send(sendPacket); DatagramPacket receivePacket = new DatagramPacket(receiveData, receiveData.length); clientSocket.receive(receivePacket); String modifiedSentence = new String(receivePacket.getData()); System.out.println("FROM SERVER:" + modifiedSentence); clientSocket.close(); } Create datagram with data-to-send, length, IP addr, port Send datagram to server Read datagram from server Example: Example: UDPClient.java (cont.)

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-177 August 26, 2015 Code Descriptions-UDPClient.java  The program UDPClient.java constructs one stream and one socket. The socket is called clientSocket, and it is of type DatagramSocket.  UDP uses a different kind of socket than TCP at the client. Here the client uses a DatagramSocket whereas with TCP our client used a Socket.  The stream inFromUser is an input stream to the program; it is attached to the standard input, that is, to the keyboard. We had an equivalent stream in our TCP version of the program. When the user types characters on the keyboard, the characters flow into the stream inFromUser.  In contrast with TCP, there are no streams (input or output) attached to the socket. Instead of feeding bytes to the stream attached to a Socket object, UDP will push individual packets through the DatagramSocket object.

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-178 August 26, 2015 Code Descriptions-UDPClient.java DatagramSocket clientSocket = new DatagramSocket();  It creates the object clientSocket of type DatagramSocket. In contrast with TCPClient.java, this line does not initiate a TCP connection.  In particular, the client host does not contact the server host upon execution of this line. For this reason, the constructor DatagramSocket() does not take the server hostname or port number as arguments.  The execution of the above line creates a port for the client process but does not create a connection between the two processes.

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-179 August 26, 2015 Code Descriptions-UDPClient.java InetAddress IPAddress = InetAddress.getByName("hostname");  In order to send bytes to a destination process, we shall need to obtain the address of the process. Part of this address is the IP address of the destination host.  The above line invokes a DNS look-up that translates the hostname to an IP address.  DNS was also invoked by the TCP version of the client, although it was done there implicitly rather than explicitly.  The method getByName() takes as an argument the hostname of the server and returns the IP address of this same server. It places this address in the object IPAddress of type InetAddress.

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-180 August 26, 2015 Code Descriptions-UDPClient.java byte[ ] sendData = new byte[ ]; byte[ ] receiveData = new byte[ ];  The byte arrays sendData and receiveData will hold the data the client sends and receives, respectively. sendData = sentence.getBytes();  The above line essentially performs a type conversion. It takes the string sentence and renames it as sendData, which is an array of bytes.

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-181 August 26, 2015 Code Descriptions-UDPClient.java DatagramPacket sendPacket = new DatagramPacket(sendData, sendData.length, IPAddress, 9876);  This line constructs the packet, sendPacket, that the client will pop into the network through its socket.  Note that sendPacket is of type DatagramPacket.  This packet includes that data that is contained in the packet, sendData,  the length of this data,  the IP address of the server, and  the port number of the application (which we have set to 9876).

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-182 August 26, 2015 Code Descriptions-UDPClient.java clientSocket.send(sendPacket);  In the above line, the method send() of the object clientSocket takes the packet just constructed and pops it into the network through clientSocket.  Once again, note that UDP sends the line of characters in a manner very different from TCP.  TCP simply inserted the line into a stream, which had a logical direct connection to the server; UDP creates a packet that includes the address of the server.  After sending the packet, the client then waits to receive a packet from the server.

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-183 August 26, 2015 Code Descriptions-UDPClient.java DatagramPacket receivePacket = new DatagramPacket(receiveData, receiveData.length);  In the above line, while waiting for the packet from the server, the client creates a place holder for the packet, receivePacket, an object of type DatagramPacket. clientSocket.receive(receivePacket);  The client idles until it receives a packet; when it does receive a packet, it puts the packet in receivePacket.

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-184 August 26, 2015 Code Descriptions-UDPClient.java String modifiedSentence = new String(receivePacket.getData());  It extracts the data from receivePacket and performs a type conversion, converting an array of bytes into the string modifiedSentence. System.out.println("FROM SERVER:" + modifiedSentence);  This line, which is also present in TCPClient, prints out the string modifiedSentence at the client's monitor. clientSocket.close();  This last line closes the socket. Because UDP is connectionless, this line does not cause the client to send a transport-layer message to the server (in contrast with TCPClient).

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-185 August 26, 2015 import java.io.*; import java.net.*; class UDPServer { public static void main(String args[ ]) throws Exception { DatagramSocket serverSocket = new DatagramSocket(9876); byte[ ] receiveData = new byte[1024]; byte[ ] sendData = new byte[1024]; while(true) { DatagramPacket receivePacket = new DatagramPacket(receiveData, receiveData.length); serverSocket.receive(receivePacket); Create datagram socket at port 9876 Create space for received datagram Receive datagram Example: UDPServer.java

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-186 August 26, 2015 String sentence = new String(receivePacket.getData()); InetAddress IPAddress = receivePacket.getAddress(); int port = receivePacket.getPort(); String capitalizedSentence = sentence.toUpperCase(); sendData = capitalizedSentence.getBytes(); DatagramPacket sendPacket = new DatagramPacket(sendData, sendData.length, IPAddress, port); serverSocket.send(sendPacket); } Get IP addr port #, of sender Write out datagram to socket End of while loop, loop back and wait for another datagram Create datagram to send to client Example: Example: UDPServer.java (cont.)

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-187 August 26, 2015  handles one HTTP request  accepts the request  parses header  obtains requested file from server’s file system  creates HTTP response message:  header lines + file  sends response to client  after creating server, you can request file using a browser (eg IE explorer)  see the following slides for details. Building a Simple Web Server

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-188 August 26, 2015 Example: WebServer.java import java.io.*; import java.net.*; import java.util.*; class WebServer { public static void main(String argv[ ]) throws Exception { String requestMessageLine; String fileName; ServerSocket listenSocket = new ServerSocket(6789); Socket connectionSocket = listenSocket.accept(); BufferedReader inFromClient = new BufferedReader( new InputStreamReader(connectionSocket.getInputStream())); DataOutputStream outToClient = new DataOutputStream(connectionSocket.getOutputStream()); contain the first line in the HTTP request message contain the file name of the requested file When a request for a connection arrives, the accept( ) method of listenSocket creates a new object, connectionSocket, of type Socket. two streams are created

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-189 August 26, 2015 Example: WebServer.java (cont.) requestMessageLine = inFromClient.readLine(); StringTokenizer tokenizedLine = new StringTokenizer(requestMessageLine); If(tokenizedLine.nextToken().equals("GET")) { fileName = tokenizedLine.nextToken(); if (fileName.startsWith("/") == true ) fileName = fileName.substring(1); File file = new File(fileName); int numOfBytes = (int) file.length(); FileInputStream inFile = new FileInputStream (fileName); byte[ ] fileInBytes = new byte[ ]; inFile.read(fileInBytes); reads the first line of the HTTP request message. tokenizedLine holds the request line with each of the "words" GET, file_name, and HTTP/1.1 placed in a separate placeholder called a token. removes the backslash that may precede the filename. These commands determine the size of the file and construct an array of bytes of that size. The name of the array is fileInBytes. reads from the stream inFile to the byte array fileInBytes

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-190 August 26, 2015 Example: WebServer.java (cont.) outToClient.writeBytes( "HTTP/1.0 200 Document Follows\r\n"); if (fileName.endsWith(".jpg")) outToClient.writeBytes("Content-Type:image/jpeg\r\n"); if (fileName.endsWith(".gif")) outToClient.writeBytes("Content-Type:image/gif\r\n"); outToClient.writeBytes("Content-Length: " +numOfBytes + "\r\n"); outToClient.writeBytes("\r\n"); outToClient.write(fileInBytes, 0, numOfBytes); connectionSocket.close(); } else System.out.println("Bad Request Message"); } sends the mandatory status line: HTTP/1.1 200 Document Follows, followed by a carriage return and a line feed. ◊ to transfer a GIF image, server prepares the header line Content-Type: image/gif. ◊ to transfer a JPEG image, server prepares the header line Content-Type: image/jpeg. sends a content- length header line and a mandatory blank line sends the requested file, fileInBytes, to the TCP send buffer closing the socket connectionSocket

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-191 August 26, 2015 Code Descriptions-WebServer.java  The first half of the program is almost identical to TCPServer.java. As with TCPServer.java, we import the java.io and java.net packages.  In addition to these two packages we also import the java.util package, which contains the StringTokenizer class, which is used for parsing HTTP request messages.

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-192 August 26, 2015 Code Descriptions-WebServer.java  Looking now at the lines within the classWebServer, we define two string objects: String requestMessageLine; String fileName;  The object requestMessageLine is a string that will contain the first line in the HTTP request message.  The object fileName is a string that will contain the file name of the requested file.

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-193 August 26, 2015 Code Descriptions-WebServer.java  The next set of commands is identical to the corresponding set of commands in TCPServer.java. ServerSocket listenSocket = new ServerSocket(6789); Socket connectionSocket = listenSocket.accept();  Two socket-like objects are created. The first of these objects is listenSocket, which is of type ServerSocket. The object listenSocket is created by the server program before receiving a request for a TCP connection from a client. It listens at port 6789 and waits for a request from some client to establish a TCP connection. When a request for a connection arrives, the accept() method of listenSocket creates a new object, connectionSocket, of type Socket.

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-194 August 26, 2015 Code Descriptions-WebServer.java BufferedReader inFromClient = new BufferedReader(new InputStreamReader (connectionSocket.getInputStream())); DataOutputStream outToClient = new DataOutputStream(connectionSocket. getOutputStream());  Next two streams are created: the BufferedReader inFromClient and the DataOutputStream outToClient. The HTTP request message comes from the network, through connectionSocket and into inFromClient; the HTTP response message goes into outToClient, through connectionSocket and into the network.

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-195 August 26, 2015 Code Descriptions-WebServer.java  The remaining portion of the code differs significantly from  TCPServer.java. requestMessageLine = inFromClient.readLine();  The above command reads the first line of the HTTP request message. This line is supposed to be of the form: GET file_name HTTP/1.1

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-196 August 26, 2015 Code Descriptions-WebServer.java  Our server must now parse the line to extract the filename. StringTokenizer tokenizedLine = new StringTokenizer(requestMessageLine); if (tokenizedLine.nextToken().equals("GET")){ fileName = tokenizedLine.nextToken();  They parse the first line of the request message to obtain the requested filename.  The object tokenizedLine can be thought of as the original request line with each of the "words"  GET,  file_name, and  HTTP/1.1 placed in a separate placeholder called a token.

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-197 August 26, 2015 Code Descriptions-WebServer.java  The server knows from the HTTP RFC that the file name for the requested file is contained in the token that follows the token containing "GET."  This file name is put in a string called fileName. if (fileName.startsWith("/") == true ) fileName = fileName.substring(1);  The purpose of the above if statement in the above code is to remove the backslash that may precede the filename.

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-198 August 26, 2015 Code Descriptions-WebServer.java FileInputStream inFile = new FileInputStream (fileName);  The above command attaches a stream, inFile, to the file fileName. byte[] fileInBytes = new byte[]; inFile.read(fileInBytes);  These commands determine the size of the file and construct an array of bytes of that size. The name of the array is fileInBytes.  The last command reads from the stream inFile to the byte array fileInBytes. The program must convert to bytes because the output stream outToClient may only be fed with bytes.

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-199 August 26, 2015 Code Descriptions-WebServer.java  Now we are ready to construct the HTTP response message. To this end we must first send the HTTP response header lines into the DataOutputStream outToClient: outToClient.writeBytes("HTTP/1.0 200 Document Follows\r\n");  The above and next two commands are particularly interesting. These commands prepare the header lines for the HTTP response message and send the header lines to the TCP send buffer.  The above command sends the mandatory status line: HTTP/1.1 200 Document Follows, followed by a carriage return and a line feed.

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-200 August 26, 2015 Code Descriptions-WebServer.java if (fileName.endsWith(".jpg")) outToClient.writeBytes("Content- Type: image/jpeg\r\n"); if (fileName.endsWith(".gif")) outToClient.writeBytes("Content-Type: image/gif\r\n");  These tow command lines prepare a single content-type header line.  If the server is to transfer a GIF image, then the server prepares the header line Content-Type: image/gif.  If the server is to transfer a JPEG image, then the server prepares the header line Content-Type: image/jpeg. (In this simple Web server, no content line is sent if the object is neither a GIF nor a JPEG image.)

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-201 August 26, 2015 Code Descriptions-WebServer.java outToClient.writeBytes("Content-Length: " + numOfBytes + "\r\n"); outToClient.writeBytes("\r\n");  The server then prepares and sends a content-length header line and a mandatory blank line to precede the object itself that is to be sent. We now must send the file FileName into the DataOutputStream outToClient.

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-202 August 26, 2015 Code Descriptions-WebServer.java  We can now send the requested file: outToClient.write(fileInBytes, 0, numOfBytes);  The above command sends the requested file, fileInBytes, to the TCP send buffer. TCP will concatenate the file, fileInBytes, to the header lines just created, segment the concatenation if necessary, and send the TCP segments to the client. connectionSocket.close();  After serving one request for one file, the server performs some housekeeping by closing the socket connectionSocket.

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-203 August 26, 2015 Code Descriptions-WebServer.java  To test this Web server,  install it on a host.  put some files in the host.  Then use a browser running on any machine to request a file from the server.  When you request a file, you will need to use the port number that you include in the server code (for example, 6789).  So if your server is located at somehost.somewhere.edu, the file is somefile.html, and the port number is 6789, then the browser should request the following:  http://somehost.somewhere.edu:6789/somefile.html

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-204 August 26, 2015 C-language tutorial (audio/slides):  “Unix Network Programming” (J. Kurose), http://manic.cs.umass.edu/~amldemo/courseware/intro. Java-tutorials:  “All About Sockets” (Sun tutorial), http://www.javaworld.com/javaworld/jw-12-1996/jw-12- sockets.html  “Socket Programming in Java: a tutorial,” http://www.javaworld.com/javaworld/jw-12-1996/jw-12- sockets.html Socket Programming: References

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-205 August 26, 2015  2.1 Principles of app layer protocols  clients and servers  app requirements  2.2 Web and HTTP  2.3 FTP  2.4 Electronic Mail  SMTP, POP3, IMAP  2.5 DNS  2.6 Socket programming with TCP  2.7 Socket programming with UDP  2.8 Building a Web server  2.9 Content distribution (delivery)  Network Web caching  Content distribution networks  P2P file sharing Chapter 2 Outline

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-206 August 26, 2015 browsers Web server networks Content Distribution Network

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-207 August 26, 2015 routers The Problem: Congestion browsers networks servers

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-208 August 26, 2015 browsers server replicated content (mirror) router content source content sink (cache) Content Delivery Network: Idea

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-209 August 26, 2015 Content Distribution Metric  Cost × Performance analysis is the key metric to the effectiveness of an information (content) distributed system.

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-210 August 26, 2015  The conventional Technologies are:  Proxy cache server, and  Mirror server  They are cost effective technologies which enhance the performance, namely:  Reducing the latency of access.  Reducing the network bandwidth required for document transfers.  Reducing the demand on servers with very popular documents.  Improving the security of electronic file transfer. Servers: Caching, and Mirror (content distribution strategies)

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-211 August 26, 2015 Caching: idea (information distribution strategies)  Basic idea in caching:  Store the frequently retrieved documents into local files or proxies for future use.  It improves:  access speed and  cuts down on network traffic.  It also reduces:  the server load and  increase availability in the web by replicating documents among many servers (cache).

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-212 August 26, 2015 Caching: client - network (information distribution strategies)  Caching on client disk:  Browsers maintain small caches of previously-viewed pages on the user’s local disk. ( example: Documents and Settings\WELCOME\Local Settings\Temporary Internet Files )  Network caching:  Caching system is located on machine in the path from multiple clients to multiple servers.

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-213 August 26, 2015 Caching: proxy (information distribution strategies)  Caching proxy servers can be located near a large community of users such as:  on a campus network,  at an intranet server, or  at an ISP server. HTML, FTP, Search, Database origin servers Proxy Architecture origin servers institutional network institutional Cache( Proxy server ) Internet LAN router Internet router

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-214 August 26, 2015  user sets browser: Web accesses via cache (proxy)  browser sends all HTTP requests to cache (proxy)  object in cache: cache returns object  else cache requests object from origin server, then returns object to client Goal: satisfy client request without involving origin server. client Proxy server client HTTP request HTTP response HTTP request HTTP response origin server origin server Web Caches (Proxy web-Server)

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-215 August 26, 2015  Cache acts as both client and server  Cache can do up-to-date check using If-modified- since HTTP header  Issue: should cache take risk and deliver cached object without checking?  Heuristics are used.  Typically cache is installed by ISP (university, company, residential ISP) Why Web caching?  Reduce response time for client request.  Reduce traffic on an institution’s access link.  Internet dense with caches enables “poor” content providers to effectively deliver content More about Web Caching

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-216 August 26, 2015 Service Providing Entity λ : Arrival (request) Departure (response) Content Distribution Model λ : Arrival (request) Departure (response) Service Providing Entity  Service Providing Entity examples:  Server  LAN  Access Link  … in service waiting

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-217 August 26, 2015 Model Parameters  λ: Average Arrival rate [requests/sec]  S: Average Service time [sec/response];  Example1: Server  λ: Average Arrival rate [file request/sec]  S: Average Service time [sec/file response];  Example2: Link, LAN  λ: Average Arrival rate [bit/sec]  S: Average Service time [sec/file] = L/R; L: file length, R: Link Bandwidth λ : Arrival (request) Departure (response) Service Providing Entity in service waiting S

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-218 August 26, 2015 Model Equations (M/M/1)  Utilization of Service Providing Entity = U = λ xS; ( λ ≤1/S)  delay (Response Time)=Service Time + Waiting Time;  delay = S/(1-U);  Waiting Time (Queuing Delay) = delay – S

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-219 August 26, 2015 Equations for Link, LAN  λ = a [files/sec]; rate of files entering into the link, LAN  S = L/R [sec/file]; the time needed to pass a file through the Link, LAN  U = λ xS = La/R [ ]; Link, LAN Utilization  I = U [ ]; Link, LAN Traffic Intensity  delay = S/(1-U) = L/[R(1-U)] [secs/file]

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-220 August 26, 2015 Link Response Time  U up link = L req λ /R link = I up link  delay up = S up /(1-U up link ) [sec/req]  U down link = L res λ’ /R link = I down link  delay down = S down /(1-U down link ) [sec/res]  delay = delay up + delay down ≈ delay down  It is because: L res >> L req R up link LAN router Internet router Files from origin servers R down link Request from clients λ λ’λ’

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-221 August 26, 2015 Caching Example1 (1) Assumptions  Average request rate from institution’s browser to origin serves: λ = 15reqs/sec  Average request massage size ≈ 0 bit  Average object size = L= 100,000 bits  Internet delay ≈ 2 sec (average) Time spent in the Internet origin servers public Internet LAN R link =1.6 Mbps (up and down) R lan =10 Mbps

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-222 August 26, 2015 Caching Example1 (2) delay is calculated for down stream only:  LAN Service time= S lan = L/R lan = 10 msec  LAN Utilization = La/R lan = 0.15 = 15%  LAN delay =S/(1-U) = 10/0.85 =11.8 msec  Link Service time S link = L/R link = 62.5 msec  Link Utilization (Traffic Intensity) = La/R link = 93.75%  Link delay = 62.5/0.0625 = 1000 msec  delay = Internet delay + access-link delay + LAN delay = 2000 + 1000 + 11.8 =3011.8 msecs  q router = 1000 – 62.5 = 937.5 msec origin servers public Internet LAN R link =1.6 Mbps access-link R lan =10 Mbps 937.5 msecs 62.5 msecs 11.8 msecs

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-223 August 26, 2015 Caching Example2 Upgrade the link:  LAN Service time= S lan = L/R lan = 10 msec  LAN Utilization = La/R lan = 0.15 = 15%  LAN delay = S/(1-U) = 10/0.85 = 11.8 msec  Link Service time S link = L/R link = 10 msec  Link Utilization (Traffic Intensity) = La/R link = 15%  Link delay = 11.8 msec  delay = Internet delay + access-link delay + LAN delay = 2000 + 11.8 + 11.8 =2023.6 msecs  q router = 11.8 – 10 = 1.8 msec origin servers public Internet LAN R link =10 Mbps access-link R lan =10 Mbps 1.8 msecs 10 msecs 11.8 msecs Often a costly upgrade

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-224 August 26, 2015 Install cache  suppose hit rate is 0.4 Consequence  40% requests will be satisfied almost immediately  60% requests satisfied by origin server  utilization of access link (reduced to 60%) = 0.6 *93.75= 56.25%  Link delay = 62.5/0.4375 = 143 msec  delay = 0.4* 11.8 + 0.6 x (2000 + 143 + 11.8+11.8) = 1304.68msec Caching Example3 origin servers public Internet LAN R link =1.6 Mbps access-link R lan =10 Mbps 80.5 msecs 62.5 msecs 11.8 msecs Network cache

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-225 August 26, 2015  The content (information) providers are the CDN customers. Content replication (mirror)  CDN company installs hundreds of CDN servers throughout Internet.  in lower-tier ISPs, close to users.  CDN replicates its customers’ content in CDN servers. When provider updates content, CDN updates servers. Content Distribution Network: idea origin server in North America CDN distribution node CDN server in S. America CDN server in Europe CDN server in Asia

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-226 August 26, 2015 1.Origin server informs RR of Content Availability. 2.Content Pushed to Distribution System. 3.Client Requests Content, Origin server redirects client to RR. 4.Client sends query to RR. 5.RR finds the most suitable Mirror Server. 6.Mirror server receives client request and provides services. CDN: Architectural Layout Request Routing(RR) Routing(RR) DistributionNode OriginServer 1 2a Client MirrorServer 2b 3 5 6 4

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-227 August 26, 2015 routing requests  CDN creates a “map”, indicating distances from leaf ISPs and CDN nodes  when query arrives at authoritative DNS server:  server determines ISP from which query originates  uses “map” to determine best CDN server not just Web pages  streaming stored audio/video  streaming real-time audio/video  CDN nodes create application-layer overlay network شبكه ي بر روی لايه ي كاربرد More about CDNs

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-228 August 26, 2015 Overlay networks IP Overlay X Y  Edge between peer X and Y if there is a TCP connection.  All active peers and edges is overlay network.  Edge is not a physical link.  Given peer will typically be connected with <10 overlay neighbors

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-229 August 26, 2015 Overlay Networks IP Overlay

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-230 August 26, 2015 Example runs P2P client application on his notebook computer.  User1 runs P2P client application on his notebook computer.  Intermittently connects to Internet; gets new IP address for each connection.  Asks for “network e-book”  Application displays other peers that have copy of network e-book.  User1 chooses one of the peers, User2.  File is copied from User2’s PC to User1’s notebook: HTTP  While User1 downloads, other users uploading from User1.  User1’s peer is both a Web client and a transient Web server. All peers are servers = highly scalable! P2P File Sharing

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-231 August 26, 2015Definitions  P2P is a class of applications that take advantage of resources:  storage,  cycles,  content,  human presence available at the edges of the Internet.  P2P refers to a class of systems and applications that employ distributed resources to perform a critical function in a decentralized manner. Clay Shirky ( www.shirky.com ) Milojicic et al. ( HP )

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-232 August 26, 2015 Some controversy Is p2p a new approach?  Problems is peer-to-peer systems are neither new nor unique; they make us look for solutions to old problems that we all worked around or tried to ignore before. Andy Oram (O'Reilly & associates) speech at Free and Open Source Software Developers's Meeting Brussels, BE, Feb. 2002

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-233 August 26, 2015 Example: University of Washington (2002)  UW is an HTTP content provider  Exported 16.65 TB - Imported 3.44 TB  Bandwidth consumption (in + out)  0.2% Akamai (overnet. eDonkey) [content delivery networks]  6.04% Gnutella (p2p system)  14.3% WWW  36.9% Kazaa (p2p system)  43% other TCP protocols, e.g. mail, streaming video

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-234 August 26, 2015Properties  No central control, no central database  No hierarchy  Every node is both a client and a server  The communication between peers is symmetric  No global view of the system  Scalability  Availability for any peer  Peers are autonomous  System globally unreliable  Robustness and security issues

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-235 August 26, 2015 Examples of p2p Applications  File-sharing applications  Napster, KazaA, Gnutella, Freenet, …  E-Commerce Systems  eBay, …  Parallel Processing  Distributed computing (grid?), SETI (Internet- connected computers used for Search for Extraterrestrial Intelligence), …  Collaboration  Distributed (Internet) games, Instant messaging, Shared Application, …  Distributed databases  Mariposa, Litwin, Yokota, Plaxton, …  Mobile Ad hoc networks (Unstructured networks)  Application-level multicast  …

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-236 August 26, 2015 How Much P2P is Involved? P2P User Interaction P2P Application P2P Information Management eBayyesno Napsteryes no Gnutella, Freenet yes

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-237 August 26, 2015 Types of P2P Systems  Hybrid or Centralized (Napster)  Pure or Decentralized (Gnutella, Freenet)  Super Peers or Hierarchical (KaZaA, DNS)  Redundant Super Peers (DNS)

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-238 August 26, 2015 Hybrid or Centralized P2P  In a hybrid P2P system, some operations are performed at a central server.  For other operations, the peers have equal status.  Example: Napster file download  Central server contains an index of the files located at all the peers currently available.  Peer 1 asks server where a file is located.  Server returns address of Peer 2 who has the file.  Peer 1 asks Peer 2 (directly) for the file. Next 2 slides

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-239 August 26, 2015 Hybrid System 2 3 4 5 1 1 5 2 5 3 4 4 5 Who has 1 5 Give me

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-240 August 26, 2015 Original “Napster” design 1) Peers to notify server when they join and leave: (IP Add, Port Num) Peers to notify server if their available files change: Contents Peers to run a “server” program that listens on a port for download requests. 2) User1 queries for “network e-book”, 3) User1 requests file from User2. peers User1 User2 1 1 1 1 2 3 Napster as a Centralized System 1 2 3 ° ° ° location server

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-241 August 26, 2015 Centralized model (Napster) INTERNET location server register Document x? OK: Peer Z IP = a.b.c.d  Document x! x  Peer Z IP: a.b.c.d

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-242 August 26, 2015 Hybrid: Ads and DisAds  Advantages:  Search is generally efficient  Disadvantages  High cost on centralized index  Performance & scalability bottleneck  Vulnerable! Highly visible target

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-243 August 26, 2015 Pure P2P-1  All peers have equal roles in all responsibilities  Example: Gnutella  In order to find an item, Peer 1 asks his neighbors if they have it.  They ask their neighbors, and so on  A message has a “time to live” which determines how long it will be sent along.  Why is this needed?  Different search strategies will be discussed later

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-244 August 26, 2015 Pure P2P-2  What happens when a peer (say, Peer 34) is identified, who has the file that Peer 1 wants?  2 Different options are in use in different systems  Peer 34 directly sends file to Peer 1  Peer 34 sends the file back in the same route that it was requested  Advantages/disadvantages of each option?

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-245 August 26, 2015 Pure P2P ? ? ? ? ? ? ? ? ?

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-246 August 26, 2015 Pure P2P: Option 1

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-247 August 26, 2015 Pure P2P: Option 2

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-248 August 26, 2015 Gnutella: protocol  Query message HTTP sent over existing TCP connections  Gnutella on ports 6346 and 6347  peers forward Query message  QueryHit sent over reverse path  Scalability: limited scopeflooding Query QueryHit Query QueryHit Query File Transfer: http

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-249 August 26, 2015 Gnutella Protocol Messages  Broadcast Messages  Ping: initiating message (“I’m here”)  Query: search pattern and TTL (time-to-live)  Back-Propagated Messages  Pong: reply to a ping, contains information about the peer  Query response: contains information about the computer that has the needed file  Node-to-Node Messages  GET: return the requested file  PUSH: push the file to me

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-250 August 26, 2015 Peer Joining in Gnutella  Joining peer X must find some other peer in Gnutella network; use list of candidate peers.  X sequentially attempts to make TCP connection with peers on list until connection setup with Y.  X sends Ping message to Y; Y forwarded Ping message.  All peers receiving Ping message respond with Pong message.  X receives many Pong messages. It can then setup additional TCP connections.  Peer living!

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-251 August 26, 2015 Topology of Gnutella BackboneBackbone + Outskirts

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-252 August 26, 2015 Pure: Ads and DisAds  Advantages:  Easy to start  No maintenance needed  Hard to shut down  privacy  Disadvantages:  Inefficient search  Lot of network traffic  Bottlenecks (limited peers)

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-253 August 26, 2015 Super Peers  Make use of heterogeneity  Powerful peers serve as super peers  Weaker peers act as clients  Example: KaZaA  Super-peers index clients’ files  Requires updates on join/leave/update  Queries handled at super-peer level.  Query evaluation between super-peers similar to query evaluation between peers in a pure system.

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-254 August 26, 2015 Super Peers

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-255 August 26, 2015  Each peer is either  a group leader or  assigned to a group leader.  Group leader tracks the content in all its children.  Each peer queries its group leader.  Group leader may query other group leaders.  KazaA on port 1214 ordinary peer (ordinary node) group-leader peer (super node) neighboring relationships in overlay network Decentralized Directory (KaZaA)

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-256 August 26, 2015 KazaA Query  Each file has a hash 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.

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-257 August 26, 2015 Super Peers: Ads and DisAds  Advantages:  All the advantages of pure  Takes advantage of different peer capabilities  Disadvantages:  Super nodes might become bottlenecks for clients  Clients are disconnected when super peer leaves  Inefficient search (but better than Pure P2P)  Maintenance costs for super peers

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-258 August 26, 2015 Redundant Super Peers  Like super peers, but each super-peer is k- redundant, i.e., there are k nodes sharing the super peer load  all k nodes have the same indexes of all the clients  clients ask super-peer queries in a round robin fashion

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-259 August 26, 2015 Super Peers

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-260 August 26, 2015 Redundant Super Peers

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-261 August 26, 2015 Redundant Super Peers: Ads and DisAds  Advantages  All advantages of super-peers  load of queries is shared among peers  less points of fail  Disadvantages  additional maintenance: nodes must notify all redundant super-peers upon joining, leaving, updating files  Additional connections between super-peers required

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-262 August 26, 2015 Non-structured system (Gnutella-like)  Two phases (like Napster)  Localization + exchange  No server  Open source  gnutella.wego.com  Distributed search  The query is flooded  Loop avoidance  Limited TTL (not all nodes are visited)

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-263 August 26, 2015 Structured systems (DHTs)  Based on Distributed Hash Tables (DHTs)  No flooding  Exact matches  Overhead  Gnutella-like  O(n)  DHT  O(log n)  Examples  CAN, Pastry, Chord, Kademlia, Tapestry, P-Grid,...

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-264 August 26, 2015 Content-Addressable Networks (CAN)  Provides a large scale distributed hash table  Keys are mapped into values  CAN defines a d-dimensional virtual space  No relationship with the physical space  Query  O(n 1/d )  Neighbors  O(d)  The virtual space is completely distributed among the peers  Each peer is responsible for one share of the space  The peer that is responsible for region R is also responsible for the values inside R  Documents must be uniquely identified

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-265 August 26, 2015Example

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-266 August 26, 2015Example 1

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-267 August 26, 2015Example 12

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-268 August 26, 2015Example 2 1 33

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-269 August 26, 2015Example 2 3 14

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-270 August 26, 2015Example 2 3 14 5 4

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-271 August 26, 2015Example 2 3 6 4 5 1

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-272 August 26, 2015Example 2 3 6 4 5 17

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-273 August 26, 2015 Association ID  node 2 3 6 4 5 17 Ex: Node 3 holds this document

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-274 August 26, 2015 Association ID  node 2 3 6 4 5 17

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-275 August 26, 2015 Application-layer multicast  Native multicast  not yet completely deployed  ALM  easier/faster to implement  Scalability  states at end-systems  High-level support

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-276 August 26, 2015 Application-layer multicast source

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-277 August 26, 2015 Many works and projects  Gnutella and Napster @sourceforge.net

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-278 August 26, 2015 JXTA (Sun)  Open platform for p2p cooperation  Interoperability  Any system/peer/application  Platform independency  Languages (C, Java, etc)  Systems platforms (Unix, Windows, etc)  Networking platforms (802.11, Bluetooth, TCP/IP, etc)  Ubiquity  Sensors, PDAs, routers, desktops, laptops, storage systems

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-279 August 26, 2015 JXTA (Sun)  Objectives  Find peers and resources  Share files with anyone across the network  Create a particular group of peers across different networks  Communicate securely with peers across public networks  Projects  Applications (24 projects)  Core (13 projects)  Demos (3 projects)  Forge (15 projects)  Other (12 projects)  Services (24 projects)

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-280 August 26, 2015 JXTA (Sun)  Protocols  Peer discovery protocol  Peer resolver protocol  Peer information protocol  Rendezvous protocol  Pipe binding protocol  Endpoint routing protocol

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-281 August 26, 2015 JXTA (Sun) Peer (Desktop, cell phone, PDA, etc.) Security Peer GroupsPeer PipesPeer Monitoring JXTA Community Services Sun JXTA Services JXTA Shell Peer Commands JXTA Community Applications CORECORE JXTAJXTA

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-282 August 26, 2015 JXTA applications

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-283 August 26, 2015 Final remarks  P2P implies a very large spectrum of areas  High interest in both academicals/industrials  Much has already been done, but no conclusions are definitive  IPv6 and P2P  NAT, firewalls, IPv6 as an overlay  Many open issues  Trust, security, scalability, QoS, etc.

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-284 August 26, 2015  application service requirements:  reliability, bandwidth, delay.  client-server paradigm.  Internet transport service model.  connection-oriented, reliable: TCP  unreliable, datagrams: UDP Our study of network apps now complete!  specific protocols:  HTTP  FTP  SMTP, POP, IMAP  DNS  socket programming  content distribution  caches, CDNs  P2P Chapter 2: Summary1

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-285 August 26, 2015  typical request/reply message exchange:  client requests info or service  server responds with data, status code  message formats:  headers: fields giving information about data  data: information being communicated Most importantly: learned about protocols  control vs data messages  in-band, out-of-band  centralized vs. decentralized  stateless vs. stateful  reliable vs. unreliable msg transfer  “complexity at network edge”  security: authentication Chapter 2: Summary2

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-286 August 26, 2015  Complimentary Hyperlinks  This part provides hyperlinks to interesting (and hopefully useful) computer-networking resources.  Most of these resources provide complimentary information to the material in chapter 2.  If you're asked to write a paper pertaining to a specialized topic in computer networking, these resources should serve as a good starting point for your research. References & Links  References and Hyperlinks

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-287 August 26, 2015  Unix Network Programming http://www- aml.cs.umass.edu/~jsmanic/unetpgm  Online tutorial on Unix socket programming, using slides and audio, from author James Kurose.  Tutorial on Java sockets http://www.javaworld.com/javaworld/jw-12-1996/jw-12- sockets.html  This tutorial presents an introduction to sockets programming and shows how to write client/server applications in Java. Complimentary Hyperlinks1

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-288 August 26, 2015  The World Wide Web Consortium (W3C) http://www.w3.org/  The W3C was founded in 1994 to develop common protocols for the evolution of the World Wide Web. This is an outstanding site with fascinating information on emerging Web technologies, protocols, and standards.  Web Protocols and Practice http://www.aw.com/catalog/academic/product/1,4096,0201710889,00.html  Web Protocols and Practice: HTTP/1.1, Networking Protocols, Caching, and Traffic Measurement, a comprehensive and readable book by Balachander Krishnamurthy and Jennifer Rexford on Web protocols and related topics.  Cookie Central http://www.cookiecentral.com/  Everything you ever wanted to know about cookies, including how they infringe on users' privacy.  The IMAP Connection http://www.imap.org/  Everything you always wanted to know about IMAP, including history, direct access to relevant RFCs, and product information. Complimentary Hyperlinks2

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-289 August 26, 2015  ISC BIND http://www.isc.org/products/BIND  DNS name servers use the Berkeley Internet Name Domain (BIND) software. You can learn about it (and download it) here.  Exploring Name Servers http://www.unhooked.net/cgi- bin/host  nslookup, host, and dig are client programs available for exploring the contents of name servers in the Internet. Several sites, including the one listed above, allow you to access these programs through a Web browser. All of these programs mimic DNS clients. They send a DNS query message to a name server (which can often be supplied by the user), and they receive a corresponding DNS response. They then extract information (e.g., IP addresses, whether the response is authoritative, etc.) and present the information to the user. Complimentary Hyperlinks3

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-290 August 26, 2015  Online Java Tutorial http://java.sun.com/docs/books/tutorial  Do you what to learn Java before doing the programming exercises? This is an excellent place to start.  Akamai Homepage http://www.akamai.com/  Homepage for leading Content Distribution Network (CDN) company.  Developers Site for Gnutella http://www.gnutelladev.com/  Includes links to source code as well as links to documentation of the protocol. Complimentary Hyperlinks 4

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-291 August 26, 2015  A note on Internet Request for Comments (RFCs): Copies of Internet RFCs are maintained at multiple sites. The RFC URLs below all point into the RFC archive at the Information Sciences Institute (ISI), maintained the the RFC Editor of the Internet Society (the body that oversees the RFCs). Other RFC sites include http://www.faqs.org/rfc, http://www.pasteur.fr/other/computer/RFC (located in France), and http://www.csl.sony.co.jp/rfc/ (located in Japan).  Internet RFCs can be updated or obsoleted by later RFCs. We encourage you to check the sites listed above for the most up-to-date information. The RFC search facility at ISI, http://www.rfc-editor.org/rfcsearch.html, will allow you to search for an RFC and show updates to that RFC.  [Abitz 1993] P. Albitz and C. Liu, DNS and BIND, O'Reilly & Associates, Petaluma, CA, 1993.  [Akamai 2000] Akamai homepage, http://www.akamai.com References and Hyperlinks1

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-292 August 26, 2015  [Berners-Lee 1994] T. Berners-Lee, R. Cailliau, A. Luotonen, H. Frystyk Nielsen, and A. Secret, "The World-Wide Web," Commun. ACM 37, 8 (Aug. 1994), Pages 76-82  [BIND 2000] Internet Software Consortium page on BIND, http://www.isc.org/bind.html  [Claffy 1998] K. Claffy, G. Miller, and K. Thompson, "The Nature of the Beast: Recent Traffic Measurements from an Internet Backbone," Proceedings of Inet '98, (Geneva, Switzerland, July 1998), http://www.caida.org/outreach/resources/papers/Inet98/  [Cookie Central 2000] Cookie Central homepage, http://www.cookiecentral.com  [Cusumano 1998] M.A. Cusumano and D.B. Toffle, Competing on Internet Time: Lessons from Netscape and its Battle with Microsoft, Free Press, 1998  [DNSNet] DNSNet page on DNS resources, http://www.dns.net/dnsrd/docs/ References and Hyperlinks2

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-293 August 26, 2015  [Frost 1994] J. Frost, "BSD Sockets: A Quick and Dirty Primer," http://world.std.com/~jimf/papers/sockets/sockets.html  [Gauthier 1999] L. Gauthier, C. Diot, and J. Kurose, "End-to-end Transmission Control Mechanisms for Multiparty Interactive Applications on the Internet," Proceedings of IEEE Infocom '99, (New York, NY, Apr. 1999). ftp://ftp.sprintlabs.com/diot/infocom99-mimiaze.zip  [Gay 1997] V. Gay and B. Dervella, "MHEGAM--A Multimedia Messaging System," IEEE Multimedia Magazine, Oct.-Dec. 1997, pp. 22-29. References and Hyperlinks3

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-294 August 26, 2015  [Heidemann 1997] J. Heidemann, K. Obraczka, and J. Touch, "Modeling the Performance of HTTP over Several Transport Protocols," IEEE/ACM Transactions on Networking, Vol. 5, No. 5 (Oct. 1997), pp. 616-630.  [Hess 1998] C. Hess, D. Lin and K. Nahrstedt, "VistaMail: An Integrated Multimedia Mailing System," IEEE Multimedia Magazine, Oct.-Dec. 1998, pp. 13-23.  [Huffaker 1998] B. Huffaker, J. Jung, D. Wessels, and K. Claffy, "Visualization of the Growth and Topology of the NLANR Caching Hierarchy," The 3rd Web Caching Workshop, June 1998, England. http://www.caida.org/tools/visualization/plankton/Paper/plankton.xml References and Hyperlinks4

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-295 August 26, 2015  [IMAP 1999] The IMAP Connection, http://www.imap.org/  [ITU 1997] International Telecommunications Union, "Recommendation E.164/ I.331--The international public telecommunication numbering plan," May 1997. http://www.itu.int/itudoc/itu-t/rec/e/s_e164.html  [Kurose 1996] J. F. Kurose, Unix Network Programming. http://manic.cs.umass.edu/~amldemo/courseware/intro.html  [Luotonen 1998] A. Luotonen, Web Proxy Servers, Prentice Hall, Englewood Cliffs, New Jersey, 1998.  [McKusik 1996] Marshall Kirk McKusick, Keith Bostic, Michael Karels, and John Quarterman, The Design and Implementation of the 4.4BSD Operating System, Addison-Wesley, Reading, MA, 1996.  [Netcraft 2000] The Netcraft Web Server Survey, Netcraft Web Site, http://www.netcraft.com/survey/ References and Hyperlinks5

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-296 August 26, 2015  [Netscape Cookie 1999] Netscape, "Persistent Client State http Cookies. http://home.netscape.com/newsref/std/cookie_spec.html  [Nielsen 1997] H. F. Nielsen, J. Gettys, A. Baird-Smith, E. Prud'hommeaux, H. W. Lie, and C. Lilley, "Network Performance Effects of HTTP/1.1, CSS1, and PNG," W3C Document, 1997 (also appears in Proceedings of ACM SIGCOMM '97, Cannes, France, pp. 155-166 ). http://www.acm.org/sigcomm/sigcomm97/papers/p102.html  [NLANR 1999] A Distributed Testbed for National Information Provisioning, http://ircache.nlanr.net/  [Padhye 1999] J. Padhye and J. Kurose, "An Empirical Study of Client Interactions with a Continuous-Media Courseware Server," IEEE Internet Computing, Apr. 1999. ftp://gaia.cs.umass.edu/pub/Padh97:Empirical.ps.gz  [Ramjee 1994] R. Ramjee, J. Kurose, D. Towsley, and H. Schulzrinne, "Adaptive Playout Mechanisms for Packetized Audio Applications in Wide- Area Networks," Proceeding IEEE Infocom 94. ftp://gaia.cs.umass.edu/pib/Ramj94:Adaptive.ps.Z  [RFC 821] J. Postel, "Simple Mail Transfer Protocol," RFC 821, Aug. 1982. http://www.rfc-editor.org/rfc/rfc821.txt References and Hyperlinks6

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-297 August 26, 2015  [RFC 854] J. Postel and J. Reynolds, "TELNET Protocol Specification," RFC 854. May 1993. http://www.rfc-editor.org/rfc/rfc854.txt  [RFC 959] J. Postel and J. Reynolds, "File Transfer Protocol (FTP)," RFC 959, Oct. 1985. http://www.rfc-editor.org/rfc/rfc959.txt  [RFC 1034] P. V. Mockapetris, "Domain Names--Concepts and Facilities," RFC 1034, Nov. 1987. http://www.rfc-editor.org/rfc/rfc1034.txt  [RFC 1035] P. Mockapetris, "Domain Names--Implementation and Specification," RFC 1035, Nov. 1987. http://www.rfc- editor.org/rfc/rfc1035.txt  [RFC 1945] T. Berners-Lee, R. Fielding, H. Frystyk, "Hypertext Transfer Protocol--HTTP/1.0," RFC 1945, May 1996 http://www.rfc- editor.org/rfc/rfc1945.txt  [RFC 2045] N. Freed, N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies," RFC 2045, Nov. 1996. http://www.rfc-editor.org/rfc/rfc2045.txt References and Hyperlinks7

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-298 August 26, 2015  [RFC 2046] N. Freed, N. Borenstein,, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types," RFC 2046, Nov. 1996. http://www.rfc-editor.org/rfc/rfc2046.txt  [RFC 2068] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, and T. Berners-Lee, "Hypertext Transfer Protocol--HTTP/1.1," RFC 2068, Jan. 1997. http://www.rfc-editor.org/rfc/rfc2068.txt. Obsoleted by RFC 2616.  [RFC 2186] K. Claffy and D. Wessels, "Internet Caching Protocol (ICP), version 2," RFC 2186, Sept. 1997. http://www.rfc- editor.org/rfc/rfc2186.txt  [RFC 2616] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee, R. Feilding, "Hypertext Transfer Protocol-- HTTP/1.1," RFC 2616, June 1999. http://www.rfc- editor.org/rfc/rfc2616.txt  [Ross 1997] K. W. Ross, "Hash-Routing for Collections of Shared Web Caches," IEEE Network Magazine, Vol. 11 (Nov.-Dec. 1997), pp. 37-45.  [Ross 1998] K. W. Ross, Distribution of Stored Information in the Web, An Online Tutorial, http://www.eurecom.fr/~ross/CacheTutorial/DistTutorial.html, 1998. References and Hyperlinks8

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-299 August 26, 2015  [Schurmann 1996] G. Schurmann, "Multimedia Mail," ACM Multimedia Systems, Oct. 1996, pp. 281-295.  [Squid 2000] Squid Web Proxy Cache, http://www.squid-cache.org/  [Stevens 1997] W.R. Stevens, Unix Network Programming, Volume 1: Networking APIs-Sockets and XTI, 2nd edition, Prentice-Hall, Englewood Cliffs, NJ, 1997.  [Turner 1999] D. A. Turner and K. W. Ross, "Continuous-Media Internet E- Mail: Infrastructure Inadequacies and Solutions," http://www.eurecom.fr/~turner/cmail1.html  [Valloppillil 1997] V. Valloppillil and K. W. Ross, "Cache Array Routing Protocol," Internet Draft,, June 1997.  [Yeager 1996] N. J. Yeager and R. E. McGrath, Web Server Technology, Morgan Kaufmann Publishers, San Francisco, 1996. © 2000-2001 by Addison Wesley Longman A division of Pearson Education References and Hyperlinks9

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-300 August 26, 2015 P2P-Working groups et al.  A generic site on p2p from O'Reilly  www.openp2p.com  P2P working group  www.peer-to-peerwg.org/  Internet2 p2p working group  p2p.internet2.edu  Peer-to-peer development (p2p-hackers)  zgp.org/mailman/listinfo/p2p-hackers  Interesting meeting  www.codecon.org

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-301 August 26, 2015P2P-References-1  Distributed Computing  Distributed (www.distributed.net)  SETI@home (www.seti.org)  Genome@home (gah.stanford.edu)  Folding@home (www.stanford.edu/group/pandegroup/folding)  Global Grid Forum (www.globalgridforum.org)  Globus Project (www.globus.org)  File sharing  Napster (www.napster.com)  Gnutella (gnutella.wego.co)  Kazaa (www.kazaa.com)

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-302 August 26, 2015P2P-References-2  Distributed hash tables  CAN (www.acm.org/sigs/sigcomm/sigcomm2001/p13-ratnasamy.pdf)  Pastry (research.microsoft.com/~antr/Pastry)  Chord (www.pdos.lcs.mit.edu/chord)  Tapestry (www.cs.berkeley.edu/~ravenben/tapestry)  Freenet (freenet.sourceforge.net)  Kademlia (kademlia.scs.cs.nyu.edu)  Ad hoc networking  AODV (www.ietf.org/internet-drafts/draft-ietf-manet-aodv- 13.txt)  OLSR (www.ietf.org/internet-drafts/draft-ietf-manet-olsr-10.txt)  Tribe (rp.lip6.fr/site_rp/_publications/350-79Viana.ps.gz)

ali.dmohammadi @gmail.comApplication Layer ali.dmohammadi @gmail.comApplication Layer 2-303 August 26, 2015P2P-References-3  Platforms  JXTA (www.jxta.org) .NET (www.microsoft.com/net)  Collaboration  Groove (www.groove.net)  Endeavors (www.endeavors.com)  IPv6 as a p2p overlay  Working Groups  p2p.internet2.edu  www.openp2p.com

Layer Layer 2-1 August 26, 2015. Application Layer Computer Networks Shahrood.

Similar presentations

Presentation on theme: "Layer Layer 2-1 August 26, 2015. Application Layer Computer Networks Shahrood."— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Layer Layer 2-1 August 26, 2015. Application Layer Computer Networks Shahrood.

Similar presentations

Presentation on theme: "Layer Layer 2-1 August 26, 2015. Application Layer Computer Networks Shahrood."— Presentation transcript:

Similar presentations

About project

Feedback