2: Application Layer P2P applications, Sockets, UDP

2: Application Layer 2 Chapter 2 Application Layer Computer Networking: A Top Down Approach Featuring the Internet, 3 rd edition. Jim Kurose, Keith Ross Addison-Wesley, July A note on the use of these ppt slides: We’re making these slides freely available to all (faculty, students, readers). They’re in PowerPoint form so you can add, modify, and delete slides (including this one) and slide content to suit your needs. They obviously represent a lot of work on our part. In return for use, we only ask the following:  If you use these slides (e.g., in a class) in substantially unaltered form, that you mention their source (after all, we’d like people to use our book!)  If you post any slides in substantially unaltered form on a www site, that you note that they are adapted from (or perhaps identical to) our slides, and note our copyright of this material. Thanks and enjoy! JFK/KWR All material copyright J.F Kurose and K.W. Ross, All Rights Reserved

2: Application Layer 3 P2P file sharing r Clients connect directly to each other for the purpose of file transfer. r Three different architectures. r HTTP for file transfer and communication.

2: Application Layer 4 P2P: centralized directory original “Napster” design 1) when peer connects, it informs central server: m IP address m content 2) Alice queries for “Tawan Yor Saeng” 3) Alice requests file from Bob centralized directory server peers Alice Bob

2: Application Layer 5 P2P: problems with centralized directory r Single point of failure r Performance bottleneck r Copyright infringement file transfer is decentralized, but locating content is highly centralized

2: Application Layer 6 Query flooding: Gnutella r fully distributed m no central server r public domain protocol r many Gnutella clients implementing protocol overlay network: graph r edge between peer X and Y if there’s a TCP connection r all active peers and edges is overlay net r Edge is not a physical link r Given peer will typically be connected with < 10 overlay neighbors

2: Application Layer 7 Gnutella: protocol Query QueryHit Query QueryHit Query QueryHit File transfer: HTTP r Query message sent over existing TCP connections r peers forward Query message r QueryHit sent over reverse path Scalability: limited scope flooding

2: Application Layer 8 Gnutella: Peer joining (bootstrap problem) 1. Joining peer X must find some other peer in Gnutella network: use list of candidate peers or bootstrap nodes 2. X sequentially attempts to make TCP connections with peers on list until connection setup with Y 3. X sends Ping message to Y; Y forwards Ping message. 4. All peers receiving Ping message respond with Pong message 5. X receives many Pong messages. It can then setup additional TCP connections

2: Application Layer 9 Exploiting heterogeneity: KaZaA r Each peer is either a group leader or assigned to a group leader. m TCP connection between peer and its group leader. m TCP connections between some pairs of group leaders. r Group leader tracks the content in all its children. Image source: erstanding.php#

2: Application Layer 10 KaZaA: Querying r Client sends keyword query to its group leader r Group leader responds with matches r If group leader forwards query to other group leaders, they respond with matches r Client then selects files for downloading

2: Application Layer 11 Kazaa tricks r Limitations on simultaneous uploads r Request queuing – ensures minimum bandwidth r Incentive priorities r Parallel downloading

2: Application Layer 12 Socket programming Socket API r introduced in BSD4.1 UNIX, 1981 r explicitly created, used, released by apps r client/server paradigm r two types of transport service via socket API: m unreliable datagram m reliable, byte stream- oriented 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 socket Goal: learn how to build client/server application that communicate using sockets

2: Application Layer 13 Socket programming with User Datagram Protocol (UDP) UDP: no “connection” between client and server r no handshaking r sender explicitly attaches IP address and port of destination to each packet r 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

2: Application Layer 14 Client/server socket interaction: UDP close clientSocket Server read reply from clientSocket create socket, clientSocket Client Create address(IP address and port number) send datagram request using clientSocket create socket, port= x, for incoming request: serverSocket read request from serverSocket write reply to serverSocket specifying client host address, port number

2: Application Layer 15 Example: Client (UDP) sock = socket(...);... sendto(sock,...);... recvfrom(sock,...); Create client socket Send datagram to server Read datagram from server

2: Application Layer 16 Example: Server (UDP) sock = socket(...); bind(sock,...);... recvfrom(sock,...);... sendto(sock,...); Create datagram socket Receive datagram Write out datagram to socket

2: Application Layer 17 Socket-programming using Transmission Control Protocol (TCP) TCP service: reliable transfer of bytes from one process to another process TCP with buffers, variables socket controlled by application developer controlled by operating system host or server process TCP with buffers, variables socket controlled by application developer controlled by operating system host or server internet

2: Application Layer 18 Socket programming with TCP Client must contact server r server process must first be running r server must have created socket (door) that welcomes client’s contact Client contacts server by: r creating client-local TCP socket r specifying IP address, port number of server process r When client creates socket: client TCP establishes connection to server TCP r When contacted by client, server TCP creates new socket for server process to communicate with client m allows server to talk with multiple clients m 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

2: Application Layer 19 Client/server socket interaction: TCP wait for incoming connection request connectionSocket create socket, port= x, for incoming request: welcomeSocket = ServerSocket() create socket, connect using clientSocket close connectionSocket read reply from clientSocket close clientSocket Server Client send request using clientSocket read request from connectionSocket write reply to connectionSocket TCP connection setup

2: Application Layer 20 Example: Client (TCP) sock = socket(…)); connect(sock, …); send(sock, …); recv(sock, …); Create client socket, connect to server Send line to server Read line from server

