Version 17/02/16

Computer Networks I

application

transport

network Application Layer

link

physical

Francisco.Moya@uclm.es
Most of this presentation was based on the official slides of the Kurose&Ross textbook
Presentation based on slides by

Kurose and Ross, Computer Networking: A Top-Down Approach

available at Pearson:

http://www.pearsonhighered.com/educator/product/Computer-Networking-A-TopDown-Approach/
 Contents

● Application layer paradigms

● Web / HTTP
● POP3, IMAP (eMail)
● DNS
● P2P

3
 Logical connection

● The Application
Layer provides
services to the user
● Logical connection
between app layers
on both sides
● But physically,
connection takes
place through the
physical layer
 App-layer protocol defines

● Types of messages Public-domain protocols:

exchanged, ● defined in RFCs
● e.g., request, response ● allows for interoperability
● Message syntax: ● e.g., HTTP, SMTP, IMAP
● what fields in messages & how
fields are delineated
● Message semantics Proprietary protocols:
● meaning of information in fields
● e.g., WhatsApp, Skype
● Rules for when and how
processes send & respond to
messages

5
 Client-server paradigm

clients: server:
● communicate with server ● always-on host
● may be intermittently connected ● permanent IP address,
port listening
● may have dynamic IP addresses
● difficult to scale
● do not communicate directly with each other
– Server farms

6
 Peer-to-peer paradigm

● no always-on server
● arbitrary end systems directly communicate
● peers are intermittently connected and change IP addresses
● Highly scalable but difficult to manage

7
 Hybrid of client-server and P2P

Skype
● Internet telephony app
● Finding address of remote party: centralized server(s)
● Client-client connection is direct (not through server)

Instant messaging
● Chatting between two users can be P2P
● Presence detection/location centralized:
– User registers its IP address with central server when it comes online
– User contacts central server to find IP addresses of buddies

8
 What transport service does an app
need?

Data loss Bandwidth

● some apps (e.g., audio) can ● some apps (e.g., multimedia)
tolerate some loss
require minimum amount of
● other apps (e.g., file transfer, bandwidth to be “effective”
telnet) require 100% reliable
data transfer ● other apps (“elastic apps”)
make use of whatever
bandwidth they get
Timing
● some apps (e.g., Internet
telephony, interactive games)
require low delay to be
“effective”

9
 Transport service requirements of common
apps

Application Data loss Bandwidth 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 yes, 100’s msec
video:10kbps-5Mbps
stored audio/video loss-tolerant same as above yes, few secs
interactive games loss-tolerant few kbps up yes, 100’s msec
instant messaging no loss elastic yes and no

10
 Internet transport protocols services
TCP service:
● connection-oriented: setup required
between client and server processes
● 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
bandwidth guarantees
UDP service:
● unreliable data transfer between
sending and receiving process
● does not provide: connection setup,
reliability, flow control, congestion
control, timing, or bandwidth
guarantee
Q: why bother? Why is there a UDP?
11
 Internet apps: application, transport protocols

Application Underlying
Application layer protocol 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 proprietary TCP or UDP
(e.g. RealNetworks)
Internet telephony proprietary
(e.g., Vonage,Dialpad) typically UDP

12
Web and HTTP
RFC1945 (HTTP/1.0)
RFC2616 (HTTP/1.1)

13
 World Wide Web

● Developed in the CERN by Tim Berners-Lee in 1989

● The WWW is a huge client-server distributed service
● Definititions:
● Web pages: documents distributed all over the Internet
● Site: location providing web pages
● Hypermedia: linked objects inside web pages (text,
audio, video, ..)
● Browser: client tool to display web pages

14
 Web browser

● Displays web pages (web client)

● Three components
● Controller
● Client protocols
● Interpreters

15
 Uniform Resource Locator (URL)

● Each object in the network is uniquely identified by

an URL
● Method: client protocol used
● Host: IP or host name
● Port: of the web service in the server (80 by default)
● Path: to the object inside the web server

