Courses/Computer Science/CPSC 441.W2014/Chapter 2: Application Layer

From wiki.ucalgary.ca
< Courses‎ | Computer Science‎ | CPSC 441.W2014
Revision as of 01:24, 25 April 2014 by Cmah (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Navigation

Course Overview

Application Layer

Transport Layer

Network Layer

Datalink Layer

Advanced Topics

Extra

Networking Basics

Chapter 2

Chapter 3

Chapter 4

Chapter 5

Chapter 7

Tutorials

Chapter 1

HTTP Over TCP

Chapter 6

Links

Quiz Review

Textbook Notes

Contents

Introduction

Hello, my name is Carrie Mah and I am currently in my 3rd year of Computer Science with a concentration in Human Computer Interaction. I am also an Executive Officer for the Computer Science Undergraduate Society. If you have any questions (whether it be CPSC-related, events around the city, or an eclectic of random things), please do not hesitate to contact me.

I hope you find my notes useful, and if there are any errors please correct me by clicking "Edit" on the top of the page and making the appropriate changes. You should also "Watch this page" for the CPSC 441 page to check when I upload notes. Just click "Edit" and scroll down to check mark "Watch this page."

You are welcome to use my notes, just credit me when possible. If you have any suggestions or major concerns, please contact me at cmah[at]ucalgary[dot]ca. Thanks in advance for reading!

Course Information

Disclaimer: This is a page created by a student. Everything created and written by me is not associated with the Department of Computer Science or the University of Calgary. I am not being paid to do this nor am getting credit. I was a class scribe for CPSC 457 and enjoyed it so much that I wanted to continue it with a course related to it. I find writing Wiki notes for courses I am not familiar with are helpful for me, so I hope you find these notes helpful. I encourage that you still write your own notes, as it helps you retain information, but my notes are public and free to use!

This course is for W2014, taught by Dr. Carey Williamson.

The course website is here: http://pages.cpsc.ucalgary.ca/~carey/CPSC441

Chapter 2: Application Layer

  • Notes adapted from slides created by JFK/KWR and lectures held by Dr. Carey Williamson
  • All material copyright 1996-2012 © J.F Kurose and K.W. Ross, All Rights Reserved

Section 2.1: Principles of Network Applications

  • Some network apps
  • Big three:
  • FTP, e-mail, remote login
  • Web, text messaging, multi-user network games, streaming stored video (Youtube, Hulu, Netflix), voice over IP (e.g. Skype), real-time video conferencing, social networking, search…

Creating a Network App

  • Write programs that:
  • Run on (different) end systems
  • Communicate over network
  • Obey vertical API of how messages get handed down in OS kernel for transmission across network
  • E.g. web server software communicates with browser software
  • No need to write software for network-core devices
  • Network-core devices do not run user applications
  • Applications on end systems allows for rapid app
  • Make sure messages get passed down the right API
  • End systems have full stack, communicate in illusion of horizontal communication
  • Web browser talks to web server, illusion talks horizontally without magic underneath; in reality there’s the passing though


  • Application architectures
  • Possible structure of applications:
  • Client-server
  • Peer-to-peer (P2P)

Client-Server Architecture

  • Server:
  • Always-on host
  • Permanent IP address
  • Data centers for scaling
  • Clients:
  • Communicate with server
  • May be intermittently connected
  • May have dynamic IP address
  • Server is special, and client is cheap and ubiquitous
  • File server, web server, video server, name server, file server
  • Put extra investments and resources that have high storage capacity, server gets permanent IP address, always on
  • Clients: from anywhere, clients are plentiful and cheap; they come and go

P2P Architecture

  • No always-on server
  • Arbitrary end systems directly communicate
  • Peers request service from other peers, provide service in return to other peers
  • Self scalability: new peers bring new service capacity, as well as new service demands
  • When you join a P2P network, you’re requesting stuff from other people; but you actually share stuff with that network
  • Content, storage you share
  • Peers are intermittently connected and change IP addresses
  • End systems can talk to other end systems and negotiate sharing of content
  • User-generated content, P2P sharing, copyright, etc.
  • Everyone is equal, can share/download content, play symmetrical role of being a provider to some others and being a consumer from others – make social good better for everybody

Processes Communicating

  • Process: program running within a host
  • Within same host, two process communicate using inter-process communication (defined by OS)
  • Processes in different hosts communicate by exchanging messages
  • Client process: process that initiates communications
  • Server process: process that waits to be contacted
  • Aside: applications with P2P architectures have client processes and server
  • Built using socket programming API
  • Way to send data from on process to another
  • Socket: magic door – stick data in socket and magically whisked away by data fairies from other end

Sockets

  • Process sends/receivers messages to/from its socket
  • Socket analogous to door
  • Sending process shoves message out the door
  • Sending process relies on transport infrastructure on other side of door to deliver message to socket at receiving process
  • Socket API – programmer invokes socket-based communication to invoke data in/out of kernel and network interface

Code Examples: Demo

  • wordlengthserver code and wordlengthclient code
  • Give it a text string, and it tells you how many characters there are
  • Server using TCP, sitting in a passive loop waiting for clients to contact it
  • Compile with –lsocket on server
  • Compile with –lsocket –lnsl for client
  • One screen with server, another with client
  • Every time talk to server, it spawns a new child process to communicate with the client
  • “CAT” is 3 letters; server sends the answer 3 and client receives the answer
  • When server sends 3, sends an ASCII string with the ‘3’ character
  • Main listener in server; forks a new child process when communicating with client

Addressing Processes

  • To receive messages, process must have identifier
  • Host device has unique 32-bit IP address
  • Q: Does IP address of host on which process runs suffice for identifying the process?
  • A: No, many processes can be running on same host
  • Identifier includes both IP address and port numbers associated with process host
  • Example port numbers:
  • HTTP server: 80
  • Mail server: 25
  • To send HTTP message to gaia.cs.umass.edu web server:
  • IP address: 128.119.245.12
  • Port number: 08

App-layer Protocol Defines

  • Variety of commands that you can send back and forth
  • Types of messages exchanged
  • E.g. request, response
  • Message syntax
  • What fields in messages and how fields are delineated
  • Where does URL go, what commands go, key-value pairs
  • Message semantics
  • Meaning of information in fields
  • Example: GET <retrieve file>
  • Rules for when and how processes send and respond to messages
  • Who talks first, what to do when message comes in and how to handle wacky behavior
  • Open protocols
  • Defined in RFCs
  • Allows for interoperability
  • Everyone knows how server and client should talk – public protocol
  • E.g. HTTP, SMTP
  • Proprietary protocols
  • Don’t want to tell anyone how it works, internal secret protocol used
  • E.g. Skype

What Transport Services Does an App Need?

  • Data integrity
  • Some apps (e.g. file transfer, web transactions) require 100% reliable data transfer
  • Other apps (e.g. audio) can tolerate some loss
  • Reliable data exchange required as client wants exact copy of web page that server has
  • Timing
  • Some apps (e.g. Internet telephony, interactive games) require low delay to be ‘effective’
  • Some applications need fast response, some are elastic (depends on Internet speed)
  • Elastic example: a file
  • Stock exchange need to be updated – hard to do with TCP
  • Throughput
  • Some apps (e.g. multimedia) require minimum amount of throughput to be ‘effective’
  • Other apps (‘elastic apps’) make use of whatever throughput they get
  • How much data does app need to pump
  • Example: Youtube, with video and a certain video rate – needs to be delivered consistently across the network. If network unable to sustain throughput, you might see pauses or glitches
  • Security
  • On network – encrypted form so no one can steal it

Transport Service Requirements: Common Apps

application data loss throughput time sensitive
File transfer no loss elastic no
E-mail no loss elastic no
Web documents no loss elastic no
Real-time audio/video loss-tolerant audio: 5kbps-1Mbps
video:10kbps-5Mbps
yes, 100s msec
Stored audio/video loss-tolerant audio: 5kbps-1Mbps
video:10kbps-5Mbps
yes, few secs
Interactive games loss-tolerant few kbps up yes, 100s msec
Text messaging no loss elastic yes and no
  • File transfer: reliable, want perfect data; delay-tolerant
  • Video: want guaranteed throughput (live video) and low latency hopefully (screen is actually what is happening)
  • Stored video (Youtube): throughput, tolerate more latency – pause, rewind
  • Gaming: low bandwidth, low latency
  • FPS: want shot to hit person, don’t want latency

Internet Transport Protocols Services

  • Layer 4 – what transport layer protocol to invoke?
  • Reliable, TCP vs unreliable, UDP

TCP service:

  • Gets all of your data there eventually (slow)
  • Reliable transport between sending and receiving process
  • Flow control: sender won’t overwhelm receiver
  • Congestion control: throttle sender when network overloaded
  • Does not provide: timing, minimum throughput guarantee, security
  • Connection-oriented: setup required between client and server processes


UDP service:

  • Gets most of your data there quickly (fast)
  • Minimal mechanism, generates data
  • Unreliable data transfer between sending and receiving process
  • Does not provide: reliability, flow control, congestion control, timing, throughput, guarantee, security, error-checking, connection setup
application application layer protocol underlying transport protocol
E-mail SMTP [RFC 2821] TCP
Remote terminal access Telnet [RFC 854] TCP
Web HTTP [RFC 2616] TCP
File transfer FTP [RFC 959] TCP
Streaming multimedia HTTP (e.g. Youtube), RTP [RFC 1889] TCP or UDP
Internet telephony SIP, RTP, proprietary (e.g. Skype) TCP or UDP

Securing TCP

  • TCP & UDP
  • No encryption
  • Cleartext passwds sent into socket traverse Internet in cleartext
  • SSL
  • Provides encrypted TCP connection
  • Data integrity
  • End-point authentication
  • SSL is at app layer
  • Apps use SSL libraries, which ‘talk’ to TCP
  • SSL socket API
  • cleartext passwds sent into socket traverse Internet encrypted
  • Internet protocol stack – no security unless you build it
  • SSL allows encryption near top of protocol stack – API for program to do encryption and have data handled by lower level of stack

Back to Navigation

HTTP over TCP

Diagram: Comparison of Approaches

2CAbRn6.png
Bigger Image

Comparison of Approaches
HTTP/1.0 (Classic) Parallel Persistent HTTP/1.1 (Pipelining)
  • Classic approach: use one HTTP request per TCP connection, serially
  • Three transactions instead of one
  • Vertical dimension – time
  • Round-trip interaction between client and server to retrieve object and close connection; repeated three times
  • Inefficient
  • Improvements: store information server has, do not close connection – send multiple objects on same connection
  • Concurrent TCP connection can be used to make things faster
  • Spawn threads to get different elements
  • Each initiates a TCP connection, doing so concurrently
  • Vertical distance is less than first
  • Supported by most modern browsers (up to 6-8 parallel connections) to retrieve multiple objects concurrently
  • Works regardless of which server those objects are hosted on – several servers when filling content from a web page
  • Reuse the same TCP connection for multiple HTTP transfers, one after another, serially
  • Amortizes TCP overhead, maintains TCP state longer at server
  • Even though server is done, server is going to keep connection alive for a short period of time just in case the other end has something more they want
  • When client stops asking (for GET requests), server closes the connection
  • First box: data of base page written into client’s socket, browser reads out of it and render on screen (processing time) then parses through it and realizes there is an embedded image, so need a GET request
  • Same thing as ‘keep alive’ connection
  • Only works if objects on same server
  • Allows requests to be issued asynchronously on a persistent connection
  • Requests must be processes in proper order. Can do clever packaging
  • Bundle HTTP requests together in a clever way
  • Get base page, and when you’re parsing there are more elements
  • Issue a GET for both elements back-to-back, perhaps in the same TCP data packet

Summary of Web and HTTP

  • The major application on the Internet
  • Majority of traffic is HTTP (or HTTP-related)
  • Client/server model:
  • Clients make requests, servers respond to them
  • Done mostly in ASCII text (helps debugging)
  • Various headers and commands
  • Original version built by physicist had 1.0 paradigm – works but it’s slow and clunky

Back to Navigation

Section 2.2: Web and HTTP

  • Implementation in early 90s, idea about 50 years ago
  • Host stores object, path name contains files
  • Web page consists of objects
  • Object can be HTML file, JPEF image, Java applet, audio file…
  • Web page consists of base HTML-file which includes several referenced objects
  • Each object is addressable by a URL, e.g.
  • [www.someschool.edu]/someDept/pic.gif
  • [host name] path name

HTTP Overview

  • HTTP: hypertext transfer protocol
  • Web’s application layer protocol
  • Client/server model
  • Client: browser that requests, receivers, (using HTTP protocol) and ‘displays’ Web objects
  • Server: Web server sends (using HTTP protocol) objects in response to requests
  • Uses TCP:
  • Client initiated TCP connection (creates socket) to server, port 80
  • Server accepts TCP connection from client
  • HTTP messages (application-layer protocol messages) exchanged between browser (HTTP client) and Web server (HTTP server)
  • TCP connection closed
  • HTTP is ‘stateless’
  • Server maintains no information about past client requests
  • Protocols that maintain ‘state’ are complex
  • Past history (state) must be maintained
  • If server/client crashes, their views of ‘state’ may be inconsistent, must be reconciled
HTTP/1.0 HTTP/1.1
  • Classic version of request-response protocol
  • Interaction of Web server is single request and a single response – more transaction-based interaction
  • ‘Stateless’
  • Client initiates connection to web server using TCP, put a message in data packet wanting a web page, server provides it back and then you’re done
  • Non-persistent
  • Above TCP, verifies web page is there and connection state so reliable data transfer occurs
  • Adds ‘state’
  • Still request-response interaction
  • Persistent connection
  • Avoid TCP connection negotiation and termination
  • One lengthy transaction vs 3 short
  • Pipelining
  • Passwords, caching, cookies…
  • Faster, more efficient, more complicated

HTTP Connections

  • Non-persistent HTTP
  • At most one object sent over TCP connection
  • Connection then closed
  • Downloading multiple objects required multiple connections
  • Persistent HTTP
  • Multiple objects can be sent over single TCP connection between client, server

Non-persistent HTTP

  • Suppose user enters URL: www.someschool.edu/somedepartment/home.index (contains text, references to 10 jpeg images)
1a) HTTP client initiates TCP connection to HTTP server (process) at www.someschool.edu on port 80
1b) HTTP server at host www.someschool.edu waiting for TCP connection at port 80. ‘Accepts’ connection, notifying client
2) HTTP client sends HTTP request message (containing URL) into TCP connection socket. Message indicates that client wants object somedepartment/home.index
3) HTTP server receives request message, forms response message containing requested object, and sends message into its socket
4) HTTP server closes TCP connection
5) HTTP client receives response message containing HTML file, displays HTML. Parsing HTML file, finds 10 referenced JPEG objects
6) Steps 1-5 repeated for each of 10 JPEG objects


  • Response time
  • RTT: time for a small packet to travel from client to server and back
  • HTTP response time:
  • One RTT to initiate TCP connection
  • One RTT for HTTP request and first few bytes of HTTP response to return
  • File transmission time (time from server to send file to client)
  • Non-persistent HTTP response time = 2RTT + file transmission time

