Advanced Networks
Advanced Network Technologies
Applications
School of Computer Science
Dr. | Lecturer
1
Web caches (proxy server)
user sets browser: Web accesses via cache
browser sends all HTTP requests to cache
if object in cache:
then cache returns object
else cache requests object from origin server, then returns object to client
goal: satisfy client request without involving origin server
client
proxy
server
client
HTTP request
HTTP response
HTTP request
HTTP request
origin
server
origin
server
HTTP response
HTTP response
2
More about Web caching
Q: Does the cache act as a client or a server?
3
More about Web caching
R: 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)
why Web caching?
reduce response time for client request
reduce traffic on an institution’s access link
4
origin
servers
public
Internet
institutional
network
1 Gbps LAN
1.54 Mbps
access link
assumptions:
avg object size: 100K bits
avg request rate from browsers to origin servers:15/sec (1.5 Mbps service )
RTT from institutional router to any origin server: 2 sec
access link rate: 1.54 Mbps
consequences:
LAN utilization: 0.15%
LANU = avg req rate * size / link bandwidth
access link utilization = 99%
ALU = avg req rate * size / link bankwidth
total delay = 2 sec + seconds + usecs
Q: what happens with fatter access link?
problem!
Caching example
5
assumptions:
avg object size: 100K bits
avg request rate from browsers to origin servers:15/sec
RTT from institutional router to any origin server: 2 sec
access link rate: 1.54 Mbps
consequences:
LAN utilization: 0.15%
access link utilization = 99%
total delay = 2 sec + seconds + usecs
origin
servers
1.54 Mbps
access link
154 Mbps
154 Mbps
msecs
Cost: increased access link speed (not cheap!)
0.99%
public
Internet
institutional
network
1 Gbps LAN
Caching example: fatter access link
6
institutional
network
1 Gbps LAN
origin
servers
1.54 Mbps
access link
local web
cache
assumptions:
avg object size: 100K bits
avg request rate from browsers to origin servers:15/sec
RTT from institutional router to any origin server: 2 sec
access link rate: 1.54 Mbps
consequences:
LAN utilization: 0.15%
access link utilization = 0%
total delay = usecs
Cost: web cache (cheap!)
public
Internet
Caching example: install local cache
7
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
average total delay
= 0.6 * (delay from origin servers) +0.4 * (delay when satisfied at cache)
Link utilization is around 60%, queueing delay is small enough
= 0.6 (~2.x second) + 0.4 (~usecs)
less than with 154 Mbps link (and cheaper too!)
origin
servers
1.54 Mbps
access link
public
Internet
institutional
network
1 Gbps LAN
local web
cache
Caching example: install local cache
8
Conditional GET
Goal: don’t send object if client has up-to-date cached version
no object transmission delay
lower link utilization
client: specify date of cached copy in HTTP request
If-modified-since:
server: response contains no object if cached copy is up-to-date:
HTTP/1.0 304 Not Modified
HTTP request msg
If-modified-since:
HTTP response
HTTP/1.0
304 Not Modified
object
not
modified
HTTP request msg
If-modified-since:
HTTP response
HTTP/1.0 200 OK
object
modified
after
client
server
9
HTTP/2
Key goal: decreased delay in multi-object HTTP requests
HTTP1.1: introduced multiple, pipelined GETs over single TCP connection
server responds in-order (FCFS: first-come-first-served scheduling) to GET requests
with FCFS, small object may have to wait for transmission (head-of-line (HOL) blocking) behind large object(s)
loss recovery (retransmitting lost TCP segments) stalls object transmission
Application Layer: 2-10
t’
10
HTTP/2
Key goal: decreased delay in multi-object HTTP requests
HTTP/2: [RFC 7540, 2015] increased flexibility at server in sending objects to client:
methods, status codes, most header fields unchanged from HTTP 1.1
transmission order of requested objects based on client-specified object priority (not necessarily FCFS)
push unrequested objects to client
divide objects into frames, schedule frames to mitigate Head-of-line (HOL) blocking
Application Layer: 2-11
t’
11
HTTP/2: mitigating HOL blocking
HTTP 1.1: client requests 1 large object (e.g., video file, and 3 smaller objects)
client
server
GET O1
GET O2
GET O3
GET O4
O1
O2
O3
O4
object data requested
O1
O2
O3
O4
objects delivered in order requested: O2, O3, O4 wait behind O1
Application Layer: 2-12
t’
12
HTTP/2: mitigating HOL blocking
HTTP/2: objects divided into frames, frame transmission interleaved
client
server
GET O1
GET O2
GET O3
GET O4
O2
O4
object data requested
O1
O2
O3
O4
O2, O3, O4 delivered quickly, O1 slightly delayed
O3
O1
Application Layer: 2-13
shortest job first: decreased average delay!
13
HTTP/2 Streams and frames
Client
Server
HTTP/2 Streams and frames
Frames:
Basic HTTP/2 data unit, replacing HTTP/1.1 header and body format.
HTTP/2 frames have a binary encoding (more efficient).
Header frames, Data frames
Streams
Bidirectional channel where frames are transmitted
Replacing HTTP/1.1 Request-Response mode
A single TCP connection to carry multiple streams
HTTP/2 push
The HTTP/2 Server Push mechanism allows the server to send resources proactively without waiting for a request, when it believes the client will need them.
https://blog.golang.org/h2push
Outline
Web and HTTP (Done)
FTP
DNS
P2P
FTP
file transfer
FTP
server
FTP
user
interface
FTP
client
local file
system
remote file
system
user
at host
transfer file to/from remote host
client/server model
client: side that initiates transfer (either to/from remote)
server: remote host
ftp: RFC 959
ftp server: port 21, 20
FTP: the file transfer protocol
19
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
FTP
client
FTP
server
TCP control connection,
server port 21
TCP data connection,
server port 20
server opens another TCP data connection to transfer another file
control connection: “out of band”
FTP server maintains “state”: current directory, earlier authentication
FTP is stateful as server maintains “state”
20
FTP commands, responses
sample commands:
sent as ASCII text over control channel
USER username
PASS password
LIST return 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
21
Email
SMTP: Simple Mail Transfer Protocol
IMAP: Internet Message Access Protocol
POP3: Post Office Protocol 3
Three major components:
user agents (clients)
mail servers
simple mail transfer protocol: SMTP
User Agent
a.k.a. “mail reader”
composing, editing, reading mail messages
e.g., Outlook, Thunderbird, iPhone mail client
user mailbox
outgoing
message queue
mail
server
mail
server
mail
server
SMTP
SMTP
SMTP
user
agent
user
agent
user
agent
user
agent
user
agent
user
agent
Electronic mail
23
mail servers:
mailbox contains incoming messages for user
message queue of outgoing (to be sent) mail messages
SMTP protocol to send email messages between mail servers
client: sending mail to server
“server”: receiving mail from server
mail
server
mail
server
mail
server
SMTP
SMTP
SMTP
user
agent
user
agent
user
agent
user
agent
user
agent
user
agent
Electronic mail: mail servers
24
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
Q: is SMTP stateful or stateless?
Stateful
Electronic Mail: SMTP [RFC 2821]
R: STMP is stateful as he maintains information about the client
25
user
agent
1) Alice uses UA to compose message “to”
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
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
mail
server
mail
server
1
2
3
4
5
6
Alice’s mail server
Bob’s mail server
user
agent
Scenario: Alice sends message to A: user agent
26
S: 220 hamburger.edu
C: HELO crepes.fr
S: 250 Hello crepes.fr, pleased to meet you
C: MAIL FROM:
S: 250 Sender ok
C: RCPT TO:
S: 250 … 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
Sample SMTP interaction
27
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
Carriage return
Line feed
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 one msg
SMTP: final words
28
SMTP: protocol for exchanging email msgs
RFC 822: standard for text message format:
header lines, e.g.,
To:
From:
Subject:
different from SMTP MAIL FROM, RCPT TO: commands!
Body: the “message”
ASCII characters only
header
body
blank
line
Mail message format
29
SMTP: delivery/storage to receiver’s server
mail access protocol: retrieval from server
POP: Post Office Protocol [RFC 1939]: authorization, download
IMAP: Internet Mail Access Protocol [RFC 1730]: more features, including manipulation of stored msgs on server
HTTP: Using a browser to access a webmail https://webmail.sydney.edu.au
sender’s mail
server
SMTP
SMTP
mail access
protocol
receiver’s mail
server
(e.g., POP,
IMAP)
user
agent
user
agent
Mail access protocols
30
authorization phase
client commands:
user: declare username
pass: password
server responses
+OK
-ERR
transaction phase, client:
list: list message numbers
retr: retrieve message by number
dele: delete
quit
C: list
S: 1 498
S: 2 912
S: .
C: retr 1
S:
S: .
C: dele 1
C: retr 2
S:
S: .
C: dele 2
C: quit
S: +OK POP3 server signing off
S: +OK POP3 server ready
C: user bob
S: +OK
C: pass hungry
S: +OK user successfully logged on
POP3 Protocol
31
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
POP3 (more) and IMAP
32
DNS
Internet hosts, routers:
IP address (32 bit) – used for addressing datagrams
“name”, e.g., www.yahoo.com – used by humans
people: many identifiers:
name, passport #
Q: how to map between IP address and name, and vice versa ?
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)
DNS: domain name system
SSN: social security number (id number in the US).
34
DNS: services, structure
why not centralize DNS?
single point of failure
distant centralized database
scalability
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
35
Root DNS Servers
com DNS servers
org DNS servers
edu DNS servers
poly.edu
DNS servers
umass.edu
DNS servers
yahoo.com
DNS servers
amazon.com
DNS servers
pbs.org
DNS servers
client wants IP for www.amazon.com; 1st approx:
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
…
…
DNS: a distributed, hierarchical database
36
DNS: root name servers
13 root name “servers” worldwide
a. Verisign, Los Angeles CA
(5 other sites)
b. USC-ISI Marina del Rey, CA
l. ICANN Los Angeles, CA
(41 other sites)
e. NASA Mt View, CA
f. Internet Software C.
Palo Alto, CA (and 48 other sites)
i. Netnod, Stockholm (37 other sites)
k. RIPE London (17 other sites)
m. WIDE Tokyo
(5 other sites)
c. Cogent, Herndon, VA (5 other sites)
d. U Maryland College Park, MD
h. ARL Aberdeen, MD
j. Verisign, Dulles VA (69 other sites )
g. US DoD Columbus, OH (5 other sites)
Closing of megaupload
37
top-level domain (TLD) servers:
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
authoritative DNS servers:
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
TLD, authoritative servers
38
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
Local DNS name server
39
requesting host
cis.poly.edu
gaia.cs.umass.edu
root DNS server
local DNS server
dns.poly.edu
1
2
3
4
5
6
authoritative DNS server
dns.cs.umass.edu
7
8
TLD DNS server
host at cis.poly.edu wants IP address for gaia.cs.umass.edu
iterated query:
contacted server replies with name of server to contact
“I don’t know this name, but ask this server”
DNS name resolution example
.edu DNS server
40
4
5
6
3
recursive query:
puts burden of name resolution on contacted name server
heavy load at upper levels of hierarchy?
requesting host
cis.poly.edu
gaia.cs.umass.edu
root DNS server
local DNS server
dns.poly.edu
1
2
7
authoritative DNS server
dns.cs.umass.edu
8
DNS name resolution example (cont’d)
TLD DNS server
.edu DNS server
41
once (any) name server learns mapping, it caches mapping
cache entries timeout (disappear) after some time (TTL)
cached entries may be out-of-date (best effort name-to-address translation!)
if name host changes IP address, may not be known Internet-wide until all TTLs expire
update/notify mechanisms proposed IETF standard
RFC 2136
DNS caching, updating records
42
DNS: distributed db storing resource records (RR)
type=NS
name is domain (e.g., foo.com)
value is hostname of authoritative name server for this domain
RR format: (name, value, type, ttl)
type=A
name is hostname
value is IP address
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
DNS records
43
example: new startup “Network Utopia”
register name networkuptopia.com at DNS registrar (e.g., Network Solutions)
provide names, IP addresses of authoritative name server
registrar inserts two RRs into .com TLD server:
(networkutopia.com, dns1.networkutopia.com, NS)
(dns1.networkutopia.com, 212.212.212.1, A)
create at authoritative server
type A record for www.networkuptopia.com;
(www.networkutopia.com, 212.212.212.22, A)
(www.home.networkutopia.com, www.networkutopia.com, CNAME)
Inserting records into DNS
44
Socket Programming
45
Socket programming
goal: learn how to build client/server applications that communicate using sockets
socket: door between application process and end-end-transport protocol
46
Internet
controlled
by OS
controlled by
app developer
transport
application
physical
link
network
process
transport
application
physical
link
network
process
socket
Socket programming
Two socket types for two transport services:
UDP: unreliable datagram
TCP: reliable, byte stream-oriented
47
Application Example:
Client reads a line of characters (data) from its keyboard and sends the data to the server.
The server receives the data and converts characters to uppercase.
The server sends the modified data to the client.
The client receives the modified data and displays the line on its screen.
47
Socket programming with UDP
UDP: no “connection” between client & server
no handshaking before sending data
sender explicitly attaches IP destination address and port # to each packet
receiver extracts sender IP address and port # from received packet
UDP: transmitted data may be lost or received out-of-order
Application viewpoint:
UDP provides unreliable transfer of groups of bytes (“datagrams”) between client and server
48
48
close
clientSocket
read datagram from
clientSocket
create socket:
clientSocket =
socket(AF_INET,SOCK_DGRAM)
Create datagram with server IP and
port=x; send datagram via
clientSocket
create socket, port= x:
serverSocket =
socket(AF_INET,SOCK_DGRAM)
read datagram from
serverSocket
write reply to
serverSocket
specifying
client address,
port number
server (running on serverIP)
client
Client/server socket interaction: UDP
49
AF_INER indicates IPv4 and SOCK_DGRAM indicates UDP
49
from socket import *
serverName = ‘hostname’
serverPort = 12000
clientSocket = socket(socket.AF_INET,
socket.SOCK_DGRAM)
message = input(’Input lowercase sentence:’)
message = message.encode(‘utf-8’)
clientSocket.sendto(message,(serverName, serverPort))
modifiedMessage, serverAddress =
clientSocket.recvfrom(2048)
print (modifiedMessage.decode(‘utf-8’))
clientSocket.close()
Python UDPClient
include Python’s socket
library
create UDP for server
get user keyboard
input
Attach server name, port to message; send into socket
print out received string and close socket
read reply characters from
socket into string
UDP client
50
convert from string to bytes
convert from bytes to string
New feature in Python 3
from socket import *
serverPort = 12000
serverSocket = socket(AF_INET, SOCK_DGRAM)
serverSocket.bind((”, serverPort))
print “The server is ready to receive”
while 1:
message, clientAddress = serverSocket.recvfrom(2048)
message=message.decode(‘utf-8’)
modifiedMessage = message.upper()
serverSocket.sendto(modifiedMessage.encode(‘utf-8’),
clientAddress)
Python UDPServer
create UDP socket
bind socket to local port number 12000
loop forever
Read from UDP socket into message, getting client’s address (client IP and port)
send upper case string back to this client
UDP server
51
Socket programming with TCP
client must contact server
server process must first be running
server must have created socket (door) that welcomes client’s contact
client contacts server by:
creating TCP socket, connecting server by specifying IP address, port number of server process
client connects: client TCP establishes connection to server TCP
when contacted by client, server TCP creates new socket for server process to communicate with that particular client
allows server to talk with multiple clients
source port numbers used to distinguish clients
52
TCP provides reliable, in-order
byte-stream transfer (“pipe”)
between client and server
application viewpoint:
Accept client
connectionSocket =
serverSocket.accept()
create socket,
port=x,
serverSocket = socket() wait for incoming
connection request
serverSocket.listen(1)
create socket,
connect to hostid, port=x
clientSocket = socket()
clientSocket.connect((hostid, x))
server (running on hostid)
client
send request using
clientSocket
read request from
connectionSocket
write reply to
connectionSocket
TCP
connection setup
close
connectionSocket
read reply from
clientSocket
close
clientSocket
Client-server socket interaction TCP
53
from socket import *
serverName = ’servername’
serverPort = 12000
clientSocket = socket(AF_INET, SOCK_STREAM)
clientSocket.connect((serverName,serverPort))
sentence = input(‘Input lowercase sentence:’)
clientSocket.send(sentence.encode(‘utf-8’))
## Do not specify serverName,serverPort
modifiedSentence = clientSocket.recv(1024)
print (‘From Server:’, modifiedSentence.decode(‘utf-8’))
clientSocket.close()
Python TCPClient
create TCP socket for server, remote port 12000
No need to attach server name, port
TCP client
54
54
from socket import *
serverPort = 12000
serverSocket = socket(AF_INET, SOCK_STREAM)
serverSocket.bind((‘’, serverPort))
serverSocket.listen(1)
print (‘The server is ready to receive’)
while 1:
connectionSocket, addr = serverSocket.accept()
sentence = connectionSocket.recv(1024)
capitalizedSentence = sentence.decode(‘utf-8’).upper().encode(‘utf-8’)
connectionSocket.send(capitalizedSentence)
connectionSocket.close()
Python TCPServer
create TCP welcoming
socket
server begins listening for incoming TCP requests
loop forever
server waits on accept()
for incoming requests, new socket created on return
read bytes from socket (but not address as in UDP)
close connection to this client (but not welcoming socket)
TCP server
55
Peer-to-Peer
56
Pure peer-to-peer model architecture
no always-on server
arbitrary end systems directly communicate
peers are intermittently connected and change IP addresses
examples:
file distribution (BitTorrent)
Streaming (Zattoo, KanKan)
VoIP (Skype)
57
57
File distribution: client-server vs. p2p
Question: how much time to distribute file (size F) from one server to N peers?
peer upload/download capacity is limited resource
58
us
uN
dN
server
network (with abundant
bandwidth)
file, size F
us: server upload capacity
ui: peer i upload capacity
di: peer i download capacity
u2
d2
u1
d1
di
ui
Let assume that U1 = … = UN = Us, then it is NF/Us.
But if they are different, we have: Max(NF/Us, F/U_1, …, F/U_N)
58
File distribution time: client-server
server transmission: must sequentially send (upload) N file copies:
time to send one copy: F/us
time to send N copies: NF/us
59
increases linearly in N
time to distribute F
to N clients using
client-server approach
Dc-s > max{NF/us,,F/dmin}
client: each client must download file copy
dmin = min client download rate
(worst case) client download time: F/dmin
us
network
di
ui
F
59
60
server transmission: must upload at least one copy
time to send one copy: F/us
time to distribute F
to N clients using
P2P approach
us
network
di
ui
F
DP2P > max{F/us,,F/dmin,,NF/(us + Sui)}
client: each client must download file copy
client download time: F/dmin
clients: as aggregate must download NF bits = upload NF bits
Max upload rate us + Sui
NF/(us + Sui)
… but so does this, as each peer brings service capacity
increases linearly in N …
File distribution time: p2p
60
client upload rate = u, F/u = 1 hour, us = 10u, dmin ≥ us
Client-server vs. p2p
61
61
P2P file distribution: BitTorrent
20% of European internet traffic in 2012.
Used for Linux distribution, software patches, distributing movies
Goal: quickly replicate large files to large number of clients
Web server hosts a .torrent file (w/ file length, hash, tracker’s URL…)
A tracker tracks downloaders/owners of a file
Files are divided into chunks (256kB-1MB)
Downloaders download chunks from themselves (and owners)
Tit-for-tat: the more one shares (server), the faster it can download (client)
62
BitTorrent, a file sharing application
37min
Source for the Internet traffic: http://www.scribd.com/doc/94722096/Sandvine-Global-Internet-Phenomena-Report-1H-2012
62
tracker: tracks peers
participating in torrent
torrent: group of peers exchanging chunks of a file
Alice arrives …
file divided into 256KB chunks
peers in torrent send/receive file chunks
… obtains list
of peers from tracker
… and begins exchanging
file chunks with peers in torrent
P2P file distribution: BitTorrent
63
63
P2P file distribution: BitTorrent
peer joining torrent:
has no chunks, but will accumulate them over time from other peers
registers with tracker to get list of peers, connects to subset of peers (“neighbors”)
64
while downloading, peer uploads chunks to other peers
peer may change peers with whom it exchanges chunks
churn: peers may come and go
once peer has entire file, it may (selfishly) leave or (altruistically) remain in torrent
64
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
65
sending chunks: tit-for-tat
Alice sends chunks to those four peers currently sending her chunks at highest rate
other peers are choked by Alice (do not receive chunks from her)
re-evaluate top 4 every10 secs
every 30 secs: randomly select another peer, starts sending chunks
“optimistically unchoke” this peer
newly chosen peer may join top 4
Choked: stopped
65
(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
higher upload rate: find better trading partners, get file faster !
BitTorrent: tit-for-tat
66
66
0
0.5
1
1.5
2
2.5
3
3.5
05101520253035
N
Minimum Distribution Time
P2P
Client-Server
Chart1
1 1
2 2
3 3
4 4
5 5
6 6
7 7
8 8
9 9
10 10
11 11
12 12
13 13
14 14
15 15
16 16
17 17
18 18
19 19
20 20
21 21
22 22
23 23
24 24
25 25
26 26
27 27
28 28
29 29
30 30
31 31
32 32
P2P
Client-Server
N
Minimum Distribution Time
0.1
0.1
0.1666666667
0.2
0.2307692308
0.3
0.2857142857
0.4
0.3333333333
0.5
0.375
0.6
0.4117647059
0.7
0.4444444444
0.8
0.4736842105
0.9
0.5
1
0.5238095238
1.1
0.5454545455
1.2
0.5652173913
1.3
0.5833333333
1.4
0.6
1.5
0.6153846154
1.6
0.6296296296
1.7
0.6428571429
1.8
0.6551724138
1.9
0.6666666667
2
0.6774193548
2.1
0.6875
2.2
0.696969697
2.3
0.7058823529
2.4
0.7142857143
2.5
0.7222222222
2.6
0.7297297297
2.7
0.7368421053
2.8
0.7435897436
2.9
0.75
3
0.756097561
3.1
0.7619047619
3.2
Sheet1
L P2P Client-Server ratio factor
1 0.1 0.1 1 10
2 0.1666666667 0.2
3 0.2307692308 0.3
4 0.2857142857 0.4
5 0.3333333333 0.5
6 0.375 0.6
7 0.4117647059 0.7
8 0.4444444444 0.8
9 0.4736842105 0.9
10 0.5 1
11 0.5238095238 1.1
12 0.5454545455 1.2
13 0.5652173913 1.3
14 0.5833333333 1.4
15 0.6 1.5
16 0.6153846154 1.6
17 0.6296296296 1.7
18 0.6428571429 1.8
19 0.6551724138 1.9
20 0.6666666667 2
21 0.6774193548 2.1
22 0.6875 2.2
23 0.696969697 2.3
24 0.7058823529 2.4
25 0.7142857143 2.5
26 0.7222222222 2.6
27 0.7297297297 2.7
28 0.7368421053 2.8
29 0.7435897436 2.9
30 0.75 3
31 0.756097561 3.1
32 0.7619047619 3.2
33 0.7674418605 3.3
34 0.7727272727 3.4
35 0.7777777778 3.5
36 0.7826086957 3.6
37 0.7872340426 3.7
38 0.7916666667 3.8
39 0.7959183673 3.9
40 0.8 4
41 0.8039215686 4.1
42 0.8076923077 4.2
43 0.8113207547 4.3
44 0.8148148148 4.4
45 0.8181818182 4.5
46 0.8214285714 4.6
47 0.8245614035 4.7
48 0.8275862069 4.8
49 0.8305084746 4.9
Sheet1
0 0
0 0
0 0
0 0
0 0
0 0
0 0
0 0
0 0
0 0
0 0
0 0
0 0
0 0
0 0
0 0
0 0
0 0
0 0
0 0
0 0
0 0
0 0
0 0
0 0
0 0
0 0
0 0
0 0
0 0
0 0
0 0
P2P
Client-Server
N
Minimum Distribution Time
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
Sheet2
Sheet3
/docProps/thumbnail.jpeg