4 Application Protocols FTP SMTP POP and others

4: Application Protocols: FTP, SMTP , POP and others Last Modified: 10/21/2021 2: 38: 23 PM 2: Application Layer 1

FTP r Similar to HTTP in many ways r Fetching files over the network from a server, sending files to a server r Text based commands r But differences too r Separate data and command r Stateful 2: Application Layer 2

2: Application Layer 3

FTP Model (RFC 959) Ftp client FTP server User Interface Server Protocol Interpreter User Protocol Interpreter Server Data Transfer Process File System FTP Commands/ Replies Data Connection User Data Transfer Process File System 2: Application Layer 4

FTP: separate control, data connections r FTP client contacts ftp server at TCP port 21 m Control channel: exchange commands, responses between client, server. “out of band control” r Other parallel TCP connections are opened to transfer file data: m Data channel: file data to/from server, can be used in either direction m Different data channels can be established for each file/data transferred TCP control connection port 21 FTP client TCP data connection FTP server 2: Application Layer 5

ftp commands, responses Sample commands: r sent as ASCII text over control channel r USER username r PASS password (sent in clear text!) r LIST return list of file in Sample return codes r status code and phrase (as r r current directory r RETR filename retrieves r r STOR filename stores r (gets) file (puts) file onto remote host in http) 331 Username OK, password required 125 data connection already open; transfer starting 425 Can’t open data connection 452 Error writing file 2: Application Layer 6

FTP server is stateful r FTP server maintains state: m Current user • Established with USER + PASS • REIN: deletes this state but leaves the control channel open • QUIT: deletes state and closes the control channel m Current working directory • Set to user’s home directory after USER • Changed with CWD • Reset with CDUP 2: Application Layer 7

Transfer Parameters r Client can specify many characteristics of the data channel r PORT – client can specify IP address and port for server to connect to m m PORT a 1, a 2, a 3, a 4, p 1, p 2 = IP address a 1. a 2. a 3. a 4 port p 1*256+p 2 Crazy syntax and also security hole! Hides source of attack (appears as FTP server) Servers on same LAN as FTP server may not be properly configured to defend against attacks from within r PASV – Server will wait for incoming data connection from client (good if client is behind a firewall/NAT) 2: Application Layer 8

FTP timeline CONTROL CHANNEL Data channel for ls Data channel for file retrieval 2: Application Layer 9

2: Application Layer 10

2: Application Layer 11

2: Application Layer 12

2: Application Layer 13

BREAK 2: Application Layer 14

Electronic Mail 2: Application Layer 15

Electronic Mail POP outgoing message queue user agent user mailbox Components: r Mail clients m Composing, editing, reading mail messages r Mail servers m Receive outgoing mail from mail clients via SMTP m Receive incoming mail from other mail servers via SMTP m Allow mail clients to receive incoming mail via POP, IMAP or many times HTTP m Outgoing, incoming messages stored on server HTTP mail server SMTP mail server user agent SMTP mail server IMAP user agent 2: Application Layer 16

Electronic Mail: mail servers Mail Servers r mailbox contains incoming messages (yet to be read) for user r message queue of outgoing (to be sent) mail messages (if message cannot be delivered will stay in queue) r smtp protocol between mail servers to send email messages m Mail server is an SMTP client when sending mail m Mail server is an SMTP server” when receiving mail POP outgoing message queue user agent user mailbox HTTP mail server SMTP mail server user agent SMTP mail server IMAP user agent 2: Application Layer 17

Electronic Mail: smtp [RFC 5321] r Uses tcp to reliably transfer email msg from client to r r server, port 25 direct transfer: sending server to receiving server three phases of transfer m handshaking (greeting) m transfer of messages m closure More stateful than HTTP but less so that FTP command/response interaction m commands: ASCII text m response: status code and phrase m Much like HTTP and FTP 2: Application Layer 18