Persistent HTTP

  • Non-persistent HTTP issues
  • Requires 2 RTTs per object
  • OS overhead for each TCP connection
  • Browsers often open parallel TCP connections to fetch referenced objects
  • Persistent HTTP
  • Server leaves connection open after sending response
  • Subsequent HTTP messages between same client/server sent over open connection
  • Client sends requests as soon as it encounters a referenced object
  • As little as one RTT for all the referenced objects

HTTP Request Message

  • Two types of HTTP messages: request, response
  • HTTP request message: ASCII (human-readable format)
GET /index.html HTTP/1.1\r\n
Host: www-net.cs.umass.edu\r\n
User-Agent: Firefox/3.6.10\r\n
Accept: text/html,application/xhtml+xml\r\n
Accept-Language: en-us,en;q=0.5\r\n
Accept-Encoding: gzip,deflate\r\n
Accept-Charset: ISO-8859-1,utf-8;q=0.7\r\n
Keep-Alive: 115\r\n
Connection: keep-alive\r\n
\r\n
  • GET: request line
  • \r\n: carriage return character, line-feed character
  • Host…Connection: header lines
  • \r\n + <space>: carriage return, line-feed at start of line indicates end of header lines
  • Blank line after request delineates header and data of subsequent responses

Uploading Form Input

  • POST method
  • Web page often includes form input
  • Input is uploaded to server in entity body
  • URL method
  • Uses GET method (retrieves web pages)
  • Input is uploaded in URL field of request line
  • www.somesite.com/animalsearch?monkeys&banana