http://www.someschool.edu/someDept/pic.gif

host name path name

16
 Web documents

● Grouped into 3 categories

● Static
– Documents stored in the server
Static web page request
– Client gets a copy
– Languages used:
● HTML, XML, XSL, XHTML
● Dynamic
● Active

17
 Web documents

● Dynamic document
● Created by the server
upon request
● May vary from request to
request
● Programs used:
– Common Gateway
Interface - CGI (obsolete)
– Java Server Pages (JSP)
– Active Server Pages (ASP)

Dynamic web page request

18
 Web documents

● Active web page

● Program runs in the
client
● Client programs
– Java applets
– JavaScripts

Active web page request

19
 HTTP overview

● Uses TCP as transport protocol:

● client initiates TCP connection to server, port 80
● server accepts TCP connection from client
● HTTP messages exchanged between browser and
Web server
● TCP connection closed
● HTTP is stateless
● server maintains no information about past client
requests

20
 HTTP connections

● Nonpersistent HTTP ● Persistent HTTP

● At most one object is ● Multiple objects can be
sent over a TCP sent over single TCP
connection connection between
● A new connection per client and server.
each object in the web ● HTTP/1.1 uses
page persistent connections in
● HTTP/1.0 uses default mode
nonpersistent HTTP

21
 Nonpersistent HTTP connection

● Example: text file with a

link to an image
● Each connection
implies 3 TCP msgs.
● Request sent in the 3rd
one
● New connection for
every object
– 1 for the file
– 1 for the image

22
 Persistent HTTP connection

● Same example:
● Only one connection
● Image request sent separately

23
 HTTP message format

●
Two types of HTTP messages: request, response
●
HTTP request message: 4 sections
●
ASCII (human-readable format)

24
 HTTP request message

Method : (GET, POST, HEAD commands)

GET /somedir/page.html HTTP/1.1

Host: www.someschool.edu
User-agent: Mozilla/4.0
Connection: close
Accept-language:fr

(extra carriage return, line feed)

Carriage return, line feed

indicates end of message

25
 HTTP request message

●
Some of the method types (not a complete list):
●
GET: request a message
– Most used. Empty body
– May upload information using the URL field of the request line
●
http://www.somesite.com/animalsearch?monkeys&banana
● HEAD: request only info about the document
– Ex: last modification time
– Empty body in the response
●
PUT: sends a document to the server (only HTTP 1.1)
– Inverse of the GET
●
POST: sends information to the server
– Sends information to be added to the web page, or to modify it
●
Ex.: web page with an input form
●
Input is uploaded in the body, not as part of the URL

26
 HTTP request message

● Request header:
● Optional, from 0 to several lines
● Additional information sent to the server
Header Description
User-agent Identifies the client program
Accept Shows the media format the client can accept
Accept-charset Shows the character set the client can handle
Accept-encoding Shows the encoding scheme the client cant handle
Accept-language Shows the language the client can accept
Authorization Shows what permissions the client has
Host Shows the host and port number of the client
Date Shows the current date
Upgrade Speifies the preferred communication protocol
Cookie Returns the cookie to the server
If-Modified-Since If the file is modificed since a specific date

27
 HTTP response message

HTTP/1.1 200 OK
Connection: close
Date: Thu, 06 Aug 1998 12:00:15 GMT
Server: Apache/1.3.0 (Unix)
Last-Modified: Mon, 22 Jun 1998 …...
Content-Length: 6821
Content-Type: text/html

data data data data data ...

data,
e.g., requested HTML file

28
 HTTP response status codes

● A few 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

29
 HTTP request message

● Response header:
● Optional, from 0 to several lines
● Additional information sent from the server
Header Description
Date Shows the current date
Upgrade Specifies the preferred communication protocol
Server Gives information about the server
Set-Cookie The server asks the client to save a cookie
Content-Encoding Specifies the encoding scheme
Content-Language Specifies the language
Content-Length Shows the length of the document
Content-Type Specifies the media type
Location To ask the client to send the request to another site
Accept-Ranges The server will accept the requested byte-ranges
Last-modified Gives the date and time of the last change
30
 HTTP GET request example