SMTP History r SMTP has been around a long time r RFC done in 1982 r In use well before that 2: Application Layer 19

Sample smtp interaction S: C: S: C: C: C: S: 220 hamburger. edu HELO crepes. fr 250 Hello crepes. fr, pleased to meet you MAIL FROM: <alice@crepes. fr> 250 alice@crepes. fr. . . Sender ok RCPT TO: <bob@hamburger. edu> 250 bob@hamburger. edu. . . Recipient ok DATA 354 Enter mail, end with ". " on a line by itself Do you like ketchup? How about pickles? . 250 Message accepted for delivery QUIT 221 hamburger. edu closing connection 2: Application Layer 20

try smtp interaction for yourself: r telnet servername 25 r see 220 reply from server r enter HELO, MAIL FROM, RCPT TO, DATA, QUIT commands above lets you send email without using email client (reader) r How do you know the right server name? Trace it – does your mail data go in the clear? 2: Application Layer 21

What is missing? r Some commands processed by SMTP protocol mirror mail headers we are used to seeing in our email messages (To, From, …), but are not the same things r Email headers (To, From, CC, Subject, Date, . . ) are considered part of the data by SMTP and are not processed SMTP server at all! r Email headers are processed by the mail reader software and ignored by SMTP m How is Bcc implemented? r Another example of “protocol” layering (like HTML and HTTP) r BTW, Mail storage format is yet another issue 2: Application Layer 22

Mail message format smtp: protocol for exchanging email msgs RFC 5322: standard for text message format (format of data from smtp perspective) r header lines, e. g. , To: m CC: m Subject: different from SMTP commands! SMTP Data Message headers blank line Message body m r body m the “message”, ASCII characters only 2: Application Layer 23

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: To: bob@hamburger. edu C: Subject: dinner preferences C: From: alice@crepes. fr C: C: Do you like ketchup? C: How about pickles? C: . S: 250 Message accepted for delivery C: QUIT S: 221 hamburger. edu closing connection 2: Application Layer 24

SMTP format r SMTP requires that message (header & body) be in 7 -bit ASCII m Made sense in text-based early days m Requires encoding for binary data (jpegs, etc. ) in 7 -bit ASCII (yuck!) r SMTP server uses CRLF to determine end of message m Can’t have CRLF inside the message itself. If ever want that put CRLF. . CRLF and have the server strip out the extra “. ” 2: Application Layer 25

MIME for sending pictures and other binary data r MIME: multimedia mail extension, RFC 2045, 2046 r additional lines in msg header declare MIME content type MIME version method used to encode data multimedia data type, subtype, parameter declaration encoded data From: alice@crepes. fr To: bob@hamburger. edu Subject: Picture of yummy crepe. MIME-Version: 1. 0 Content-Transfer-Encoding: base 64 Content-Type: image/jpeg base 64 encoded data. . . . . base 64 encoded data 2: Application Layer 26

MIME types: Extensible Content-Type: type/subtype; parameters Text r example subtypes: plain, html Image r example subtypes: jpeg, gif Audio r example subtypes: basic (8 -bit mu-law encoded), 32 kadpcm (32 kbps coding) Video r example subtypes: mpeg, quicktime Application r other data that must be processed by reader before “viewable” r example subtypes: msword, octet-stream 2: Application Layer 27

Multipart Type From: alice@crepes. fr To: bob@hamburger. edu Subject: Picture of yummy crepe. MIME-Version: 1. 0 Content-Type: multipart/mixed; boundary=98766789 --98766789 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain Dear Bob, Please find a picture of a crepe. --98766789 Content-Transfer-Encoding: base 64 Content-Type: image/jpeg base 64 encoded data. . . . . base 64 encoded data --98766789 -- 2: Application Layer 28

Common to send in html and text r From myself to myself in gmail (lots of other things missing inthis example) 2: Application Layer 29