Method Types
HTTP/1.0 HTTP/1.1
  • GET, POST
  • HEAD
  • Asks server to leave requests object out of response
  • GET, POST, HEAD
  • PUT
  • Uploads file in entity body to path specified in URL field
  • DELETE
  • Deletes file specified in the URL field

HTTP Response Message

HTTP/1.1 200 OK\r\n
Date: Sun, 26 Sep 2010 20:09:20 GMT\r\n
Server: Apache/2.0.52 (CentOS)\r\n
Last-Modified: Tue, 30 Oct 2007 17:00:02 GMT\r\n
ETag: "17dc6-a5c-bf716880"\r\n
Accept-Ranges: bytes\r\n
Content-Length: 2652\r\n
Keep-Alive: timeout=10, max=100\r\n
Connection: Keep-Alive\r\n
Content-Type: text/html; charset=ISO-8859-1\r\n
\r\n
data data data data data ... 
  • HTTP/1.1 200 OK\r\n: status line (protocol status code, status phrase)
  • Date…\r\n: header lines
  • data data data data data ... : data, e.g. Requested HTML file

HTTP Response Status Codes

  • Status code appears in first line in server-to-client response message
  • Some sample codes:
  • 200 OK
  • Request succeeded, requested object later in this message
  • 301 Moved Permanently
  • Requested object moved, new location specified later in this message (Location:)
  • 400 Bad Request
  • Request message not understood by server
  • 404 Not Found
  • Requested document not found on this server
  • 505 HTTP Version Not Supported

Trying HTTP (Client Side)

(1) Telnet to your favorite Web server:

telnet cis.poly.edu 80
  • Opens TCP connection to port 80
  • (Default HTTP server port) at cis.poly.edu
  • Anything typed in sent to port 80 at cis.poly.edu

(2) Type in a GET HTTP request:

GET /~ross/ HTTP/1.1
Host: cis.poly.edu
  • By typing this in (hit carriage return twice), you send this minimal (but complete) GET request to HTTP server

(3) Look at response message sent by HTTP server

  • When you type up something random, you will get a BAD REQUEST (did not talk HTTP language)
  • GET /~carey/index.htm HTTP/1.0
  • Sends back content
  • HEAD /~carey/index.htm HTTP/1.0
  • Metadata
  • In HTTP/1.1 host header is mandatory
  • /~carey/CPSC441/oddtest1.html HTTP/1.1
Host: asdasda
  • Pauses for 5 seconds because of timeout to retrieve multiple objects on same connection
  • Host:
  • Doesn’t respond because no extra blank line after
  • Five seconds before interaction ends (can do GET request)
  • /~carey/CPSC441/oddtest4.html HTTP/1.0
  • 404 Not Found
  • /~carey/CPSC441/oddtest3.html HTTP/1.0
  • 403 Forbidden: exists, but no access permission
  • Public webserver www.cpsc.ucalgary.ca but redirects to internal server with different name and server actually hosting content
  • GET /~carey/CPSC441/oddtest1.html HTTP/1.0
Host: foople
Range: bytes=250-30
  • Give bytes from location 250 – 300
  • 206 Partial Content: successful, returns something but not entire object, just part of it

