1. 2: Application Layer 1 05 - P2P applications and Sockets

2. 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 2004. 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 1996-2004 J.F Kurose and K.W. Ross, All Rights Reserved

3. 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.

4. 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 “Hey Jude” 3) Alice requests file from Bob centralized directory server peers Alice Bob 1 1 1 1 2 3

5. 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

6. 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

7. 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

8. 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 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

9. 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: http://www.cachelogic.com/p2p/p2pund erstanding.php#

10. 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

11. 2: Application Layer 11 File distribution: BitTorrent tracker: tracks peers participating in torrent torrent: group of peers exchanging chunks of a file obtain list of peers trading chunks peer rP2P file distribution

12. 2: Application Layer 12 BitTorrent (1) r file divided into 256KB chunks. r peer joining torrent: m has no chunks, but will accumulate them over time m registers with tracker to get list of peers, connects to subset of peers (“neighbors”) r while downloading, peer uploads chunks to other peers. r peers may come and go r once peer has entire file, it may (selfishly) leave or (altruistically) remain

13. 2: Application Layer 13 BitTorrent (2) Pulling Chunks r at any given time, different peers have different subsets of file chunks r periodically, a peer (Alice) asks each neighbor for list of chunks that they have. r Alice sends requests for her missing chunks m rarest first Sending Chunks: tit-for-tat rAlice sends chunks to top four neighbors (unchoked)  re-evaluate top 4 every 10 secs revery 30 secs: randomly select another peer, starts sending chunks  newly chosen peer may join top 4  “optimistically unchoke”

14. 2: Application Layer 14 BitTorrent: Tit-for-tat (1) Alice “optimistically unchokes” Bob (2) Alice becomes one of Bob’s top-four providers; Bob reciprocates (3) Bob becomes one of Alice’s top-four providers With higher upload rate, can find better trading partners & get file faster!

15. 2: Application Layer 15 P2P Case study: Skype r inherently P2P: pairs of users communicate. r proprietary application-layer protocol (inferred via reverse engineering) r hierarchical overlay with SNs r Index maps usernames to IP addresses; distributed over SNs Skype clients (SC) Supernode (SN) Skype login server

16. 2: Application Layer 16 Peers as relays r Problem when both Alice and Bob are behind “NATs”. m NAT prevents an outside peer from initiating a call to insider peer r Solution: m Using Alice’s and Bob’s SNs, Relay is chosen m Each peer initiates session with relay. m Peers can now communicate through NATs via relay

17. 2: Application Layer 17 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

18. 2: Application Layer 18 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

19. 2: Application Layer 19 Client/server socket interaction: UDP close clientSocket Server read reply from clientSocket create socket, clientSocket Client Create address 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

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

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

22. 2: Application Layer 22 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

23. 2: Application Layer 23 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

24. 2: Application Layer 24 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

25. 2: Application Layer 25 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

26. 2: Application Layer 26 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

27. 2: Application Layer 27 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

28. 2: Application Layer 28 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