● The client retrieves an image

● May accept gif & jpeg formats
● The server provides the image encoded (MIME)

31
 HTTP PUT request example

● The client sends a web

page to be posted on
the server
● The body contains
the page
● The server returns the
result of the execution
of the CGI script in the
body

32
 HTTP conditional requests

● The client may include a condition in the request

● The server sends a response in case it matches
● Mainly used for date & time modifications

GET http://www.MyServer.com/info/file1 HTTP/1.1 Request line Request if changed

If-Modified-Since: Wed, Jan 06 00:00:00 GMT Header line after the 6th of
Blank line January at 0 hours

HTTP/1.1 304 Not Modified Status line Not changed

Date: Thu, Jan 07 01:20:48 GMT Header lines therefore
Server: MyServer.com page not sent
Blank line
(Empty Body) Empty body

33
 Cookies

● The web was designed as a stateless entity

● But today state is required in situation such as:
● Electronic stores (shopping cart)
● Restricted access to registered users
● Portals where the user controls what it's displayed
● etc

34
 Cookies

●
Cookie creation process
● The server receives a request from a client and stores certain information
(cookie) in a database
– Domain name, user name, timestamp, etc
● The server includes the cookie in the response
– In the header line
● The client stores the cookie locally
– Local filesystem and associated to the user profile
● Use of the cookie
● On the request the browser looks for a locally stored cookie
● If it exists, it is sent to the server that will “recognize” the user
– In the header line

35
 Cookies example

● On-line toys store

1) Request
2) Empty cart with code
12343 + page with the
toys
3) Client requests a toy
4) Server updates the cart
and sends a page with
total price
5) The client sends
payment data
● While the cookie is not
deleted the server will
remember about you

36
 Web caches (proxy server)

Goal: satisfy client request without involving origin server

● user sets browser: Web origin

accesses via cache server
● browser sends all HTTP
Proxy
requests to cache
server
● object in cache: cache returns
client
object
● else cache requests object
from origin server, then returns
object to client

client
origin
server

37
 More about Web caching
● Cache acts as both client and server
● Typically cache is installed by ISP
(university, company, residential
ISP)
Why Web caching?
● Reduce response time for client
request.
● Reduce traffic on an institution’s
access link.
● Internet dense with caches: enables
“poor” content providers to
effectively deliver content (but so
does P2P file sharing)
38
 Caching example
origin
Assumptions
servers
● average object size = 100,000 bits
● avg. request rate from institution’s public
browsers to origin servers = 15/sec Internet
● delay from institutional router to any
origin server and back to router = 2
sec
1.5 Mbps
Consequences
access link
● utilization on LAN = 15%
● utilization on access link = 100% institutional
network
● total delay = Internet delay + access 10 Mbps LAN
delay + LAN delay
= 2 sec + minutes + milliseconds

institutional
cache

39
 Caching example (cont)
origin
Possible solution
servers
● increase bandwidth of access link to,
say, 10 Mbps public
Consequences Internet
● utilization on LAN = 15%
● utilization on access link = 15%
● Total delay = Internet delay + access
delay + LAN delay 10 Mbps
access link
= 2 sec + msecs + msecs
● often a costly upgrade institutional
network
10 Mbps LAN

institutional
cache

40
 Caching example (cont)
origin
Install cache servers
● suppose hit rate is .4 public
Consequence Internet
● 40% requests will be satisfied
almost immediately
● 60% requests satisfied by origin
server
● utilization of access link reduced to 1.5 Mbps
60%, resulting in negligible delays access link
(say 10 msec)
● total avg delay = Internet delay + institutional
access delay + LAN delay = . network
10 Mbps LAN
6*(2.01) secs + .4*milliseconds <
1.4 secs

institutional
cache

41
Electronic mail
RFC5321 (SMTP)
RFC1939 (POP3)
RFC3501 (IMAP4)