User-Server State: Cookies

  • Many Web sites use cookies
  • Four components:
(1) Cookie header line of HTTP response message
(2) Cookie header line in next HTTP request message
(3) Cookie file kept on user’s host, managed by user’s browser
(4) Back-end database at Web site
  • Example:
  • Susan always accesses Internet from PC
  • Visits specific e-commerce site for first time
  • When initial HTTP requests arrives at site, site creates: unique ID and entry in backend database for ID
  • Header is a set-cookie header
  • Amazon, unique identifier
  • Browser sending cookie header – know what you bought, send targeted ads
bzwGF8q.png
  • Messy when companies send cookie database to another organization
  • What cookies can be used for
  • Authorization
  • Shopping carts
  • Recommendations
  • User session state (Web e-mail)
  • How to keep ‘state’
  • Protocol endpoints: maintain state at sender/receiver over multiple transactions
  • Cookies: http messages carry state
  • Cookies and privacy
  • Cookies permit sites to learn a lot about you
  • You may supply name and e-mail to sites

Web Caches (Proxy Server)

  • Goal: satisfy client request without involving origin server
  • User sets browser: Web accesses via cache
  • Browser sends all HTTP requests to cache
  • Object in cache: cache returns object
  • Else cache requests object from origin server, then returns object to client
  • Browser has a cache for images, etc.
  • Important for efficiency of web
  • Cache acts as both client and server
  • Server for original requesting client
  • Client to origin server
  • Typically cache is installed by ISP (university, company, residential ISP)
  • Web caching:
  • Reduces response time for client request
  • Reduces traffic on an institution’s access link
  • Internet dense with caches: enables ‘poor’ content providers to effectively deliver content (so too does P2P file sharing)

Example: Caching

  • Assumptions
  • Average object size: 100K bits
  • Average request rate from browsers to origin servers: 15/sec
  • Average data rate to browsers: 1.50 Mbps
  • RTT from institutional router to any origin server: 2 sec
  • Access link rate: 1.54 Mbps
  • Consequences
  • LAN utilization: 15%
  • Access link utilization = 99% (problem)
  • Total delay = Internet delay + access delay + LAN delay = 2 sec + minutes + usecs
  • Bottleneck link
  • Use a fatter access link
  • Access link rate: 154 Mbps
  • Access link utilization = 0.99%
  • Total delay = Internet delay + access delay + LAN delay = 2 sec + msecs + usecs
  • Cost: increased access link speed (not cheap!)


  • Install local cache
  • Access link utilization = ?
  • Total delay = ?
  • Cost: web cache (cheap!)
  • Calculating access link utilization, delay with cache:
  • Suppose cache hit rate is 0.4
  • 40% requests satisfied at cache, 60% requests satisfied at origin
  • Access link utilization:
  • 60% of requests use access link
  • Data rate to browsers over access link = 0.6*1.50 Mbps = .9 Mbps
  • Utilization = 0.9/1.54 = .58
  • Total delay
  • = 0.6 * (delay from origin servers) + 0.4 * (delay when satisfied at cache)
  • = 0.6 (2.01) + 0.4 (~msecs)
  • = ~ 1.2 secs
  • Less than with 154 Mbps link (and cheaper too!)

Conditional GET

  • Goal: don’t send object if cache has up-to-date cached version
  • No object transmission delay
  • Lower link utilization
  • Cache: specify date of cached copy in HTTP request
  • If-modified-since: <date>
  • Server: response contains no object if cached copy is up-to-date
  • HTTP/1.0 304 Not Modified
  • HTTP/1.0 200 OK <date> if cached copy has been modified after <date>

Back to Navigation

Section 2.3: File Transfer Protocol (FTP)

  • Transfer file to/from remote host
  • Client/server model
  • Client: side that initiates transfer (either to/from remote)
  • Server: remote host
  • Text-based protocol
  • User interface session part: log in, navigate around directories and issue requests
  • Data transfer part: copy file from one machine to another
  • ftp: RFC 959
  • ftp server: port 21

FTP: Separate Control, Data Connections

  • FTP client contacts FTP server at port 21, using TCP
  • Client authorized over control connection
  • Client browses remote directory, sends commands over control connection
  • When server receives file transfer command, server opens 2nd TCP data connection (for file) to client
  • After transferring one file, server closes data connection
  • Server opens another TCP data connection to transfer another file
  • Control connection: ‘out of band’
  • FTP server maintains ‘state’: current directory, earlier authentication
  • FTP control and data part separately done


FTP
Control part Data part
  • Single persistent TCP connection
  • Initiated by client
  • Port 21
  • “Session” state
  • User ID and credentials
  • Permissions for different groups
  • Working directory
  • 0 or more non-persistent TCP connections
  • Initiated by server
  • Port 20
  • One connection per file transfer

FTP Commands, Responses

  • Sample commands
  • Sent as ASCII text over control channel
  • USER <username>
  • PASS <password>
  • LIST returns list of file in current directory
  • RETR filename retrieves (gets) file
  • STOR filename stores (puts) file onto remote host
  • Sample return codes
  • Status code and phrase (as in HTTP)
  • 331 Username OK, password required
  • 125 data connection already open; transfer starting
  • 425 Can’t open data connection
  • 452 Error writing file


  • ftp ftp.cpsc.ucalgary.ca
  • Login:
  • (1) username: anonymous; password: <e-mail address>
  • Can copy files to local directory
  • (2) username: <name>; password: <password>
  • Displays actual directory
  • Forces browser to go from http to ftp
  • Also: ftp://<name>.ftp.cpsc.ucalgary.ca

Back to Navigation

Section 2.4: Electronic Mail

Electronic Mail
Good Old Days Today
  • 80s
  • Mainframes
  • Few of them
  • On 24/7
  • Stationary
  • UNIX
  • Trusted
  • ASCII
  • mail (single command)
  • SMTP (Simple Mail Transfer Protocol)
  • Nightly transfer
  • PCs, tablets, smartphones, laptops…
  • Lots of them
  • Transient – come and go
  • Mobile
  • Window and others
  • Untrusted: spammers, hackers, etc.
  • Attachments
  • Outlook, Thunderbird…
  • POP, IMAP, IMAPS, HTTP
  • Instant transfer
  • Three major components:
  • User agents
  • Mail servers
  • Simple mail transfer protocol (SMTP)
  • User agent
  • Aka ‘mail reader’
  • Composing, editing, reading mail messages
  • Outgoing, incoming messages stored on server
  • E.g. Outlook, Thunderbird, iPhone mail client
  • Mail servers
  • Mailbox contains incoming messages for user
  • Message queue of outgoing (to be sent) mail messages
  • SMTP protocol between mail servers to send e-mail messages
  • Client: sending mail server
  • ‘Server’: receiving mail server

