Chapter 2: outline. 2.6 P2P applications 2.7 socket programming with UDP and TCP

Chapter 2: outline 2.1 principles of network applications app architectures app requirements 2.2 Web and HTTP 2.3 FTP 2.4 electronic mail SMTP, POP3, IMAP 2.5 DNS 2.6 P2P applications 2.7 socket programming with UDP and TCP Application Layer 2-1

FTP: the file transfer protocol client/server model based on TCP, port 21 separate control and data connections FTP server maintains states commands in ASCII text Application Layer 2-2

FTP mode Passive mode: client initiates data connection. Client sends PASV command to request server side port number. Active mode: server initiates the data connection. Client sends PORT command to specify the client side port number. Application Layer 2-3

Electronic Mail SMTP client/server model based on TCP, port 25 three phases of transfer: handshaking, transfer of messages, closure commands and messages in ASCII text Mail message format defined in RFC 822 header and body POP3 and IMAP mail access protocols 2: Application Layer 5

DNS: Domain Name System hierarchical distributed database for name-ip translation DNS services hostname to IP address translation host aliasing: canonical, alias names mail server aliasing load distribution 2: Application Layer 7

Distributed, Hierarchical Database Root DNS Servers com DNS servers org DNS servers edu DNS servers yahoo.com DNS servers amazon.com DNS servers pbs.org DNS servers poly.edu umass.edu DNS serversdns servers Root name servers Top-level domain (TLD) servers Authoritative DNS servers Local name server 2: Application Layer 8

DNS name resolution example root DNS server host at cis.poly.edu wants IP address for gaia.cs.umass.edu 2 3 4 5 TLD DNS server iterated query: contacted server replies with name of server to contact I don t know this name, but ask this server local DNS server dns.poly.edu 1 8 requesting host cis.poly.edu 7 6 authoritative DNS server dns.cs.umass.edu gaia.cs.umass.edu Application Layer 2-9

DNS name resolution example root DNS server recursive query: 2 7 6 3 puts burden of name resolution on contacted name server local DNS server dns.poly.edu 5 4 TLD DNS server heavy load at upper levels of hierarchy 1 8 requesting host cis.poly.edu authoritative DNS server dns.cs.umass.edu gaia.cs.umass.edu Application Layer 2-10

DNS: caching, updating records once (any) name server learns mapping, it caches mapping cache entries timeout (disappear) after some time (TTL) TLD servers typically cached in local name servers cached entries may be out-of-date (best effort name-to-address translation!) if name host changes IP address, may not be known Internet-wide until all TTLs expire Application Layer 2-11

DNS records DNS: distributed db storing resource records (RR) RR format: (name, value, type, ttl) type=a name is hostname value is IP address type=ns name is domain (e.g., foo.com) value is hostname of authoritative name server for this domain 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 mailserver associated with name Application Layer 2-12

DNS protocol, messages query and reply messages, both with same message format 2 bytes 2 bytes msg header identification flags identification # questions # authority RRs flags # answer RRs # additional RRs msg body four sections questions (variable # of questions) answers (variable # of RRs) authority (variable # of RRs) additional info (variable # of RRs) Application Layer 2-13

Client-server vs. P2P: example client upload rate = u, F/u = 1 hour, u s = 10u, d min u s Minimum Distribution Time 3.5 3 2.5 2 1.5 1 0.5 0 P2P Client-Server D c-s > max{nf/u s,,f/d min } D P2P > max{f/u s,,f/d min,,nf/(u s + Su i )} 0 5 10 15 20 25 30 35 N Application Layer 2-15

P2P file distribution: BitTorrent file divided into 256Kb chunks peers in torrent send/receive file chunks tracker: tracks peers participating in torrent torrent: group of peers exchanging chunks of a file Alice arrives obtains list of peers from tracker and begins exchanging file chunks with peers in torrent Application Layer 2-16

BitTorrent: requesting, sending file chunks requesting chunks: at any given time, different peers have different subsets of file chunks periodically, Alice asks each peer for list of chunks that they have Alice requests missing chunks from peers, rarest first sending chunks: tit-for-tat Alice sends chunks to those four peers currently sending her chunks at highest rate other peers are choked by Alice (do not receive chunks from her) re-evaluate top 4 every10 secs every 30 secs: randomly select another peer, starts sending chunks optimistically unchoke this peer newly chosen peer may join top 4 Application Layer 2-17

Distributed Hash Table (DHT) DHT = distributed P2P database Database has (key, value) pairs; key: content type; value: IP address Peers query DB with key DB returns values that match the key Central issue: Assigning (key, value) pairs to peers.

Socket programming goal: learn how to build client/server applications that communicate using sockets socket: door between application process and endend-transport protocol application process socket application process controlled by app developer transport network link physical Internet transport network link physical controlled by OS Application Layer 2-20