42
 Electronic Mail outgoing
message queue

user mailbox
user
Three major components: agent
● user agents mail
user
● mail servers server
agent
● simple mail transfer protocol: SMTP
SMTP mail
User Agent server user
● a.k.a. “mail reader” SMTP agent
● composing, editing, reading mail
messages SMTP
e.g., outlook, pine, mutt, thunderbird user
●
mail
server agent
● outgoing, incoming messages stored
on server
user
agent

user
agent

43
 Electronic Mail: mail servers

Mail Servers
● mailbox contains incoming messages
for user
● message queue of outgoing (to be
sent) mail messages
● SMTP protocol between mail servers
to send email messages
● client: sending mail server
● server: receiving mail server

44
 RFC
RFC
Electronic Mail: SMTP 282
282
11

● 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
● commands: ASCII text
● response: status code and phrase
● Messages must be in 7-bit ASCII

45
 Scenario:
Alice sends message to Bob

1) Alice uses UA to compose message 4) SMTP client sends Alice’s message

and “to” bob@someschool.edu
2) Alice’s UA sends message to her mail
server; message placed in message
queue
3) Client side of SMTP opens TCP
connection with Bob’s mail server
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

1 mail
mail
server user
user server
agent
agent 2 3 6
4
5

46
 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: From: Alice <alice@crepes.fr>
C: To: Bob <bob@hamburger.edu>
C: Subject: Toppings
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
47
 Try SMTP interaction for yourself:

● ncat servername 25
● see 220 reply from server
●
enter HELO, MAIL FROM, RCPT TO, DATA, QUIT commands
above lets you send email without using email client (reader)

48
 SMTP: final words
● 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 msg
● SMTP: multiple objects sent in
multipart msg
49
 Mail message format

SMTP: protocol for exchanging email msgs

RFC 822: standard for text message header
format: blank
line
●
header lines, e.g.,
●
To:
●
From:
●
Subject: body
different from SMTP commands!
●
body
●
the “message”, ASCII characters only

50
 Message format: multimedia extensions

RFC
RFC
● MIME: multimedia mail extension.
2045
2045
● additional lines in msg header declare MIME content type 2056
2056

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

51
 Mail access protocols

SMTP SMTP access

user protocol user
agent agent

sender’s mail receiver’s mail

server server

● SMTP: delivery/storage to receiver’s server

● Mail access protocol: retrieval from server
● POP: Post Office Protocol RFC
RFC
– authorization (agent <-->server) and download 193
193
● IMAP: Internet Mail Access Protocol 99
– more features (more complex) RFC
RFC
– manipulation of stored messages on server 173
173
00
● HTTP: Gmail , Yahoo! Mail, etc.

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

53
 POP3 (more) and IMAP
More about POP3
● Previous example uses
“download and delete”
mode.
● Bob cannot re-read e-mail if
he changes client
● “Download-and-keep”:
copies of messages on
different clients
● POP3 is stateless across
sessions
IMAP
● Keep all messages in one
place: the server
● Allows user to organize
messages in folders
● IMAP keeps user state
across sessions:
● names of folders and
mappings between message
IDs and folder name
54
 DNS
RFC1034/RFC1035

55
 DNS: Domain Name System
People: many identifiers:
● SSN, name, passport #
Internet hosts, routers:
● IP address (32 bit) - used for
addressing datagrams
● “name”, e.g., www.yahoo.com -
used by humans
Q: map between IP addresses
and name ?
Domain Name System:
● distributed database implemented in
hierarchy of many name servers
● application-layer protocol host,
routers, name servers to
communicate to resolve names
(address/name translation)
● note: core Internet function,
implemented as application-layer
protocol
● complexity at network’s “edge”
56
 DNS

Why not centralize DNS? DNS services

● Single point of failure ● Hostname to IP address
● Traffic volume translation
● Distant centralized database ● Host aliasing
● Canonical and alias names
● Maintenance
● Mail server aliasing
Doesn’t scale!
● Load distribution
● Replicated Web servers: set of
IP addresses for one canonical
name