SMTP [RFC 2821]

  • Uses TCP to reliably transfer email message from client to server, port 25
  • Direct transfer: sending server to receiving server
  • Three phases of transfer
  • Handshaking (greeting)
  • Transfer of messages
  • Closure
  • Command/response interaction (like HTTP, FTP)
  • Commands: ASCII text
  • Response: status code and phrase
  • Messages must be in 7-bit ASCII

Example: Alice Sends Message to Bob

(1) Alice uses UA to compose message ‘to’ bob@someschool.edu
(2) Alice uploads to SMTP server; her UA sends message to her mail server, and message placed in message queue
(3) Client side of SMTP opens TCP connection with Bob’s mail server
  • SMTP has outbound message in message queue, try to find SMTP server (Bob’s)
(4) SMTP client sends Alice’s message over the TCP connection
(5) Bob’s mail server places the message in Bob’s mailbox
(6) Bob invokes his user agent to read message
  • User agent -> Alice’s mail server -> Bob’s mail server -> user agent

Example: 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 
C: QUIT 
S: 221 hamburger.edu closing connection
  • cs.umass.edu bulletproof’d their SMTP; must use proper mail exchange
  • Naive vulnerable protocol; spammers exploited vulnerabilities, driving e-mail from any place

SMTP

  • Can send e-mail without using e-mail client (reader)
  • telnet servername 25
  • See 220 reply from server
  • Enter HELO, MAIL FROM, RCPT TO, DATA, QUIT commands


  • SMTP uses persistent connections
  • SMTP requires message (header & body) to be in 7-bit ASCII
  • SMTP server uses CRLF.CRLF to determine end of message
  • Comparison with HTTP:
  • HTTP: pull
  • SMTP: push
  • Both have ASCII command/response interaction, status codes
  • HTTP: each object encapsulated in its own response message
  • SMTP: multiple objects sent in multi-part message

Mail Message Format

  • SMTP: protocol for exchanging email messages
  • RFC 822: standard for text message format:
  • Header lines, such as:
  • To:
  • From:
  • Subject:
  • Different from SMTP MAIL FROM, RCPT TO: commands!
  • Blank line
  • Body: the “message”
  • ASCII characters only

Mail Access Protocols

  • User agent ---SMTP---> Sender’s mail server ---SMTP---> Receiver’s mail server ---Mail access protocol---> User agent
  • SMTP: delivery/storage to receiver’s server
  • Mail access protocol: retrieval from server
  • POP: Post Office Protocol [RFC 1939]
  • Authorization, download
  • Mail arrived at SMTP server
  • Using device, when you retrieve messages, the message is now on the device used to retrieve; message is no longer at the server
  • IMAP: Internet Mail Access Protocol [RFC 1730]
  • More features, including manipulation of stored messages on server
  • Remote manipulation of content; stays on server but remotely access and read from anywhere
  • HTTP: HyperText Transfer Protocol
  • Gmail, Hotmail, Yahoo! Mail, etc.

POP3 Protocol

S: +OK POP3 server ready 
C: user bob 
S: +OK 
C: pass hungry 
S: +OK user successfully logged on
  • Authorization phase
  • Client commands:
  • user: declare username
  • pass: password
  • Server responses
  • +OK
  • -ERR
C: list 
S: 1 498 
S: 2 912 
S: . 
C: retr 1 
S: <message 1 contents>
S: . 
C: dele 1 
C: retr 2 
S: <message 1 contents>
S: . 
C: dele 2 
C: quit 
S: +OK POP3 server signing off
  • Transaction phase, client
  • list: list message numbers
  • retr: retrieve message by number
  • dele: delete
  • quit

POP3 and IMAP

  • More about POP3
  • Previous example uses POP3 'download and delete' mode
  • Bob cannot re-read e-mail if he changes client
  • POP3 'download-and-keep': copies of messages on different clients
  • POP3 is stateless across sessions
  • IMAP
  • Keeps all messages in one place: at server
  • Allows user to organize messages in folders
  • Keeps user state across sessions:
  • Names of folders and mappings between message IDs and folder name

Back to Navigation

Section 2.5: DNS

Domain Name System/Service (DNS)

  • Mapping from human readable text name (www….) to an actual IP address, so your computer knows where the website is on the Internet and can get there
  • For Internet hosts and routers, IP address (32 bit) used fo addressing datagrams, ‘name’ (e.g. www.yahoo.com) is used by humans
  • Human readable name (high level) => mapping => unique IP address (low level identity)
  • Client goes to DNS first before setting up a socket and GET from the Internet to retrieve data from Web server and get sent back
  • Tool for doing this mapping, from human name spaces into IP name spaces
  • Domain Name System:
  • Distributed database implemented in hierarchy of many name servers
  • Application-layer protocol: hosts, name servers communicate to resolve names (address/name translation)
  • Note: core Internet function implemented as application-layer protocol
  • Complexity at network’s edge
  • Transaction-oriented application-layer protocol
  • UDP-based (usually) because want low latency
  • Runs on Port 53

Services, Structures

  • DNS services
  • Hostname to IP address translation
  • Host aliasing: canonical, alias names
  • Mail server aliasing
  • Load distribution
  • Replicated Web servers: many IP addresses correspond to one name
  • Why not centralize DNS and make it a huge distributed database?
  • Issue of scale
  • Single point of failure
  • Traffic volume
  • Distant centralized database
  • Maintenance
  • If you centralize, massive amount of load by everyday people will be sent; single point of failure if someone were to attack DNS – doesn’t scale

A Distributed, Hierarchical Database

  • Root DNS Servers
-> com DNS servers
-> yahoo.com DNS servers
-> amazon.com DNS servers
-> org DNS servers
-> pbs.org DNS servers
-> edu DNS servers
-> poly.edu DNS servers
-> umass.edu DNS servers
  • Client wants IP for www.amazon.com, first approximation:
  • Client queries root server to find com DNS server
  • Client queries .com DNS server to get amazon.com DNS server
  • Client queries amazon.com DNS server to get IP address for www.amazon.com

Root Name Servers

  • Contacted by local name server that cannot resolve name
  • Root name server:
  • Contacts authoritative name server if name mapping not known
  • Gets mapping
  • Returns mapping to local name server


  • Replicated by number of sites

[www].cpsc.ucalgary.(ca)

  • [most specific] to (least specific, top level of where it is)
  • Resolve from root level (right) and working the way down to get exact details


  • 13 root name ‘servers’ worldwide
