© Janice Regan, CMPT 128, Jan 2007 CMPT 371 Data Communications and Networking Introducing the Application Layer 0

Janice Regan © Sept What is in the application layer  All user applications  Electronic mail, instant messaging, telephony  Web, video, music  Remote login  File transfer and file sharing  Multiplayer networked games  What else?

Janice Regan © Sept How do apps communicate  Applications may be built on a reliable network (TCP) or a best effort network (UDP). In the case of the best effort network the application itself must take care of assuring the communications are as reliable as necessary

Some Application layer Protocols  Users most commonly directly use application layer protocols like Hypertext Transfer Protocol (HTTP), File Transfer Protocol (FTP), Simple Mail Transfer Protocol (SMTP); Telnet,  Other common application layer protocols help facilitate the use and management of TCP/IP networks: These include Domain Name System (DNS), the Routing Information Protocol (RIP), the Simple Network Management Protocol (SNMP). Janice Regan © Sept

4 Network application architectures  Client server  Servers provide services to other hosts, always available  Clients request services from other hosts, when needed (not always connected)  Examples include, web, file servers,  When a service is heavily used it may be provided by a group of servers, not just one Client Server Client Server

Janice Regan © Sept Network application architectures  P2P (peer to peer)  Arbitrary pairs of hosts directly communicating (no server)  Easily scalable, each host both services and makes requests  Decentralized, highly distributed, may be difficult to manage to provide reliable service If only one host has the information and it leaves the application the information is lost  Hybrid systems (both client server and P2P aspects) Janice Regan © Sept Client

Hybrid client-server and P2P  Instant Messaging  Sending messages is P2P  Central server manages client detection (are you on right now?) Searching for friends addresses  Skype  Voice over IP is a P2P application  Your client accesses a centralized server to manage addresses and memberships Janice Regan © Sept

Issues with P2P  P2P distributes the function of the server over many users, this increases upstream traffic, stresses ISPs  Difficulty in proving security in P2P apps  Perception that supporting P2P is supporting “illegal” applications Janice Regan © Sept

8 Communication between processes  In order to build an application that communicates between processes (on the same or different hosts) need a way to send information, (data messages) from one process to another.  To write a user application you need not know how this communication works in detail, but you need a set of services that allows you to send messages.  The interface for sending messages will likely be the interface to the transport layer.

Janice Regan © Sept Communication between processes.  Think in terms of a client server architecture:  If your architecture is P2P think of the peer that is requesting (receiving) as the client and the host that is replying (sending) as the server.  Any communication can be thought of in terms of a series of communications from one process to another  If your architecture is P2P, the identity of the client and server may reverse for different communications in the series

Janice Regan © Sept Building an application  How do we build a communication channel in an application?  Usually use the socket API  A socket is one end of a communication connection  A process may include more than one communication connection, that is more than one socket  Your application will build the needed sockets, then connect them (or wait for them to be connected to) to the socket at the other end of the communication.  We will look at sockets in much more detail when we discuss the transport layer.

Janice Regan © Sept Socket API  Basic ideas: how to use the socket API  A socket is one end of a communication connection  A socket includes The address of the host running the process (IP address) The address of the process running on the host (port) A specification of the transport protocol to use (TCP, UDP).  Your application will build needed sockets  Each socket will Wait for a request to connect to another socket Make a request to connect to another socket

Janice Regan © Sept After connection?  What happens after we build our sockets and connect them to each other so the two processes can communicate?  The purpose of the connection is to enable the transfer of information between the processes, so the next step will be transferring information.  To transfer information we send messages from one process to the other through the communication connection

Janice Regan © Sept After connection?  To transfer information we send messages from one process to the other  The application level protocol developed for the particular application will define  The types of messages  The syntax of each message (layout and number of fields)  The semantics of each message (the content of each field, its meaning and use)  Rules for processing each type of message and building replies

Transport requirements  Some application will tolerate some data loss  Voice, some interactive games, and video will  file transfer, many web apps, and will not  Some apps are time sensitive  video games, video conferencing, streamed video  Some apps are bandwidth sensitive and require continuous minimum throughput  audio, video, telephony  Some apps can tolerate bursts of throughput (elastic throughput) , file transfer, … Janice Regan © Sept

Janice Regan © Sept Available Transport services  TCP  connection oriented (not a physical connection)  Reliable (guaranteed delivery)  No guarantee on the rate of delivery, will slow down transmission in case of congestion  Available congestion control mechanisms

Janice Regan © Sept Available Transport services  UDP  Simple, efficient  Best effort delivery, no guarantee of delivery  No congestion control, will not slow down transmission in case of congestion.  Can to a certain extent build guarantee into your application and avoid congestion control slowdowns to support rate critical (inelastic) applications

Internet applications (TCP)  Applicationprotocol  SMTP [RFC 2821]  remote accessTelnet [RFC 854]  WebHTTP [RFC 2616]  file transferFTP [RFC 959] Janice Regan © Sept

© Janice Regan, CMPT 128, Jan 2007 CMPT 371 Data Communications and Networking HTTP 18

HTTP  HyperText Transfer Protocol  The main application layer communication protocol of the world wide web (WWW)  For detailed information on any protocol refer to the RFC documents (Request for comment) these are the standard reference documents defining protocols  For HTTP see RFC 1945 and RFC 2616  You will not be expected to read all the RFC’s for this course Janice Regan © Sept

