data connection management 1 ftp commands, responses over 30 are - PDF document

ftp: File Transfer Protocol FTP file transfer FTP FTP user client server interface user remote file local file at host system system v ftp specification: RFC 959 (http://www.ietf.org/rfc/rfc959.txt) data connection management 1

ftp commands, responses over 30 are available Sample return codes v sent as ASCII text over control conn. v authentication: user, pass v status code and phrase (as in http) v file access: e.g. put, get v 331 Username OK, password v file transfer control: mode required v directory: pwd, list, delete v 125 data connection already v ftp session: help, stat, abort, quit open; transfer starting Sample commands: v 425 Can’t open data connection v USER username v 452 Error writing file v PASS password v LIST: return list of file in the current directory v RETR filename : retrieves (gets) file v STOR filename: stores (puts) file onto remote host Electronic Mail outgoing Three major components: message queue v user agents user mailbox v mail servers v simple mail transfer protocol(smtp) user agent User Agent mail user v composing, editing, reading mail msgs server agent Eudora, Outlook, elm, Netscape ÿ SMTP Messenger mail v outgoing, incoming messages stored on server user server SMTP agent Mail Servers SMTP v mailbox contains incoming messages user (yet to be read) for user mail agent v message queue of outgoing (to be sent) server mail messages user SMTP protocol between mail servers agent user agent 2

how a sender contacts a SMTP server v an SMTP server process running on every SMTP server host, waiting for incoming mail v TCP port# (25) is permanently assigned to SMTP (“well-known port”) v sender opens a TCP connection to the dest. application layer SMTP server mailman.cs.ucla.edu data socket port 25 Email delivery TCP port 25 Your email application program mail server user SMTP user agent SMTP daemon sender SMTP user User SMTP user agent mailbox daemon POP receiver mail server 3

Simple Mail Transfer Protocol [RFC 821] Sample smtp interaction S: 220 hamburger.edu C: HELO crepes.fr S: 250 Hello crepes.fr, pleased to meet you C: MAIL FROM: <alice@crepes.fr> S: 250 alice@crepes.fr... Sender ok C: RCPT TO: <bob@hamburger.edu> S: 250 bob@hamburger.edu ... Recipient ok C: DATA S: 354 Enter mail, end with "." on a line by itself C: Do you like ketchup? C: How about pickles? C: . S: 250 Message accepted for delivery (if more msgs to send, start from "MAIL FROM" again) C: QUIT S: 221 hamburger.edu closing connection 4

A typical SMTP message exchange (after the TCP connection setup) sender SMTP process receiver SMTP process 220 whitehouse.gov SMTP ready HELO foo.berkeley.edu 250 whitehouse.gov MAILFROM:<john@foo.berkeley.edu> 250 OK RCPT TO: <clinton@whitehouse.gov> 250 OK RCPT TO: <al@whitehouse.gov> 550 No such user DATA 354 start mail input blah blah blah ..... <CRLF>.<CRLF> 250 OK QUIT 221 whitehouse.gov service closing Are there some basic rules behind the reply codes? Code meaning 220 service ready 221 I’m closing too 250 requested action OK 500 error, command not recognized 550 no such mbox, no action taken Common practices 1st digit: whether response is good/bad/incomplete e.g. 2= positive completion, 5=negative completion 2nd digit: encodes responses in specific categories e.g. 2=connections, 5=mail system (status of the receiver mail system) 3rd digit: a finer gradation of meaning in each category specified by the 2nd digit. 5

smtp: final words v smtp uses persistent Comparison with http connections v http: pull v smtp requires that message v email: push (header & body) be in 7-bit ascii v certain character strings are v both have ASCII not permitted in message (e.g., command/response interaction, CRLF.CRLF ). Thus message status codes body must be encoded if it v http: each object is contains forbidden characters encapsulated in its own v smtp server uses CRLF.CRLF to response message determine end of message v smtp: multiple objects message sent in a multipart message Mail message format RFC 821: SMTP specification (protocol for exchanging email msgs) header blank RFC 822: standard for text line message format: v header lines, e.g., body ÿ To: ÿ From: ÿ Subject: different from smtp commands ! v body ÿ the “message”, ASCII characters only 6

Message format: extension for multimedia MIME: Multipurpose Internet Mail Extension v additional lines in msg header declare MIME content type From: alice@crepes.fr MIME version To: bob@hamburger.edu Subject: Picture of yummy crepe. method used MIME-Version: 1.0 to encode data Content-Transfer-Encoding: base64 Content-Type: image/jpeg multimedia data type, subtype, base64 encoded data ..... parameter declaration ......................... ......base64 encoded data encoded data Mail access protocols SMTP SMTP POP3 or user user IMAP agent agent receiver’s mail sender’s mail server server Mail access protocol: retrieval from mail server v POP: Post Office Protocol [RFC 1939] ÿ authorization (agent <-->server) and download v IMAP: Internet Mail Access Protocol [RFC 1730] ÿ more features, such as msg folders on the server ß more complex implementation ÿ manipulation of stored msgs on server v HTTP: Hotmail , Yahoo! Mail, etc. 7

POP3 protocol S: +OK POP3 server ready authorization phase C: user alice v client commands: S: +OK ÿ user: declare C: pass hungry username S: +OK user successfully logged on ÿ pass: password C: list v server responses S: 1 498 ÿ +OK S: 2 912 ÿ -ERR S: . transaction phase, C: retr 1 client: S: <message 1 contents> v list: list message S: . C: dele 1 numbers C: retr 2 v retr: retrieve message S: <message 1 contents> by number S: . v dele: delete C: dele 2 v quit C: quit S: +OK POP3 server signing off telnet (RFC854) v A TCP connection used to transmit data with interspersed TELNET control information v Client side of the TCP connection initiates a request, the server accepts or rejects the request. v Telnet server uses port# 23 ÿ the client side can use any unreserved port. application telnet process client User's key board operating operating & display system system Internet 8

client-server paradigm v any program can become a network application client when it needs network services v servers are special purpose applications dedicated to providing specific service ÿ server processes start at system initialization time v applications at both ends take initiative ÿ server application informs local OS that it is ready to take incoming messages ß wait for incoming messages ß perform requested service ß return results ÿ client application contacts the server ß send request ß wait for reply identifying servers and services v each service is assigned a unique well-known port number v server application process registers with local protocol software with that port # v a client requests a service by sending request to a specific server host with the well-known port # v server handles multiple requests concurrently 9

Chapter 3: Transport Layer Chapter goals: v Principles behind transport layer services: ÿ multiplexing/demultiplexing ÿ reliable data transfer ÿ flow control ÿ congestion control v instantiation and implementation in the Internet Chapter Overview: v transport layer services; multiplexing/demultiplexing v connectionless transport: UDP v connection-oriented transport: TCP ÿ How to achieve reliable data delivery v TCP congestion control Transport services and protocols v data delivery between app’ processes running on different hosts application transport v transport vs network layer network data link network services: physical data link logical end-end transport physical network data link physical network data link physical network Internet transport services: data link physical v unreliable, unordered delivery: network data link UDP physical application transport v reliable, in-order delivery(TCP) network data link physical 10

Multiplexing/demultiplexing Multiplexing Demultiplexing data segments from multiple delivering received data segments to corresponding app processes is sent to lower layer for transmission upper layer protocols/apps Application data P3 transport P1 P2 P4 M M header M M application application Some segment transport transport Ht M other network network Hn segment host sender receiver Multiplexing/demultiplexing: examples source port: x Web clients server B host A dest. port: 23 host C source port:23 dest. port: x Source IP: C Source IP: C Dest IP: B Dest IP: B sour port: 2211 sour port: 1180 port use: simple telnet app dest. port: 80 dest. port: 80 Source IP: A Web Dest IP: B Web client sour port: 1180 server B dest. port: 80 host A port use: Web server 11

UDP: User Datagram Protocol [RFC 768] v “best effort” service: UDP segments may be lost, or delivered out of order to applications v connectionless: UDP format 32 bits source port # dest port # Length of UDP length checksum segment (in bytes), including header Application data (message) UDP checksum Goal: detect bit errors (e.g., flipped bits) in transmitted segment Sender: Receiver: v treat data in the segment as v compute checksum of received sequence of 16-bit integers segment v checksum: addition (1’s v check if computed checksum equals complement sum) of segment checksum field value: contents ÿ NO - error detected v puts checksum value into UDP ÿ YES - no error detected checksum field 12