(a) Verisign, Los Angeles, CA (5 other sites)
(b) USC=ISI Marina del Rey, CA
(c) Cogent, Herndon, VA (5 other sites)
(d) U Maryland College Park, MD
(e) NASA Mt. View, CA
(f) Internet Software C. Palo Alto, CA (and 48 other sites)
(g) US DoD Columbus, OH (5 other sites)
(h) ARL Aberdeen, MD
(i) Netnod, Stockholm (37 other sites)
(j) Verisign, Dulles VA (69 other sites)
(k) RIPE London (17 other sites)
(l) ICANN Los Angeles, CA (41 other sites)
(m) WIDE Tokyo (5 other sites)

TLD, Authoritative Servers

  • Generic top-level domain (TLD) servers
  • Generic categories for businesses/advertising
  • Responsible for com, org, net, edu, aero, jobs, museums, and all top-level country domains (e.g. uk, fr, ca, jp)
  • Network Solutions maintains servers for .com TLD
  • Educause for .edu TLD
  • Allow you to have .insurance, .xxx, etc.
  • Authoritative DNS servers
  • Local DNS server, that has real answers of ‘which computer and office does it reside in?’
  • Name of every computer, IP address, who owns that computer (map to location/person)
  • Organization’s own DNS server(s), providing authoritative hostname to IP mappings for organization’s named hosts
  • Can be maintained by organization or service provider
  • Non-authoritative server: anything that comes out of a cache

Local DNS Name Server

  • Does not strictly belong to hierarchy
  • Each ISP (residential ISP, company, university) has one
  • Also called “default name server”
  • When host makes DNS query, query is sent to its local DNS server
  • Has local cache of recent name-to-address translation pairs (but may be out of date!)
  • Acts as proxy, forwards query into hierarchy

DNS Name Resolution Example

  • Host at cis.poly.edu wants IP address for gaia.cs.umass.edu
  • nslookup gaia.cs.umass.edu
  • IP address: 128.119.245.12 (can initiate TCP connection)
  • Answered by local DNS server (that already knew the answer; cached)
  • Non-authoritative answer because it came out of local cache rather than getting definitive answer from umass server


  • Iterated query
  • Each step, different servers consulted – “I don’t have the answer, but I know where you should look”
  • Originating DNS server does all heavy lifting
  • Most commonly used
  • Answer only ends up at local DNS server (because of space, query volume)


(1) Requesting host (cis.poly.edu) -> local DNS server (dns.poly.edu): “I don’t know, I will find it for you”
(2) Local DNS server -> root DNS server: “you need to go over to .edu”
(3) Root DNS server -> local DNS server
(4) Local DNS server -> TLD DNA server: tells where .umass is
(5) TLD DNS server -> local DNS server
(6) Local DNS server -> authoritative DNS server (dns.cs.umass.edu -> gaia.cs.umass.edu): talks to .umass and returns IP address
(7) Authoritative DNS server-> local DNS server


  • Recursive query
  • Puts burden of name resolution on contacted name server
  • Originating computer asks local DNS server, and it will find it for you – passes down to .umass
  • Make each server along the chain do lots of work for you
  • Answer generated at end, propagated through chain


(1) Requesting host (cis.poly.edu) -> local DNS server (dns.poly.edu)
(2) Local DNS server -> root DNS server
(3) Root DNS server -> TLD DNS server
(4) TLD DNS server -> authoritative DNS server (dns.cs.umass.edu -> gaia.cs.umass.edu)
(5) Authoritative DNS server -> TLD DNS server
(6) TLD DNS server -> root DNS server
(7) Root DNS server -> local DNS server
(8) Local DNS server -> requesting host

Caching, Updating Records

  • Once (any) name server leans mapping, it caches mapping – lots of caching
  • Cache entries timeout (disappear) after some time (TTL)
  • Anytime you get an answer, it will be remembered (for a certain amount of time)
  • TLD servers typically cached in local name servers
  • Thus root name servers not often visited
  • Cached entries may be out of date, but cached to avoid the trouble of getting the answer (best effort name-to-address translation)
  • Mostly accurate, avoids unnecessary lookup
  • If name host changes IP address, may not be know Internet-wide until all TTLs expire
  • Fill DNS cache locally with good information, avoid necessary lookups if possible
  • Update/notify mechanisms proposed IETF standard (RFC 2136)

DNS Records

  • DNS: distributed db storing resource records (RR)
  • RR format: (name, value, type, ttl)
type=A type=NS type=CNAME type=MX
  • name is hostname
  • value is IP address
  • Authoritative – this hostname has this IP address (definitive)
  • Tells you mapping of given hostname to IP
  • name is domain (e.g. foo.com)
  • value is hostname of authoritative name server for this domain
  • This domain is managed by this name server
  • Parse domain, consult someone – that entry tells you who the name server is for that domain (find umass domain server if ask about it)
  • name is alias name for some ‘canonical’ (the real) name
  • www.ibm.com is actually servereast.backup1.ibm.com
  • value is canonical name
  • Alias magic that allows you to change internal name without changing external
  • Called www but inside organization may be calleddbtemp1, and cname hides that
  • Public interface name, inside can be computerdb1, and cname allows you to keep track of all different names and how to get to the correct address
  • value is name of mailserver associated with name
  • Mail exchange – DNS entry where the mail server is this machine – tells SMTP to contact to transfer in/out domain

DNS Protocol, Messages

  • Query and reply messages, both with same message format
  • Message header:
  • Identification
  • 2 bytes in size
  • 16 bit number for query, reply to query uses same number
  • Flags
  • 2 bytes in size
  • Query or reply
  • Recursion available and desired
  • Reply is authoritative
  • Number of questions (2 bytes), number of answer resource records (RRs) (2 bytes)
  • Number of authority RRs (2 bytes), number of additional RRs (2 bytes)
  • Questions
  • 4 bytes in size
  • Variable number of questions
  • Name, type fields for a query
  • Answers
  • 4 bytes in size
  • Variable number of RRs
  • RRs in response to query
  • Authority
  • 4 bytes in size
  • Variable number of RRs
  • Records for authoritative servers
  • Additional Information
  • 4 bytes in size
  • Variable number of RRs
  • Additional “helpful” info that may be used
  • Sequence numbers
  • Outbound query – sequence number incremented each time DNS query happens; match response with originating query and corresponds to the name
  • Typical response: A few 100 bytes
  • List cname, mx, etc. and info of who responded and which DNS server; if it was authoritative or non-authoritative

Example: nslookup

  • nslookup
www.cpsc.ucalgary.ca
  • First looks at root level, then ends up at highest level
  • Information from a cache
  • Actual machine name is web1.cpsc.ucalgary.ca
  • www.google.com</cde>
  • Query <code>google.com, receive many answers
  • Load balancing – uses multiple servers
  • Numbers keep changing
  • Ordering changed, for load balancing (round robin)