57
 Distributed, Hierarchical Database
Root DNS Servers

com DNS servers org DNS servers edu DNS servers

pbs.org poly.edu umass.edu

yahoo.com amazon.com
DNS servers DNS servers DNS servers
DNS servers DNS servers

Client wants IP for www.amazon.com; 1st approx:

● Client queries a 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”

58
 DNS: Root name servers

● Contacted by local name server that can not resolve name

● Root name server:
● contacts authoritative name server if name mapping not known
● gets mapping
● returns mapping to local name server

a Verisign, Dulles, VA
c Cogent, Herndon, VA (also Los Angeles)
d U Maryland College Park, MD k RIPE London (also Amsterdam, Frankfurt)
g US DoD Vienna, VA
h ARL Aberdeen, MD i Autonomica, Stockholm (plus 3 other
j Verisign, ( 11 locations)
locations)

m WIDE Tokyo
e NASA Mt View, CA
f Internet Software C. Palo Alto, CA
(and 17 other locations)

13 root name servers

worldwide
b USC-ISI Marina del Rey, CA
l ICANN Los Angeles, CA

59
 TLD and Authoritative Servers

● Top-level domain (TLD) servers: responsible for com, org,

net, edu, etc, and all top-level country domains uk, fr, ca,
jp.
● Network solutions maintains servers for com TLD

● Educause for edu TLD

● CIRA for ca TLD

● Authoritative DNS servers: organization’s DNS servers,

providing authoritative hostname to IP mappings for
organization’s servers (e.g., Web and mail).
● Can be maintained by organization or service provider

60
 Local Name Server

● Does not strictly belong to hierarchy

● Each ISP (residential ISP, company, university)
has one.
● Also called “default name server”
● When a host makes a DNS query, query is sent to
its local DNS server
● Acts as a proxy, forwards query into hierarchy.

61
 Example root DNS server

● Host at cis.poly.edu wants IP 2

address for www.uwaterloo.ca 3
TLD DNS server
4

5
local DNS server
dns.poly.edu

7 6
1 8

authoritative DNS server

ns1.uwaterloo.ca
requesting host
cis.poly.edu

www.uwaterloo.ca

62
 Recursive queries
root DNS server

recursive query:
□ puts burden of name 2 3
resolution on contacted 6
name server 7
□ heavy load? TLD DNS server

iterated query: local DNS server

□ contacted server replies dns.poly.edu 5 4
with name of server to
contact 1 8
□ “I don’t know this name, but
ask this server” authoritative DNS server
ns1.uwaterloo.ca
requesting host
cis.poly.edu

www.uwaterloo.ca

63
 DNS: caching and updating records

● Once (any) name server learns mapping, it caches mapping

● cache entries timeout (disappear) after some time
● TLD servers typically cached in local name servers
– Thus root name servers not often visited
● Update/notify mechanisms under design by IETF
● RFC 2136
● http://www.ietf.org/html.charters/dnsind-charter.html

64
 DNS records

DNS: distributed db storing resource records (RR)

RR format: (name, value, type, ttl)

□ Type=A
♦ name is hostname
♦ value is IP address
□ Type=NS
♦ name is domain (e.g. foo.com)
♦ value is hostname of authoritative
name server for this domain
□ Type=CNAME
♦ name is alias name for some “canonical”
(the real) name
♦ www.ibm.com is really
servereast.backup2.ibm.com
♦ value is canonical name
□ Type=MX
♦ value is name of mailserver associated
with name

65
 DNS protocol, messages

DNS protocol : query and reply messages, both with same message
format

msg header
□ identification: 16 bit # for query,
reply to query uses same #
□ flags:
♦ query or reply
♦ recursion desired
♦ recursion available
♦ reply is authoritative

66
 DNS protocol, messages

Name, type fields

for a query

RRs in response
to query

records for
authoritative servers

additional “helpful”
info that may be used

67
 Inserting records into DNS

● Example: just created startup “Network Utopia”