Socket programming Two socket types for two transport services: UDP: unreliable datagram TCP: reliable, byte stream-oriented Application Example: 1. Client reads a line of characters (data) from its keyboard and sends the data to the server. 2. The server receives the data and converts characters to uppercase. 3. The server sends the modified data to the client. 4. The client receives the modified data and displays the line on its screen. Application Layer 2-21

Socket programming with UDP UDP: no connection between client & server no handshaking before sending data sender explicitly attaches IP destination address and port # to each packet rcvr extracts sender IP address and port# from received packet UDP: transmitted data may be lost or received out-of-order Application viewpoint: UDP provides unreliable transfer of groups of bytes ( datagrams ) between client and server Application Layer 2-22

Client/server socket interaction: UDP server (running on serverip) create socket, port= x: serversocket = socket(af_inet,sock_dgram) read datagram from serversocket write reply to serversocket specifying client address, port number client create socket: clientsocket = socket(af_inet,sock_dgram) Create datagram with server IP and port=x; send datagram via clientsocket read datagram from clientsocket close clientsocket Application 2-23

Example app: UDP client Python UDPClient include Python s socket library from socket import * servername = hostname serverport = 12000 create UDP socket for server get user keyboard input Attach server name, port to message; send into socket read reply characters from socket into string print out received string and close socket clientsocket = socket(af_inet, SOCK_DGRAM) message = raw_input( Input lowercase sentence: ) clientsocket.sendto(message,(servername, serverport)) modifiedmessage, serveraddress = clientsocket.recvfrom(1024) print modifiedmessage clientsocket.close() Application Layer 2-24

Example app: UDP server create UDP socket bind socket to local port number 12000 loop forever Read from UDP socket into message, getting client s address (client IP and port) send upper case string back to this client Python UDPServer from socket import * serverport = 12000 serversocket = socket(af_inet, SOCK_DGRAM) serversocket.bind(('', serverport)) print The server is ready to receive while 1: message, clientaddress = serversocket.recvfrom(1024) modifiedmessage = message.upper() serversocket.sendto(modifiedmessage, clientaddress) Application Layer 2-25

Socket programming with TCP 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 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 that particular client allows server to talk with multiple clients source port numbers used to distinguish clients (more in Chap 3) application viewpoint: TCP provides reliable, in-order byte-stream transfer ( pipe ) between client and server Application Layer 2-26

Client/server socket interaction: TCP server (running on hostid) client create socket, port=x, for incoming request: serversocket = socket() wait for incoming connection request connectionsocket = serversocket.accept() read request from connectionsocket write reply to connectionsocket close connectionsocket TCP connection setup create socket, connect to hostid, port=x clientsocket = socket() send request using clientsocket read reply from clientsocket close clientsocket Application Layer 2-27

Example app: TCP client create TCP socket for server, remote port 12000 No need to attach server name, port Python TCPClient from socket import * servername = servername serverport = 12000 clientsocket = socket(af_inet, SOCK_STREAM) clientsocket.connect((servername,serverport)) sentence = raw_input( Input lowercase sentence: ) clientsocket.send(sentence) modifiedsentence = clientsocket.recv(1024) print From Server:, modifiedsentence clientsocket.close() Application Layer 2-28

Example app: TCP server Python TCPServer create TCP welcoming socket server begins listening for incoming TCP requests loop forever server waits on accept() for incoming requests, new socket created on return read bytes from socket (but not address as in UDP) close connection to this client (but not welcoming socket) from socket import * serverport = 12000 serversocket = socket(af_inet,sock_stream) serversocket.bind((,serverport)) serversocket.listen(1) print The server is ready to receive while 1: connectionsocket, addr = serversocket.accept() sentence = connectionsocket.recv(1024) capitalizedsentence = sentence.upper() connectionsocket.send(capitalizedsentence) connectionsocket.close() Application Layer 2-29

Chapter 2: summary our study of network apps now complete! application architectures client-server P2P application service requirements: reliability, bandwidth, delay Internet transport service model connection-oriented, reliable: TCP unreliable, datagrams: UDP specific protocols: HTTP FTP SMTP, POP, IMAP DNS P2P: BitTorrent, DHT socket programming: TCP, UDP sockets Application Layer 2-30

Chapter 3 Transport Layer Computer Networking: A Top Down Approach 6 th edition Jim Kurose, Keith Ross Addison-Wesley March 2012 Slides adopted from original ones provided by the textbook authors. Transport Layer 3-31

Chapter 3: Transport Layer our goals: understand principles behind transport layer services: multiplexing, demultiplexing reliable data transfer flow control congestion control learn about Internet transport layer protocols: UDP: connectionless transport TCP: connection-oriented reliable transport TCP congestion control Transport Layer 3-32