2: Application Layer 21 Example: Server (TCP) sock = socket(…); bind((sock, …); //Map port # listen(sock, …); //Allow connections... while(true) { //create a new socket for each client clntsock = accept(sock,...);... recv(clntsock,...);... send(clntsock,...); } Create welcoming socket Wait on welcoming socket for contact by client Read in line from socket Write out line to socket

2: Application Layer 22 Chapter 2: Summary r application service requirements: m reliability, bandwidth, delay r client-server paradigm r Internet transport service model m connection-oriented, reliable: TCP m unreliable, datagrams: UDP Our study of network apps now complete! r specific protocols: m HTTP m FTP m SMTP, POP, IMAP m DNS r socket programming

2: Application Layer 23 Chapter 2: Summary r typical request/reply message exchange: m client requests info or service m server responds with data, status code r message formats: m headers: fields giving info about data m data: info being communicated Most importantly: learned about protocols r control vs. data msgs m in-band, out-of-band r centralized vs. decentralized r stateless vs. stateful r reliable vs. unreliable msg transfer r “complexity at network edge” r security: authentication

Transport Layer Chapter 3 Transport Layer Computer Networking: A Top Down Approach Featuring the Internet, 3 rd edition. Jim Kurose, Keith Ross Addison-Wesley, July A note on the use of these ppt slides: We’re making these slides freely available to all (faculty, students, readers). They’re in PowerPoint form so you can add, modify, and delete slides (including this one) and slide content to suit your needs. They obviously represent a lot of work on our part. In return for use, we only ask the following:  If you use these slides (e.g., in a class) in substantially unaltered form, that you mention their source (after all, we’d like people to use our book!)  If you post any slides in substantially unaltered form on a www site, that you note that they are adapted from (or perhaps identical to) our slides, and note our copyright of this material. Thanks and enjoy! JFK/KWR All material copyright J.F Kurose and K.W. Ross, All Rights Reserved

Transport Layer Transport services and protocols r provide logical communication between app processes running on different hosts r transport protocols run in end systems m send side: breaks app messages into segments, passes to network layer m receive side: reassembles segments into messages, passes to app layer r more than one transport protocol available to apps m Internet: TCP and UDP application transport network data link physical application transport network data link physical network data link physical network data link physical network data link physical network data link physical network data link physical logical end-end transport

Transport Layer Transport vs. network layer r network layer: logical communication between hosts r transport layer: logical communication between processes m relies on, enhances, network layer services

Transport Layer Internet transport-layer protocols r reliable, in-order delivery (TCP) m congestion control m flow control m connection setup r unreliable, unordered delivery: UDP m no-frills extension of “best-effort” IP r services not available: m delay guarantees m bandwidth guarantees application transport network data link physical application transport network data link physical network data link physical network data link physical network data link physical network data link physical network data link physical logical end-end transport

Transport Layer Multiplexing/demultiplexing application transport network link physical P1 application transport network link physical application transport network link physical P2 P3 P4 P1 host 1 host 2 host 3 = process= socket delivering received segments to correct socket Demultiplexing at rcv host: gathering data from multiple sockets, enveloping data with header (later used for demultiplexing) Multiplexing at send host:

Transport Layer How demultiplexing works r host receives IP datagrams m each datagram has source IP address, destination IP address m each datagram carries 1 transport-layer segment m each segment has source, destination port number (recall: well-known port numbers for specific applications) r host uses IP addresses & port numbers to direct segment to appropriate socket source port #dest port # 32 bits application data (message) other header fields TCP/UDP segment format

Transport Layer Connectionless demultiplexing r Create sockets with port numbers: r UDP socket identified by two-tuple: ( dest IP address, dest port number) r When host receives UDP segment: m checks destination port number in segment m directs UDP segment to socket with that port number r IP datagrams with different source IP addresses and/or source port numbers directed to same socket

Transport Layer Connectionless demux (cont) Client IP:B P2 client IP: A P1 P3 server IP: C SP: 6428 DP: 9157 SP: 9157 DP: 6428 SP: 6428 DP: 5775 SP: 5775 DP: 6428 SP provides “return address”

Transport Layer Connection-oriented demux r TCP socket identified by 4-tuple: m source IP address m source port number m dest IP address m dest port number r recv host uses all four values to direct segment to appropriate socket r Server host may support many simultaneous TCP sockets: m each socket identified by its own 4-tuple

Transport Layer Connection-oriented demux (cont) Client IP:B P2 client IP: A P1 P3 server IP: C SP: 80 DP: 9157 SP: 9157 DP: 80 SP: 80 DP: 5775 SP: 5775 DP: 80

Transport Layer UDP: User Datagram Protocol [RFC 768] r “no frills,” “bare bones” Internet transport protocol r “best effort” service, UDP segments may be: m lost m delivered out of order to app r connectionless: m no handshaking between UDP sender, receiver m each UDP segment handled independently of others Why is there a UDP? r no connection establishment (which can add delay) r simple: no connection state at sender, receiver r small segment header r no congestion control: UDP can blast away as fast as desired

Transport Layer UDP: more r often used for streaming multimedia apps m loss tolerant m rate sensitive r other UDP uses m DNS m SNMP r reliable transfer over UDP: add reliability at application layer m application-specific error recovery! source port #dest port # 32 bits Application data (message) UDP segment format length checksum Length, in bytes of UDP segment, including header

Transport Layer UDP checksum Sender: r treat segment contents as sequence of 16-bit integers r checksum: addition (1’s complement sum) of segment contents r sender puts checksum value into UDP checksum field Receiver: r check if computed checksum equals checksum field value: m add all the received 16 bit fields including the checksum m Is the answer all 1s? NO - error detected YES - no error detected. But maybe errors nonetheless? More later …. Goal: detect “errors” (e.g., flipped bits) in transmitted segment