WWW: objects  When we use WWW we provide a URL and expect to see the web page displayed by our browser  Each web page is made up of many objects including images, text, audio or video clips, animations, applets and other components Janice Regan © Sept

WWW: objects  Each web page is described by an HTML file  The HTML file will include a reference (a separate URL) for each of the objects on the page  After the HTML file is received in response to the original HTML request, the objects in it can be individually requested  All the requested objects can then be assembled in the displayed page Janice Regan © Sept

WWW: using agents  Each browser is called an agent  Agents use HTTP to communicate across the Internet.  Agents are clients, they request information, the objects on a web page  For any operating system your agent is always uses HTTP to communicate across the Internet Janice Regan © Sept

WWW basic operation  Your agent (browser) is the client in a client server system  The hosts containing the objects that make up your web page are servers  You (the client) must request the objects from the servers (which store and provide the objects) using HTTP  HTTP is an application layer protocol Janice Regan © Sept

Access a web page  When we type a URL into our browser we expect to see a page displayed. How does it happen?  HTTP is used to send a request from your browser to the web server  HTTP is used by the server the send a reply to your HTTP request Janice Regan © Sept

Steps to access an object  The web server must first be located: use the URL  A TCP (reliable transport protocol) connection is made between the client and the server  The client sends a HTTP request for the object to the server, (or a series of HTTP requests)  The server will process the request and if appropriate sends a HTTP reply containing the requested object to the client  The client will add the object to the page and request the next object Janice Regan © Sept

Non-persistent connections  In the original version (1.0) of HTTP it was assumed that a TCP connection would be made to transfer each object.  As soon as the single object had been transferred the connection would be terminated  A new connection would be made for the next object that needed transferring between the same client server pair Janice Regan © Sept

Non-persistent connections  Early web pages contained one or a very small number of objects, this was not a critical problem  Today web pages contain many objects and the extra load of creating and terminating connections would place a significant extra load on the internet  A nonpersistant connection transports at most 1 HTTP request and 1 HTTP reply Janice Regan © Sept

Non-persistent connection Janice Regan © Sept Host AHost B Request TCP connection (SYN) (SYN, ACK) Accept TCP connection Acknowledge acceptance (ACK) and HTTP GET request object HTTP OK send object Request close of TCP connection (FIN) Acknowledge close request and make close request (FIN, ACK) Acknowledge close request (ACK)

non-persistent connections  Each time a non persistent connection is made, it is necessary to initialize and terminate a TCP connection  Send request to make/break connection A-B  Send back a response agreeing to make/break connection (B-A)  Send an acknowledgement that the connection has been made/terminated. Janice Regan © Sept

Efficiency: non-persistent connections  Each time a non persistent connection is made, it is necessary to initialize and terminate a TCP connection  The RTT (round trip travel time) is the time it takes to propagate from A to B and back to A  For each connection it take 3 round trip travel times to make and break the connection.  If many objects are to be transmitted this extra delay becomes significant. How can we increase the efficiency?  By sending multiple objects through each connection. Janice Regan © Sept

Persistent connections  In the late 1990’s HTTP 1.1 came into use  The default in HTTP1.1 is a persistent connection  When a web page is requested the client requests a TCP connection to the Web server  Many objects on the requested web page are then transferred through that connection before it is terminated. Janice Regan © Sept

Persistent connections  In fact when the web page has been completely sent the connection will remain open  It is likely if one page has been retrieved from the server another will be retrieved soon after  The connection can be terminated by the client or the server, or will be closed after a “reasonable” time has elapsed without any traffic passing through the connection. Janice Regan © Sept

Persistent connection Janice Regan © Sept Host AHost B (SYN) (SYN, ACK) (ACK) HTTP GET request object 1 With Piggyback ACK HTTP OK send object 1 Piggyback ACK of request HTTP GET request object 1 Piggyback ACK object (FIN) (FIN, ACK) (ACK) HTTP GET request object n Piggyback ACK object n-1 HTTP OK send object n May remain open

Persistent connections  Each time an object is sent through a persistent connection  Send request for the object to the server  Send back a response agreeing to make/break connection (B-A)  Send an acknowledgement that the object has been received  We wait for the first object to be received before requesting the next object. Janice Regan © Sept

Efficiency: persistent connections  The server must wait 1 RTT between the end of transmitting one object and the start of transmitting the next object  Transmission time plus ½ RTT for the end of the message to reach the client,  ½ RTT for the client to make the next request  If we pipeline, that is allow the next request to be made before finishing the present request we can improve efficiency by removing the need for this 1 RTT per object wait. Janice Regan © Sept

Pipelining  A series of objects can be requested  As the user’s agent tries to display a web page it may encounter embedded objects that need to be requested  With pipelining these objects are requested as soon as the agent knows they are needed.  At the web server the requests are queued and replied to (by sending the object) sequentially Janice Regan © Sept

Pipelining  A series of objects can be requested  At the web server the requests are queued and replied to sequentially  As soon as the web server has transmitted one object it can begin servicing the next request (sending the next object)  Eventually all requests have been serviced and the connection becomes idle  After the connection is idle for a short time (usually 10s of seconds) it will be closed Janice Regan © Sept

Persistent connection pipelining Janice Regan © Sept Host AHost B (SYN) (SYN, ACK) request object 1 Piggyback ACK send object 1 Transmission time object 1 (FIN) (FIN, ACK) (ACK) Acknowledge object n (ACK) send object 2 send object n request object 2 Transmission time object n request object n