SMTP servers add headers r As they relay mail, SMTP servers add information about themselves m Received: m Message ID: r Definitely a break in strict protocol layering 2: Application Layer 30

Check out examples in your own inbox! r Find the full raw email headers and all m how to see full email headers YOUR_EMAIL_CLIENT m See some examples of what you are looking for r Find at least one header you recognize from this lecture r Find at least one header you don’t recognize 2: Application Layer 31

When mail server can’t send r Warnings from mailserver r Failures from mailserver 2: Application Layer 32

BREAK 2: Application Layer 33

Receiving Side of Email 2: Application Layer 34

SMTP vs HTTP r Smtp: persistent connections like HTTP 1. 1 r Both have ASCII command/response interaction, status codes r http: each object is encapsulated in its own response message r smtp: multiple objects message sent in a multipart message r http: pull; smtp: push 2: Application Layer 35

SMTP = outgoing r Notice we didn’t see any SMTP commands to “get” or “retrieve” mail r SMTP is for outgoing mail only r How do we get mail? m Early days: log on to server and read mail from a mailbox = file on server m How many people still read mail that way? m Today most people read mail on their PC m How do they get their mail from the mail server? 2: Application Layer 36

Incoming mail? user agent SMTP sender’s mail server receiver’s mail server r Mailbox file r POP: Post Office Protocol [RFC 1939] >server) and download POP 3 IMAP HTTP user agent authorization (agent <-- more features (more complex) manipulation of stored messages on server r IMAP: Internet Mail Access Protocol [RFC 1730] r HTTP: Gmail, Hotmail , Yahoo! Mail, etc. m m Why not use HTTP to transfer random things like email? Convenient – don’t need mail reader just the ubiquitous web browser r Other? 2: Application Layer 37

Why not just SMTP server on local machine? r “Push not pull” means your PC must be constantly on to accept “push” 2: Application Layer 38

POP 3 protocol authorization phase r client commands: user: declare username m pass: password r server responses m +OK m -ERR m transaction phase, client: r list: list message numbers r retr: retrieve message by number r dele: delete r Quit S: C: S: +OK POP 3 server ready user alice +OK pass hungry +OK user successfully logged C: S: S: S: C: C: S: list 1 498 2 912. retr 1 <message 1 contents>. dele 1 retr 2 <message 1 contents>. dele 2 quit +OK POP 3 server signing off 2: Application Layer 39 on

try POP interaction for yourself: r telnet servername 110 r see “OK POP 3 server ready” reply from server r enter user, pass, list, retr, dele commands above lets you send get you own email without using email client (reader) Trace it – do your password and mail data go in the clear? Do you configure your mail reader to pop mail every X minutes? Same as announcing your password regularly (unless over Kerberos etc)! 2: Application Layer 40

IMAP r Allows user to set up and maintain multiple folders (for sorting mail) on the remote server r Can get headers for and manipulate messages without downloading them (can even download individual MIME attachments) m m Don’t pay cost to download over slow link Don’t leave them on insecure computers r Stateful protocol - stores per user information about folders and the status of the messages in them m Folder information, actual messages Seen, Deleted, Answered flags per message POP stateful too but just username/password 2: Application Layer 41

IMAP con’t r During an IMAP connection, the server transitions between multiple states m Initially non-authenticated m Authenticated m Selected – folder selected and operations on messages permitted m Finally, Logout state r Authentication is more complicated in IMAP than username/password we saw in FTP and POP 2: Application Layer 42

Authentication in IMAP r Client requests a certain AUTHENTICATION method C: A 001 AUTHENTICATE KERBEROS_V 4 r If server implements that authentication mechanism then it will authenticate via that method S: + Am. FYig== C: BAc. AQU 5 EUk. VXLk. NNVS 5 FRFUAOCAsho 84 k. L N 3/IJmr. MG+25 a 4 DT+n. ZIm. Jjn. TNHJUtx. AA+o 0 KPKf. H Ec. AFs 9 a 3 CL 5 Oebe/yd. HJUw. YFd S: + or//Eo. AADZI= C: Di. AF 5 A 4 g. A+o. OIALu. Bk. AAmw== S: A 001 OK Kerberos V 4 authentication successful r Sever can respond with NO if it does not support that authentication mechanism S: A 001 NO authenticate failure 2: Application Layer 43

Authentication in IMAP (cont) r Client can try various authentication mechanisms in decreasing order of preference looking for one the server supports r In the worst case, a client may authenticate with plain text login C: a 001 LOGIN SMITH SESAME S: a 001 OK LOGIN completed 2: Application Layer 44

Once authenticated, client can: r SELECT a mailbox C: A 142 SELECT INBOX S: * 172 EXISTS S: * 1 RECENT S: * OK [UNSEEN 12] Message 12 is first unseen S: * OK [UIDVALIDITY 3857529045] UIDs valid S: * FLAGS (Answered Flagged Deleted Seen Draft) S: * OK [PERMANENTFLAGS (Deleted Seen *)] Limited S: A 142 OK [READ-WRITE] SELECT completed r CREATE, RENAME or DELETE mailboxes r FETCH messages from a mailbox r SEARCH through messages r APPEND messages to a mailbox 2: Application Layer 45

Pop vs IMAP r Similarities m Mail delivered to a shared, constantly connected server m New mail accessible anywhere in network on a variety of platforms m For access only, Need SMTP to send mail r Differences m POP simpler and more established (more clients and servers that support it) m IMAP keeps more state and has more features; POP uses less server resources m IMAP = prioritize download time; POP = shorter overall connection time 2: Application Layer 46

Mailservers play different roles r Be careful to identify the role played by a specific mailserver r Incoming mail to a domain m May refuse to take RCPT TO other domains r Allow users to get their incoming mail m May not do SMTP at all m Typically do require authentication r Outgoing mail from a domain m May require authentication from valid user m May require that MAIL FROM match domain r Can have one mail server do it all and can have no checking OR can divy up into specific roles and enforce those 2: Application Layer 47

r IMAP uses port 143, but SSL/TLS encrypted IMAP uses port 993. r POP uses port 110, but SSL/TLS encrypted POP uses port 995. r SMTP uses port 25, but SSL/TLS encrypted SMTP uses port 465. 2: Application Layer 48

BREAK 2: Application Layer 49

r How it works when it is working correctly can be complicated …hopefully you are getting a feeling for that r What happens when things go wrong is a whole other level m Delivery problems m Fake mail m Spam mail 2: Application Layer 50

Problems during sending r SMTP server takes an email agreeing to try and deliver it r Can’t promise because things can go wrong m Account disabled m Mailbox full m We will keep trying but still haven’t succeeded m Going around in a loop m Blacklisted senders, recipients, etc. m …… r Tries to alert sender m Have you gotten a bounce email like that? 2: Application Layer 51

What can you trust? r Unreliable headers r Fake mail r What can you trust and what can’t you trust 2: Application Layer 52

r Often these error reporting emails contain details from the headers r “Received: ” and “Message. ID” headers are part of the data m Accurate and helpful from legitimate servers and user agents m But not trustworthy from spam servers r Mail rarely relayed multiple hops anymore m Sometimes mail servers and also spam blocking appliances, etc. 2: Application Layer 53

2: Application Layer 54

2: Application Layer 55

Spam/forged mail r Chain of Received headers also useful in tracking spam mail r Important to know that servers can lie and add things that never happened to throw off the trail r Start with a legitimate server you trust and verify the Mail From field (resolvable domain and matching IP address) r Work backwards and find a “break” in the chain r Consult their databases to corroborate 2: Application Layer 56

2: Application Layer 57

Spamcop r In each received line, compare hostname of machine received from versus the IP address m Does the hostname resolve to that IP address? m Is that IP address listed as an MX for the domain listed in the hostname? r Believe first parse line, consider discarding others as bogus m Does first receive line list a well know relay? http: //www. monkeys. com/upl/index. html m If no, discard others 2: Application Layer 58

Reporting Spam r Spamcop uses a combination of tools like dig, nslookup and finger to cross-check all the information in an email header and find the email address of the system administrator responsible for the network from which the mail was sent r postmaster@domain or abuse@domain r Warning: reporting spam to a spammer domain tells them you are a real person 2: Application Layer 59

Mail Server Anti-spam configuration r Do not relay mail except from specified sources (IP addresses within your own domain) r Check for valid machine names in “MAIL FROM” r Identify based on matches to “spam profiles” (keywords, etc. ) r Refusing to receive mail from blacklisted IP addresses m Spamhaus and Spamcop r Reaction: mark as spam or drop before reaches intended recipient? Act silently or give feedback to sender? 2: Application Layer 60

Sender Policy Framework (SPF) r RFC 4408 r Allows the owner of a domain to specify their mail sending policy m E. g. they can specify which mail servers they use to send mail *from* their domain r SPF record in DNS r SPF query tool: m http: //www. kitterman. com/spf/validate. html 2: Application Layer 61

2: Application Layer 62

Interesting mail to examine r Most “Received headers” r Mail from and to yourself at different mail servers r Spam mail r Advertizing mail r Mailing lists r Mail from Moodle r …. . r A interesting project idea m Look at errors, mail architectures of organizations, etc 2: Application Layer 63

2: Application Layer 64

More Application Level Protocols? r Telnet, Rlogin, SNMP (Simple Network Management Protocol), Instant Messenger (AIM), DHCP (BOOTP) , RPC, NFS, X, Finger, Whois, IDENT…………………. . r Any ones that you really wish we’d cover? r You now know how to investigate any of these on your own m RFCs for open protocols, Run apps and trace them, Get client/server source, … r It would be a lot more fun to learn more than application level protocols though, right? 2: Application Layer 65

Roadmap r We’ve looked at a bunch of application level protocols (HTTP, DNS, FTP, SMTP, POP, IMAP, , . . ) – Lessons? m m m Many were human readable – why? High level examples of protocol layering (SMTP, HTTP) Some ran on TCP, some on UDP, one on both – why? Used telnet/nslookup to interact with these protocols more directly Traced them (What went in clear text? !) r Food-for-thought: Design a “Telephone Protocol” other choices? r Next. . How would we implement an application level protocol ourselves? m Socket API r After that down to transport layer 2: Application Layer 66

Outtakes 2: Application Layer 67

r nslookup m set query=txt m clarkson. edu r v=spf 1 mx a: mymail. clarkson. edu a: lists. clarkson. edu a: janus. clarkson. edu a: web 2. clarkson. edu a: milhouse. clarkson. edu a: outbound. clarkson. edu a: bulkmail. clarkson. edu 2: Application Layer 68

Network News Thanks to Jeffrey Vinocur (NNTP presentation, Spring 2002) 2: Application Layer 69

What is Usenet? r Reading/posting to Usenet newsgroups r Conceptually: a semi-organized collection of forums (“newsgroups”) for public discussion r Technically: a system for distributing email-like messages 2: Application Layer 70

Usenet Messages r Format: like email, but a bit stricter and with some extra headers (e. g. , Newsgroups) – we don’t care about this today, except for two important headers r Message-ID: unlike email, every message truly needs to have a globally unique identifier r Path: we’ll see this header later 2: Application Layer 71

Path: news. litech. org!lnsnews. lns. cornell. edu!paradoxa. ogoense. net!not-for-meow From: meowbot@meowing. net (A Meowbot) Newsgroups: alt. dev. null Subject: Why? Date: Sun, 27 Jan 2002 23: 25: 52 +0000 (UTC) Organization: a tyranny of meowing fascist censor cabalists Lines: 4 Approved: nope. Message-ID: <m. W. 3 C 548 C 72. 8 BC 5@K 0 de. Z. scriptkiddie. net> X-Trace: paradoxa. ogoense. net 1012173952 6565 141. 154. 205. 147 (27 Jan 2002 23: 25: 52 GMT) X-Complaints-To: abuse@ogoense. net X-Meow: Wouf Mail-Copies-To: nobody X-No-Repost: yes Xref: news. litech. org alt. dev. null: 492 Because we like you. -Meow 2: Application Layer 72

Network Topology r Users connect to a local site r Each site may have several servers for better throughput r Sites are connected by (manually-requested and -configured) peering links to other sites r Major sites have hundreds of peers 2: Application Layer 73

So I post…then what? r The goal is for every article to make it to every server in the world – the “floodfill” model r This can be as fast as a few seconds or as long as a few days (normally a few hours) 2: Application Layer 74

Serious bandwidth Credit: CAIDA (1999) 2: Application Layer 75

An article arrives… This can be either a new post from a user or an article being “fed” from a peering server. The server’s “name” added to the Path header (history of where the article has been) 2. The server stores the article so users can read it 3. For each of the server’s peers, determine if the peer has seen the article already (first check for peer’s name in Path header, then ask the peer about the Message-ID) 4. Send the article to peers who do not have it 1. 2: Application Layer 76

Path headers and Message-IDs r Let’s trace an article. The initial component (at the end!) of the Path header marks the original posting server; then the originating server adds its name: Path: paradoxa. ogoense. net!not-for-meow r Then this article gets fed to a another server and then add their hostname: Path: lnsnews. lns. cornell. edu!paradoxa. ogoense. net!not-for-meow r And then it gets fed to another server… Path: news. litech. org!lnsnews. lns. cornell. edu!paradoxa. ogoense. net!not-for-meow 2: Application Layer 77

Usenet, 1980 Credit: Mark Horton reed phs / uok---duke-unc / research vax 135 | ucbvax 2: Application Layer 78

Usenet, 1981 Credit: ucbvax!mark pdp (Misc) ! (NC) (Misc) decvax sii reed phs--unc--grumpy duke 34 utzoo cincy teklabs ! ! ! +--+-----+-+--+-------+------+ ! ! ! duke ! ! ! +------+------------+----+ ! ! ! ! ucbopt ! hocsr--mhtsa----research mh 135 a harpo-----chico : ! ! ucbcory ! ! eagle ihnss vax 135 (Bell Labs) (UCB) : ! ! ! ucbvax--++-----+--+--+------+----+ : @ ! ! ! (Silicon Valley) ucbarpa @ (UCSD) sdcsvax ! menlo 70 --hao : @ sdcattb-----+ ! ! ! ucbonyx @ +-----ucsfcgl sytek sri-unix @ phonlab-----+ cca-unix sdcarl !Uucp links : @ Berknet links Arpanet links 2: Application Layer 79

Usenet, 1993 Credit: Brian Reid 2: Application Layer 80

Usenet today Credit: Karl L. Swartz r 1. 4 million articles daily r ~ 360 GB daily r Over a 100 Mbit/sec link is > 8 hours! 2: Application Layer 81

Usenet is like a herd of performing elephants with diarrhea – massive, difficult to redirect, awe-inspiring, entertaining, and a source of mind-boggling amounts of excrement when you least expect it. – Professor Gene Spafford, Purdue University 2: Application Layer 82

Multimedia Applications 2: Application Layer 83

Multimedia Applications r Audio/video conferencing, streaming audio, etc. m On-demand playback: could download before beginning playback; could support rewind, fast forward etc. ; startup time and RTT not very important m Live transmission: usually broadcast from one source like TV or radio; much like on demand; no rewind or fast forward; more sensitive to delay (how close to live? ) m Conferencing: interactive, start-up time and RTT matter alot r Examples: vic (video conferencing), vat (audio conferencing), Real. Audio, Quicktime, Windows. Media 2: Application Layer 84

Requirements of multimedia r Several methods for compressing and encoding r r r voice/video; sender and receiver negotiate Ability to display stream (at degraded quality) with lost packets Ability to specify the timing requirements between packets of related data for smooth playback Frame boundary indication Synchronization of related audio and video streams No retransmission of lost packets 2: Application Layer 85

Real-time Transport Protocol (RTP) r TCP overhead to high; UDP not good enough r Initially, each application had its own protocol, implementing only those parts of TCP it really needed on top of UDP r RTP offers generalized real time transport services m m m Thin protocol; Runs on top of UDP Implements functionality commonly needed by multimedia applications - timing reconstruction, loss detection, security and content identification RFC 1889 2: Application Layer 86

Realtime Transport (? ) Protocol r Is this an application level protocol or a transport protocol? m Done at application level m If TCP implemented at application level (good project ), does that make it an application level protocol or a transport level protocol? r Where is the right place to put these features? 2: Application Layer 87

Real-time Streaming Protocol (RTSP ) r Network “Remote Control” m Like FTP has data channel and control channel; RTSP is the control channel for streaming audio/video m Not used to deliver data; often uses RTP for the data portion r Establishes and controls audio and video delivery m Single or multiple audio/video streams (time synchronization if desired) m Live feeds or stored clips r Industry consortium announced in 1996 – since then? m Mostly development continued on proprietary versions: Real Network’s (originally Progressive Networks) Real. Media, Real. Audio and Real. Player , Quicktime, Windows. Media? ? ? 2: Application Layer 88

RTSP Requests r DESCRIBE – description of presentation r OPTIONS - get supported methods; capability r r r r announcements SETUP – establish a new session PLAY – start playback/streaming; reposition ANNOUNCE – change description of presentation RECORD – start recording REDIRECT – redirect client to a new server; for load balancing PAUSE –stop delivery but keep state TEARDOWN – stop delivery, remove state 2: Application Layer 89

Trying RTSP r telnet servername 554 C: DESCRIBE rtsp: //streamserver/rafile. rm RTSP/1. 0nn S: RTSP/1. 0 200 2: Application Layer 90

Trying RTSP (2) C: SETUP rtsp: //audio. example. com/twister/audio RTSP/1. 0 Transport: rtp/udp; compression; port=3056; mode=PLAY S: RTSP/1. 0 200 1 OK Session 4231 C: PLAY rtsp: //audio. example. com/twister/audio. en/lofi RTSP/1. 0 Session: 4231 Range: npt=0 C: PAUSE rtsp: //audio. example. com/twister/audio. en/lofi RTSP/1. 0 Session: 4231 Range: npt=37 C: TEARDOWN rtsp: //audio. example. com/twister/audio. en/lofi RTSP/1. 0 Session: 4231 S: 200 3 OK 2: Application Layer 91

RTSP vs HTTP r RTSP actually derived from HTTP m Avoid mistakes (like always specify full URI) m More methods of course r RTSP server needs to maintain state from SETUP to control PLAY command; HTTP server is stateless (uses cookies to trick client into remembering it) r Data can be delivered in or out of band with RTSP; HTTP data delivered in band r RTSP is a symmetric protocol (client and server can both issue requests); HTTP client issues requests m Ex. server can announce new available streams (audio from a new participant in a conference) 2: Application Layer 92

Session Description Formats r Format for describing the number and sources for all streams in a presentation r May offer alternatives m Different audio channels in various languages m Different quality of audio/video for various BW connections r Specify timing requirements between various streams r Examples: SDF, SDP 2: Application Layer 93

SDP example session (v 0)(o mhandley 2890844526 2890842807 IN IP 4 126. 16. 64. 4) (s Sd seminar)(i A seminar on the session description protocol) (u http: //www. cs. ucl. ac. uk/staff/M. Handley/sdp. 01. ps) (e M. Handley@cs. ucl. ac. uk (Mark Handley)) (c IN IP 4 224. 2. 17. 12/127)(t 2873397496 2873404696) (a recvonly) (all (media (m audio 3456 VAT PCMU)) (media (m video 2232 RTP H 261)) (media (m whiteboard 32416 UDP WB)(orient portrait)) )) From: http: //www. cs. columbia. edu/~hgs/rtsp/sdf. html 2: Application Layer 94

From URL in web page to streaming audio/video <EMBED SRC=“http: //server/foo. sdf” TYPE = “application/x-audio”> r HTTP gets session or presentation description file ( not part of RTSP) from a web server r Presentation Description indicates RTSP server to contact m Note: RTSP is presentation description format neutral r RTSP sets up a stream to control delivery r RTSP used to indicate server that will actually stream the data and by what protocol m Ex. specify an RTP server to deliver the data r Note: possibly 3 servers involved! 2: Application Layer 95

Alternative: HTTP Streaming r Many sites simply send audio and video over HTTP r When object arrives will be opened by appropriate application just like Doc files or PDF files r Estimate when it is safe to begin playback without the playback outpacing the download r Download mode and a limited streaming mode can be supported this way m m Rewind? Fast forward? Can support full streaming if delays ok 2: Application Layer 96

Audio and Video on the Internet r Quicktime m HTTP streaming or RTP and RTSP r Real. Server m one control channel: RTSP over TCP m one data channel: PNA (Progressive Networks Audio) over UDP (? ) m Also can use RTSP to interleave data and control onto one TCP channel (common configuration) r Windows. Media m Similar to Real. Player: control channel and data channel m Harder to find details of protocols (surprise, surprise) m But formats are not compatible (surprise, surprise) 2: Application Layer 97

Email viruses r Often attachments which once opened run with the users full privileges and corrupt the system on which mail is read r Viruses tend to target Windows as it is the platform used by the majority of people 2: Application Layer 98

More FTP r Details about TYPE and MODE commands r REST – restart at specified data checkpoint 2: Application Layer 99

FTP minimum requirements r MINIMUM IMPLEMENTATION In order to make FTP workable without needless error messages, the following minimum implementation is required for all servers: TYPE - ASCII Non-print MODE - Stream STRUCTURE - File, Record COMMANDS - USER, QUIT, PORT, TYPE, MODE, STRU, for the default values RETR, STOR, NOOP. The default values for transfer parameters are: TYPE - ASCII Non-print MODE - Stream STRU - File All hosts must accept the above as the standard defaults. 2: Application Layer 100

telnet source r We’ve been using telnet to examine various application protocols r telnet basically opens a TCP connection to the specified port r Getting the telnet source and examining it would be a good exercise 2: Application Layer 101

Real Time Control Protocol (RTCP) r Real-time conferencing of groups of any size within an internet. r Provides source identification, quality-ofservice feedback from receivers to the multicast group, synchronization of different media streams 2: Application Layer 102

Re. Ser. Vation Protocol (RSVP) r Host can use to request specific quality of service from the network for a specific flow of data r Must be processed and honored at each router to be meaningful m m Works much like dynamic routing protocols; messages processed by applications at user level If a flow is “admitted” then resource reservation decisions will be made in form of packet classifier and schedulers that will prioritize the use of resources r Cisco’s take on RSVP m http: //www. cisco. com/univercd/cc/td/doc/cisintwk/ito_ doc/rsvp. htm 2: Application Layer 103

Multiple recipients r When you send mail to your outgoing mail server, transfer one copy of message regardless of how many recipients r Mail servers could play the same trick m Look at RCPT to list m If more than one recipient per destination mail server then transfer just one mail r Could also send one copy per recipient m Recommended configuration? 2: Application Layer 104