Example: dig

  • Domain Information Groper
  • Prints out resource records
  • dig gaia.cs.umass.edu
  • qr – query response, rd – recursion denied
  • dig @cis.poly.edu gaia.cs.umass.edu
  • Records kept for a few days at root level

Linuxconfig files

/etc/resolv.conf
/etc/hosts
/etc/protocols
/etc/services
  • Files used to resolve names

Inserting Records into DNS

  • Example: new startup “Network Utopia”
  • Register name networkutopia.com at DNS registrar (e.g. NetworkSolutions)
  • Provide names, IP addresses of authoritative name server (primary and secondary)
  • Registrar inserts two RRs into the .com TLD server:
  • (networkutopia.com, dns1.networkutopia.com, NS)
(dns1.networkutopia.com, 212.212.212.1, A)
  • Create authoritative server type A record for www.networkutopia.com; type MX record for networkutopia.com

Attacking DNS

  • Distributed Denial-of-Service (DDoS) attacks
  • Bombard root servers with traffic
  • Not successful to date
  • Traffic filtering
  • Local DNS servers cache IPs of TLD servers, allowing root server bypass
  • There is so much caching, it’s hard to get a query to the root
  • Bombard TLD servers
  • Potentially more dangerous
  • Redirect attacks
  • Man-in-middle
  • Intercept queries
  • DNS poisoning
  • Send bogus replies to DNS server, which caches
  • Trick people into going to your DNS site
  • Software might put in DNS cache; name mapped to bogus IP
  • Exploit DNS for DDoS
  • Send queries with spoofed source address:target IP
  • Requires amplification
  • DNS sec is secure
  • DNS can be fragile

Back to Navigation

Section 2.6.1: P2P Architecture

Pure P2P Architecture

  • No always-on server
  • Arbitrary end systems directly communicate
  • Peers are intermittently connected and change IP addresses
  • Instead of special server machines, we have ordinary peer machine
  • Any peer can be consumer, producer, provider, etc. and can talk to other peers
  • Arbitrary end hosts choosing to directly communicate with each other; may be transient, Wi-Fi, etc.
  • Examples:
  • File distribution (BitTorrent)
  • File sharing
  • Streaming (KanKan)
  • VoIP (Skype)

Peer-to-Peer Design

Real world Internet
  • Postal system
  • Write letter, send to anyone if you know the address
  • Telephone
  • If you know someone’s phone number, can call anyone
  • Routing protocols (RIP)
  • Routing Information Protocol – every router is a peer, with all other routers on the network; routers figure out who they connect to, operate as peers
  • SMTP (parts of it)
  • Servers talking to other servers in different places – conversation where they are providers/consumers of content
  • AODV (ad hoc on-demand distance vector wireless networks)
  • Computer is a router, no actual router; all devices communicate wirelessly and will forward packets accordingly
  • Skype
  • SETI – extra-terrestrial intelligence
  • NW Apps
  • Client-server
  • HTTP, DNS
  • P2P
  • File Sharing
  • Get illegal copyrighted content from other people on the network
  • Hybrid
  • Need server-hardware stuff, but need lots of bandwidth from peers

P2P File Sharing Applications

  • Early ones: central design (Napster)
  • Central server keeps track of who had what content willing to share, and gave IP address to that person so you could get that content yourself
  • Catalogue, dictionary, a list of the content and who has it
  • Distributed is sending of file
  • Later ones: distributed design (eDonkey, KaZaa, Gnutella…)
  • Structured style (CAN, Chord)
  • Explicit location for every piece of content registered
  • CAN: content addressable network
  • Tells what file/movie you’re looking for based on that name of the object, they do hash of name and gives you unique identifier and tells you where exactly the content is stored in the P2P model
  • Unstructured style
  • Content can be anywhere and you have to search for it
  • Anybody can host any file anywhere in the system, must do explicit flood-based search to find out who has what you need
  • Sends out query of all participating nodes, find whoever has it, pursue content
“Early” “Modern”
  • Static well-known port
  • If you connect on that port, talking to peer connected to that
  • TCP for data transfer since large content needs to be exactly replicated (need reliability)
  • UDP for search (flood-based; similar to DNS but it’s looking for data content)
  • Single TCP connection for data transfer (file-based)
  • Single file with a size, set up a single TCP connection to single destination and copy that size across it
  • Plain text
  • Look at HTTP headers, figure out what file they’re looking for, how big it was, etc.
  • Dynamic (random) ephemeral ports
  • Keep changing, whenever you run it, the ports change
  • TCP for data transfer
  • Multiple parallel TCP transfers (piece-based)
  • Hide, do small transfers from many different places
  • Encrypted
  • Proprietary – unsure how protocol works, run application

In Class Example

  • Actual DVD copy of Lord of the Rings with a size of 430 mb
  • Puts up on server at home (upload speed 2 mb/s), anyone can download for free
  • Person 1: access speed 3 mb/s
  • ~30 minutes – only person who wants it, gets full speed on Internet link
  • Person 2, 3, 4 now wants it
  • Server has to split the time up somehow – 2 hours
  • 50 hours to download the movie if running client-server (Slow)
  • Split into 100 pieces, 100 mb each
  • Each person has a choice of 8 pieces
  • Person 1-4 gets 1/8 of the movie (4 minutes)
  • Person 3 picks a piece Person 4 has – piece 7
  • When they want a portion a peer has, they don’t involve the server – they do peer-to-peer transfer
  • When all pieces are sent out to peers, server can be shut down and the rest can happen
  • When someone finishes all the pieces, they can shut off their services or remain in the system to serve capacity
  • How much time to distribute file (size F) from one server to N peers?
  • Peer upload/download capacity is limited resource
  • us: server upload capacity
  • dj: peer i download capacity
  • ui: peer i upload capacity