Chapter 3 outline 3.1 transport-layer services 3.2 multiplexing and demultiplexing 3.3 connectionless transport: UDP 3.4 principles of reliable data transfer 3.5 connection-oriented transport: TCP segment structure reliable data transfer flow control connection management 3.6 principles of congestion control 3.7 TCP congestion control Transport Layer 3-33

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

Transport vs. network layer network layer: logical communication between hosts transport layer: logical communication between processes relies on, enhances, network layer services 12 kids in Ann s house sending letters to 12 kids in Bill s house: hosts = houses processes = kids app messages = letters in household analogy: envelopes transport protocol = Ann and Bill who demux to inhouse siblings network-layer protocol = postal service Transport Layer 3-35

Internet transport-layer protocols reliable, in-order delivery (TCP) congestion control flow control connection setup unreliable, unordered delivery: UDP no-frills extension of best-effort IP services not available: delay guarantees bandwidth guarantees 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 network data link physical network data link physical application transport network data link physical Transport Layer 3-36

Example R6. Is it possible for an application to enjoy reliable data transfer even when the application runs over UDP? If so, how? Transport Layer 3-37

Multiplexing/demultiplexing multiplexing at sender: handle data from multiple sockets, add transport header (later used for demultiplexing) demultiplexing at receiver: use header info to deliver received segments to correct socket application application P3 transport network link P1 P2 transport network link physical application P4 transport network link socket process physical physical Transport Layer 3-39

How demultiplexing works host receives IP datagrams each datagram has source IP address, destination IP address each datagram carries one transport-layer segment each segment has source, destination port numbers host uses IP addresses & port numbers to direct segment to appropriate socket 32 bits source port # dest port # other header fields application data (payload) TCP/UDP segment format Transport Layer 3-40

Connectionless demultiplexing recall: created socket has host-local port #: serverport = 12000 when host receives UDP segment: checks destination port # in segment directs UDP segment to socket with that port # recall: when creating datagram to send into UDP socket, must specify destination IP address destination port # IP datagrams with same dest. port #, but different source IP addresses and/or source port numbers will be directed to same socket at dest Transport Layer 3-41

Connectionless demux: example Port #6428 Port #9157 Port #5775 application P3 transport network link physical application P1 transport network link physical application P4 transport network link physical source port: 6428 dest port: 9157 source port:? dest port:? source port: 9157 dest port: 6428 source port:? dest port:? Transport Layer 3-42

Connection-oriented demux TCP socket identified by 4-tuple: source IP address source port number dest IP address dest port number demux: receiver uses all four values to direct segment to appropriate socket server host may support many simultaneous TCP sockets: each socket identified by its own 4-tuple web servers have different sockets for each connecting client non-persistent HTTP will have different socket for each request Transport Layer 3-43

Connection-oriented demux: example threaded server application application P3 transport network link physical P4 transport network link physical server: IP address B application P2 P3 transport network link physical host: IP address A source IP,port: B,80 dest IP,port: A,9157 source IP,port: C,5775 dest IP,port: B,80 host: IP address C source IP,port: A,9157 dest IP, port: B,80 three segments, all destined to IP address: B, dest port: 80 are demultiplexed to different sockets source IP,port: C,9157 dest IP,port: B,80 Transport Layer 3-44

UDP: User Datagram Protocol [RFC 768] no frills, bare bones Internet transport protocol best effort service, UDP segments may be: lost delivered out-of-order to app connectionless: no handshaking between UDP sender, receiver each UDP segment handled independently of others UDP use: streaming multimedia apps (loss tolerant, rate sensitive) DNS SNMP reliable transfer over UDP: add reliability at application layer application-specific error recovery! Transport Layer 3-46

UDP: segment header 32 bits source port # dest port # length application data (payload) checksum UDP segment format length, in bytes of UDP segment, including header why is there a UDP? no connection establishment (which can add delay) simple: no connection state at sender, receiver small header size no congestion control: UDP can blast away as fast as desired Transport Layer 3-47

UDP checksum Goal: detect errors (e.g., flipped bits) in transmitted segment sender: treat segment contents, including header fields, as sequence of 16-bit integers checksum: addition (one s complement sum) of segment contents sender puts checksum value into UDP checksum field receiver: compute checksum of received segment check if computed checksum equals checksum field value: NO - error detected YES - no error detected. But maybe errors nonetheless? More later. Transport Layer 3-48

Internet checksum: example example: add two 16-bit integers 1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0 1 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 wraparound sum checksum 1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0 1 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1 Note: when adding numbers, a carryout from the most significant bit needs to be added to the result Transport Layer 3-49

Example P3: UDP and TCP use 1s complement for their checksums. Suppose you have the following three 8-bit bytes: 01010011, 01010100, 01110100. What is the 1s complement of the sum of these 8-bit bytes? With the 1s complement scheme, how does the receiver detect errors? Is it possible that a 1-bit error will go undetected? How about a 2-bit error? Transport Layer 3-50