Roadmap 16: Application, Transport, r Application Layer (User level) Network and Link Layers r Transport Layer (OS) r Network Layer (OS) Last Modified: r Link Layer (Device Driver, Adapter Card) 7/3/2004 1:46:53 PM -1 -2 Application Layer Applications and application-layer protocols Application: communicating, application transport r Network Applications Drive Network distributed processes network data link Design m running in network hosts in physical r Important to remember that network “user space” m exchange messages to applications are the reason we care about implement app building a network infrastructure m e.g., email, file transfer, r Applications range from text based the Web Application-layer protocols command line ones popular in the 1980s application m one “piece” of an app application transport (like telnet, ftp, news, chat, etc) to transport network network data link m define messages data link physical multimedia applications (Web browsers, physical exchanged by apps and audio and video streaming, realtime actions taken videoconferencing, etc.) m user services provided by lower layer protocols -3 -4 Client-server paradigm How do clients and servers communicate? Typical network app has two application pieces: client and server transport network API: application Q: how does a process data link Client: physical programming interface “identify” the other request r initiates contact with server r defines interface process with which it (“speaks first”) between application wants to communicate? r typically requests service from and transport layer m IP address of host server, running other process r socket: Internet API r for Web, client is implemented reply m “port number” - allows in browser; for e-mail, in mail m two processes receiving host to application communicate by sending reader transport determine to which network data into socket, data link local process the Server: physical reading data out of message should be r Running first (always?) socket delivered r provides requested service to client e.g., Web server sends requested Web page, mail … more on this later. server delivers e-mail -5 -6 1 Socket programming Sockets Goal: learn how to build client/server application that Socket: a door between application process communicate using sockets and end-end-transport protocol (UCP or Socket API socket TCP) r introduced in BSD4.1 UNIX, 1981 a host-local, application- created/owned, r Sockets are explicitly created, used, released by OS-controlled interface controlled by (a “door”) into which controlled by process application applications application process application process can developer r client/server paradigm developer socket socket both send and controlled by r two types of transport controlled by kernel kernel receive messages to/from buffers, operating service via socket API: operating buffers, internet another (remote or system variables system m unreliable datagram variables local) application process m reliable, byte stream- host or oriented host or server server -7 -8 Languages and Platforms Transport services and protocols r providelogical communication application transport r Socket API is available for many languages between app’ processes network data link network physical running on different hosts logical end data link on many platforms: network physical r transport protocols run in data link m C, Java,Perl, Python,… physical end systems network - data link end transport m *nix, Windows,… r physical network transport vs network layer data link services: physical r Socket Programs written in any language network r network layer:data transfer data link physical and running on any platform can between end systems application communicate with each other! r transport layer:data transport transfer between processes network r data link Client and server must agree on the type m relies on, enhances, network physical of socket, the server port number and the layer services protocol -9 -10 Services provided by Internet UDP transport protocols r UDP adds very little TCP service: UDP service: 32 bits functionality (or r connection-oriented:setup r unreliable data transfer overhead) to bare IP source port # dest port # required between client, between sending and length checksum server receiving process r Adds multiplexing/ Length, in r reliable transport between r does not provide: demultiplexing bytes of UDP sending and receiving process connection setup, r other UDP uses segment, r including flow control: sender won’t reliability, flow control, (why?): overwhelm receiver header congestion control, timing, m DNS: small, retransmit Application r congestion control: throttle sender when network or bandwidth guarantee if necessary data overloaded m often used for streaming (message) multimedia apps r Q: why bother? Why is does not providing: timing, • Loss tolerant minimum bandwidth there a UDP? • rate sensitive guarantees UDP segment format -11 -12 2 Process-to-Process Message Multiplexing/demultiplexing Delivery Multiplexing: Demultiplexing: Goal : Deliver application data to correct process (and more gathering data from multiple particularly to the right socket) Stream of incoming data into app processes, enveloping one machine separated into data with header (later used smaller streams destined for Segment - unit of data exchanged between transport layer for demultiplexing) entities; transport protocol data unit (TPDU) individual processes receiver 32 bits Demultiplexing based on IP P3 P4 source port # dest port # application-layer M M addresses of sender and and data port numbers of both sender application and receiver segment P1 transport P2 other header fields header M m Can distinguish traffic M network application application coming to same port but segment transport Ht M transport part of separate network application Hn segment network conversations (like data multiple client connections (message) to a web server) TCP/UDP segment format -13 -14 TCP adds functionality Common Sense r TCP adds lots of functionality over bare IP and r Consider faxing a document with flaky machine over UDP m Can’t talk to person on the other side any other way m Still has multiplexing/demultiplexing r What would you do to make sure they got the m Adds reliable, in-order delivery transmission? m Adds flow control and congestion control m Number the pages – so receiver can put them in order/detect duplicates/detect losses r How can you guarantee that other side gets “A B C m Need feedback from the receiver!!! D E” when network could: m Resend data that is missing or if don’t hear from m Lose data “A B D E” receiver m Duplicate data “A B C C D E” r Put some info on cover sheet that lets person m Corrupt data “A B X D E” verify fax info (summarize info like checksum) m Reorder data “A C D E B” r What if it is a really big document? Receiver might m Or all of the above! like to be able to tell you send first 10 pages then 10 more… -15 -16 TCP Connection Management Three-Way Handshake Active participant Passive participant Recall: TCP sender, receiver Three way handshake: (client) (server) establish “connection” before exchanging data Step 1: client end system SYN, SequenceNum = segments sends TCP SYN control x r segment to server initialize TCP variables: y, m seq. #s m specifies initial seq # x + 1 m buffers, flow control info (e.g. RcvWindow) Step 2: server end system SYN + ACK, SequenceNum = receives SYN, replies with Acknowledgment = r client:connection initiator SYNACK control segment ACK, Acknowledgment = Socket clientSocket = new Socket("hostname","port m ACKs received SYN y + 1 number"); m allocates buffers r server:contacted by client m specifies server-> Socket connectionSocket = receiver initial seq. # Note: SYNs take up a sequence number even though welcomeSocket.accept(); no data bytes Step 3: client acknowledges servers initial seq. # -17 -18 3 Timeout and Retransmission TCP: retransmission scenarios (1) Host A Host B Host A Host B r Seq=92, 8 bytes data Receiver must acknowledge receipt of all Seq=92, 8 bytes data packets X loss r Sender sets a timer if acknowledgement ACK=100 timeout has not arrived before timer expires then timeout X loss sender will retransmit packet Seq=92, 8 bytes data Seq=92, 8 bytes data r Adaptive retransmission: timer value computed as a function of average round ACK=100 trip times and variance ACK=100 time lost data scenario time lost ACK scenario -19 -20 TCP: retransmission scenarios (2) Network layer functions Host A Host B Host A Host B r transport packet from sending application to receiving hosts transport Seq=92, 8 bytes data Seq=92, 8 bytes data network data link network Seq r network layer protocols in physical Seq=100, 20 bytes data =100, 20 bytes data network data link network every host, router (Recall data link physical data link physical physical Seq=120, 20 bytes data X loss transport layer is end-to-end) network data link =92 timeout three important functions: physical network ACK=100ACK=120 data link Seq ACK=100 physical =100 timeout r path determination: route =100 timeout Seq=92, 8 bytes data ACK=100 network Seq taken by packets from source Seq network data link data link physical to dest. Routing algorithms physical r switching: move packets from network Seq data link application =100, 20 bytes data router’s input to appropriate physical transport ACK=120 network router output data link physical r call setup: some network time time architectures (e.g. telephone, premature timeout, Duplicate ACK, fast retransmit (really need ATM) require router call setup cumulative ACKs 3 dup acks before fast retransmit) along path before data flow -21 -22 Internet Protocol IP Addressing: introduction 223.1.1.1 r The Internet is a network of heterogeneousnetworks: r IP address: 32-bit identifier for host, 223.1.2.1 m using different technologies (ex. different maximum packet 223.1.1.2 router interface sizes) 223.1.1.4 223.1.2.9 r interface: connection m belonging to different administrative authorities (ex.