File Distribution Time
Client-Server P2P
  • Server transmission
  • Must sequentially send (upload) N file copies
  • Time to send one copy: F/us
  • Time to send N copies: NF/us
  • Client
  • Each client must download file copy
  • dmin = minimum client download rate
  • Minimum client download time: F/dmin
  • Time to distribute F to N clients using client-server approach
  • Dc-s ≥ max{NF/us, F/dmin}
  • NF increases linearly in N
  • Server transmission
  • Must upload at least one copy
  • Time to send one copy: F/us
  • Client
  • Each client must download file copy
  • Minimum client download time: F/dmin
  • Clients
  • As aggregate must download NF bits
  • Max upload rate (limiting max download rate): us + Σui
  • Time to distribute F to N clients using P2P approach
  • DP2P ≥ max{NF/us, F/dmin, NF/(us + Σui}
  • NF increases linearly in N
  • Σui also increases linearly in N, as each peer brings service capacity


  • Must provide at least a part of the copy into the system to stimulate it – if server disappears before content is out there, nobody would be able to finish their download
  • Critical piece: right-most
  • Compound every piece, download will depend on willing peers, reciprocal relationship and Internet speed
  • Ui internet access speed that wasn’t there before – BitTorrent harnesses resources (bandwidth) in the system, that server is unable to provide themselves
  • Client upload rate = u, F/u = 1 hour, us = 10u, dmin ≥ us
  • Client-server takes longer (linearly)
  • P2P asymptotically lower bound (logarithmic)

P2P File Distribution: BitTorrent

  • File divided into 256 kb chunks, peers in torrent send/receive file chunks
  • Example: Alice arrives…obtains list of peers from tracker…and begins exchanging file chunks with peers in torrent
  • Tracker: tracks peers participating in torrent
  • Keeps track of name and IP address
  • Torrent: group of peers exchanging chunks of a file
  • Peer joining torrent
  • Has no chunks, but will accumulate them over time from other peers
  • Registrars with tracker to get list of peers, connects to subset of peers (‘neighbors’)
  • While downloading, peer uploads chunks to other peers
  • Peer may change peers with whom it exchanges chunks
  • Churn: peers may come and go
  • Once a peer has entire file, it may (selfishly) leave or (altruistically) remain in torrent

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 every 10 seconds
  • Every 30 seconds: randomly selects another peer, starts sending chunks
  • ‘Optimistically unchoke’ this peer
  • Newly chosen peer may join top 4
  • Server is a seed which has every piece
  • Dynamic, unpredictable of what peer will provide
  • No security or protection on corrupted or malicious files
  • Tracker hosted on a site

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
  • Tit for tat deals: mutual incentive for an exchange (I have something you want, you want something I have)
  • Pieces: Who has the piece you need; if you find someone that also needs your pieces - reciprocate and mutual incentive
  • Service (throughput): if someone gives you good/lousy service, you return the same
  • First Piece Problem
  • When Alice joins, she has no pieces; how to get started?
  • In BitTorrent, there is something called choking and unchoking
  • Tracker provided list of 20-30 peers for Alice, she will have an active exchange with about 5
  • 25 of them are choked; 5 are unchoked
  • Do dynamically over time (every so minutes); you will allow random trades with someone
  • Will see what pieces they have and what service they have; if the new person is better than the previous, they will shut the worse service and go to the better, new one
  • Random choking allows new people to participate in the system
  • Rarest First Piece Selection
  • Identify which piece is least prevalent (i.e. fewest copies) and try to make another copy
  • Find the piece that is least popular, and make another copy of it, in case someone leaves with the only piece
  • Tracker would notice this; whenever you download it, you report to the tracker (up-to-date view of who has what) and it calculates how many copies there are
  • Alice gets optimistically unchoked, now has copy of the least prevalent piece in system. Soon, everyone will want Alice’s piece
  • Bootstrapping: everyone will contact the new one because of the rare piece they have


  • Dynamic, adaptive protocol
  • Dynamic Bandwidth Probing
  • Bandwidth Throttling
  • Last Piece Problem
  • Start to lose parallelism because only one or two pieces needed; now down to 1-2 peers
  • Find someone who has the piece you need, who has optimistically unchoked you
  • “Harnesses bandwidth”


  • BitTorrent
  • If you have to get it sequentially then must wait for piece 1
  • Might get the next piece in time while you’re watching
  • Solution: prioritize the first bits so you can watch the beginning of it, ensure you get the next ones coming up
  • Small numbers -> large numbers
  • Example: Many people start to watch the movie (good for buffer latency)
  • Person 2 wants Person 1’s piece, Person 1 no incentive for reciprocation
  • Add some randomization so people can reciprocate
  • Also people altruistically give pieces (daisy chain of performance)
  • Stratification Approach: someone watches the movie first, and can give the extra pieces to another person and so forth

Media Streaming Apps

  • Chapter 7
  • Continuous media objects
  • Audio: small, low bit rate
  • 100 kb/s or less
  • Video: large, high bit rate
  • Mb/s or more
  • Live or stored
  • Live: real-time viewing of an event (sports, etc.)
  • Stored: old content pre-recorded and pre-formatted, watching it on an on-demand basis (Youtube)
  • Needs to be viewed sequentially to make sense
  • Semantic meaning to them – watched in linear order in sequential fashion that makes sense for viewers
  • Strict timing and synchronization requirements
  • Video has a certain frame rate at which videos displayed (30 fps)
  • Creates illusion of continuous movement; if less, than you get more stop-motion
  • Synchronization of video and audio
to another person and so forth – Stratisfication Approach

Application Layer Protocols in Retrospect

  • Architecture: Client-Server (hybrid) P2P
  • What paradigm, architecture is it using? Is it server or P2P oriented?
  • Duration
  • Short (transaction-oriented) vs long (session-oriented)
  • Short
  • Web (retrieve web)
  • DNS (host name, tell me what IP is)
  • Long
  • Streaming (Youtube)
  • FTP (connect to server, session in which you exchange control information and commands
  • Reliability
  • Perfect data vs unreliable data
  • TCP-based (web, e-mail)
  • UDP-based (streaming)
  • Bandwidth needs
  • Low vs high
  • Low: e-mail (send a few kb of stuff)
  • High: HD streaming
  • Data volume
  • Low vs high
  • Low: web page
  • High: streaming
  • Statefulness
  • Connection-less vs connection-oriented
  • Connection-less
  • No setup or teardown; just do it
  • Need IP address, done in short duration
  • HTTP/1.0 (simple, get web page)
  • Connection-oriented
  • Explicit setup, transfer, teardown
  • Overhead of TCP setup
  • HTTP/1.1 (might remember it’s you, keep cookies, open the connection)
  • Directionality
  • One-way vs two-way
  • One-way: Youtube
  • Two-way: Skype
  • Style
  • Pull vs push
  • Pull: file on web server pulled from server
  • Push: file on computer, pushed onto SMTP server
  • FTP has both two-way and pull, push
  • Both deal with one way or two way exchange of data; and which direction the data is moving
  • Number of participants
  • One-to-one vs one-to-many
  • Who’s involved in the conversation/application
  • Many are one-to-one
  • Can be multi-party conversation (cideo conferencing, broadcast, multi-layer gaming apps)
  • Security
  • Yes vs no
  • Most don’t have it as everyone assumed they were a good citizen but now they are building SSL into protocol

Back to Navigation