● Register name networkuptopia.com at a registrar (e.g., Network
Solutions)
● Need to provide registrar with names and IP addresses of your 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)

● Put in authoritative server Type A record for

www.networkuptopia.com and Type MX record for
networkutopia.com
● How do people get the IP address of your Web site?

68
P2P Sharing
RFC5694

69
 P2P file sharing
Example
● Alice runs P2P client
application on her notebook
computer
● Intermittently connects to
Internet; gets new IP address
for each connection
● Asks for “Hey Jude”
● Application displays other
peers that have copy of Hey
Jude.
● Alice chooses one of the
peers, Bob.
● File is copied from Bob’s PC to
Alice’s notebook: HTTP
● While Alice downloads, other
users uploading from Alice.
● Alice’s peer is both a Web
client and a transient Web
server.
All peers are servers = highly
scalable!
70
 P2P: centralized directory

original “Napster” design Bob

1) when peer connects, it informs centralized
directory server
central server: 1
● IP address peers
● content 1

2) Alice queries for “Hey Jude”

3
3) Alice requests file from Bob 1

2 1

Alice

71
 P2P: problems with centralized directory

● Single point of failure

file transfer is decentralized,
● Performance bottleneck but locating content is
● Copyright infringement highly centralized

72
 Query flooding: Gnutella
● Fully distributed
● no central server
● Public domain protocol
● Many Gnutella clients
implementing protocol
Overlay network: graph
● Edge between peer X and Y if
there’s a TCP connection
● All active peers and edges is
overlay net
● Edge is not a physical link
● Given peer will typically be
connected with < 10 overlay
neighbors
73
 Gnutella: protocol
File transfer:
□ Query message HTTP
sent over existing TCP
connections
Query
□ Peers forward QueryHit
Query message
□ QueryHit
sent over
reverse
Query
path
QueryHit

Scalability:
limited scope
flooding
74
 Gnutella: Peer joining

1. Joining peer X must find some other peer in Gnutella network: use
list of candidate peers
2. X sequentially attempts to make TCP with peers on list until
connection setup with Y
3. X sends Ping message to Y; Y forwards Ping message.
4. All peers receiving Ping message respond with Pong message
5. X receives many Pong messages. It can then setup additional TCP
connections

75
 Exploiting heterogeneity: KaZaA

● Each peer is either a group leader

or assigned to a group leader.
● TCP connection between peer and its
group leader.
● TCP connections between some
pairs of group leaders.
● Group leader tracks the content in
all its children.

o r d in a r y p e e r

g r o u p - le a d e r p e e r

n e ig h o r in g r e la tio n s h ip s
in o v e r la y n e tw o r k

76
 KaZaA: Querying

● Each file has a hash and a descriptor

● Client sends keyword query to its group leader
● Group leader responds with matches:
● For each match: metadata, hash, IP address
● If group leader forwards query to other group
leaders, they respond with matches
● Client then selects files for downloading
● HTTP requests using hash as identifier sent to peers
holding desired file

77
 KaZaA tricks

● Limitations on simultaneous uploads

● Request queuing

● Incentive priorities

● Parallel downloading

78
 BitTorrent

● Peers in P2P leave often

● bad if Alice leaves while Bob is downloading a (huge) file from her

● BitTorrent breaks files into segments (256 KB) and shares

segments instead
● peers request segments that are rare early on to increase their availability

● BitTorrent does not provide mechanism for locating content

● assumes that clients have a “.torrent” file, listing name of “tracker server”,
which keeps track of peers having segments

79
BitTorrent

en_Wikipedia

80
 References

● B.F. Transmisión de datos y redes de comunicaciones, cuarta edición 2007.

● Chapter 25.
● A.S. Redes de computadores. Pearson Educación, Cuarta edición, 2003.
● Chapter 7.
● For further understanding:
● Behrouz A. Forouzan. TCP/IP Protocol Suite. McGraw-Hill, 2003.
– Chapters 18, 20, 22, 24, 25.
● Cited RFCs.

81