2: application layer 1 06 - p2p applications, sockets, udp
Post on 22-Dec-2015
227 views
TRANSCRIPT
2: Application Layer 1
06 - P2P applications, Sockets, UDP
2: Application Layer 2
Chapter 2Application Layer
Computer Networking: A Top Down Approach Featuring the Internet, 3rd edition. Jim Kurose, Keith RossAddison-Wesley, July 2004.
A note on the use of these ppt slides:We’re making these slides freely available to all (faculty, students, readers). They’re in PowerPoint form so you can add, modify, and delete slides (including this one) and slide content to suit your needs. They obviously represent a lot of work on our part. In return for use, we only ask the following: If you use these slides (e.g., in a class) in substantially unaltered form, that you mention their source (after all, we’d like people to use our book!) If you post any slides in substantially unaltered form on a www site, that you note that they are adapted from (or perhaps identical to) our slides, and note our copyright of this material.
Thanks and enjoy! JFK/KWR
All material copyright 1996-2004J.F Kurose and K.W. Ross, All Rights Reserved
2: Application Layer 3
P2P file sharing
Clients connect directly to each other for the purpose of file transfer.
Three different architectures. HTTP for file transfer and
communication.
2: Application Layer 4
P2P: centralized directory
original “Napster” design
1) when peer connects, it informs central server: IP address content
2) Alice queries for “Tawan Yor Saeng”
3) Alice requests file from Bob
centralizeddirectory server
peers
Alice
Bob
1
1
1
12
3
2: Application Layer 5
P2P: problems with centralized directory
Single point of failure Performance
bottleneck Copyright
infringement
file transfer is decentralized, but locating content is highly centralized
2: Application Layer 6
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
2: Application Layer 7
Gnutella: protocol
Query
QueryHit
Query
Query
QueryHit
Query
Query
QueryHit
File transfer:HTTP
Query messagesent over existing TCPconnections peers forwardQuery message QueryHit sent over reversepath
Scalability:limited scopeflooding
2: Application Layer 8
Gnutella: Peer joining (bootstrap problem)
1. Joining peer X must find some other peer in Gnutella network: use list of candidate peers or bootstrap nodes
2. X sequentially attempts to make TCP connections 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
2: Application Layer 9
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.
Image source: http://www.cachelogic.com/p2p/p2punderstanding.php#
2: Application Layer 10
KaZaA: Querying
Client sends keyword query to its group leader
Group leader responds with matches If group leader forwards query to other
group leaders, they respond with matches
Client then selects files for downloading
2: Application Layer 11
Kazaa tricks
Limitations on simultaneous uploads Request queuing – ensures minimum
bandwidth Incentive priorities Parallel downloading
2: Application Layer 12
Socket programming
Socket API introduced in BSD4.1 UNIX,
1981 explicitly created, used,
released by apps client/server paradigm two types of transport
service via socket API: unreliable datagram reliable, byte stream-
oriented
a host-local, application-created,
OS-controlled interface (a “door”) into which
application process can both send and
receive messages to/from another
application process
socket
Goal: learn how to build client/server application that communicate using sockets
2: Application Layer 13
Socket programming withUser Datagram Protocol (UDP)UDP: no “connection”
between client and server
no handshaking sender explicitly attaches
IP address and port of destination to each packet
server must extract IP address, port of sender from received packet
UDP: transmitted data may be received out of order, or lost
application viewpoint
UDP provides unreliable transfer of groups of bytes (“datagrams”)
between client and server
2: Application Layer 14
Client/server socket interaction: UDP
closeclientSocket
Server
read reply fromclientSocket
create socket,
clientSocket
Client
Create address(IP address and port number)send datagram request using clientSocket
create socket,port=x, forincoming request:
serverSocket
read request fromserverSocket
write reply toserverSocketspecifying clienthost address,port number
2: Application Layer 15
Example: Client (UDP)
sock = socket(...);
...
sendto(sock, ...);
...
recvfrom(sock, ...);
Create client socket
Send datagramto server
Read datagramfrom server
2: Application Layer 16
Example: Server (UDP)
sock = socket(...);bind(sock, ...);
...
recvfrom(sock, ...);
...
sendto(sock, ...);
Createdatagram socket
Receivedatagra
m
Write out datagramto socket
2: Application Layer 17
Socket-programming using Transmission Control Protocol (TCP)TCP service: reliable transfer of bytes from one
process to another
process
TCP withbuffers,
variables
socket
controlled byapplicationdeveloper
controlled byoperating
system
host orserver
process
TCP withbuffers,
variables
socket
controlled byapplicationdeveloper
controlled byoperatingsystem
host orserver
internet
2: Application Layer 18
Socket programming with TCPClient 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 client-local TCP
socket specifying IP address, port
number of server process When client creates
socket: client TCP establishes connection to server TCP
When contacted by client, server TCP creates new socket for server process to communicate with client allows server to talk
with multiple clients source port numbers
used to distinguish clients (more in Chap 3)
TCP provides reliable, in-order transfer of bytes (“pipe”) between client and server
application viewpoint
2: Application Layer 19
Client/server socket interaction: TCP
wait for incomingconnection request
connectionSocket
create socket,port=x, forincoming request:welcomeSocket =
ServerSocket()
create socket,connect using
clientSocket
closeconnectionSocket
read reply fromclientSocket
closeclientSocket
Server Client
send request usingclientSocketread request from
connectionSocket
write reply toconnectionSocket
TCP connection setup
2: Application Layer 20
Example: Client (TCP)
sock = socket(…));connect(sock, …);
send(sock, …);
recv(sock, …);
Create client socket,
connect to server
Send lineto server
Read linefrom server
2: Application Layer 21
Example: Server (TCP)
sock = socket(…);bind((sock, …); //Map port #listen(sock, …); //Allow connections...while(true) { //create a new socket for each client clntsock = accept(sock, ...); ... recv(clntsock, ...); ... send(clntsock, ...);}
Create welcoming
socket
Wait on welcomingsocket for contact
by client
Read in linefrom socket
Write out lineto socket
2: Application Layer 22
Chapter 2: Summary
application service requirements: reliability, bandwidth,
delay
client-server paradigm Internet transport
service model connection-oriented,
reliable: TCP unreliable, datagrams:
UDP
Our study of network apps now complete!
specific protocols: HTTP FTP SMTP, POP, IMAP DNS
socket programming
2: Application Layer 23
Chapter 2: Summary
typical request/reply message exchange: client requests info or
service server responds with
data, status code
message formats: headers: fields giving
info about data data: info being
communicated
Most importantly: learned about protocols
control vs. data msgs in-band, out-of-band
centralized vs. decentralized
stateless vs. stateful reliable vs. unreliable msg
transfer “complexity at network
edge” security: authentication
Transport Layer 3-24
Chapter 3Transport Layer
Computer Networking: A Top Down Approach Featuring the Internet, 3rd edition. Jim Kurose, Keith RossAddison-Wesley, July 2004.
A note on the use of these ppt slides:We’re making these slides freely available to all (faculty, students, readers). They’re in PowerPoint form so you can add, modify, and delete slides (including this one) and slide content to suit your needs. They obviously represent a lot of work on our part. In return for use, we only ask the following: If you use these slides (e.g., in a class) in substantially unaltered form, that you mention their source (after all, we’d like people to use our book!) If you post any slides in substantially unaltered form on a www site, that you note that they are adapted from (or perhaps identical to) our slides, and note our copyright of this material.
Thanks and enjoy! JFK/KWR
All material copyright 1996-2004J.F Kurose and K.W. Ross, All Rights Reserved
Transport Layer 3-25
Transport services and protocols provide logical
communication between app processes running on different hosts
transport protocols run in end systems send side: breaks app
messages into segments, passes to network layer
receive side: reassembles segments into messages, passes to app layer
more than one transport protocol available to apps Internet: TCP and UDP
application
transportnetworkdata linkphysical
application
transportnetworkdata linkphysical
networkdata linkphysical
networkdata linkphysical
networkdata linkphysical
networkdata linkphysicalnetwork
data linkphysical
logical end-end transport
Transport Layer 3-26
Transport vs. network layer
network layer: logical communication between hosts
transport layer: logical communication between processes relies on, enhances, network layer services
Transport Layer 3-27
Internet transport-layer protocols reliable, in-order
delivery (TCP) congestion control flow control connection setup
unreliable, unordered delivery: UDP no-frills extension of
“best-effort” IP
services not available: delay guarantees bandwidth guarantees
application
transportnetworkdata linkphysical
application
transportnetworkdata linkphysical
networkdata linkphysical
networkdata linkphysical
networkdata linkphysical
networkdata linkphysicalnetwork
data linkphysical
logical end-end transport
Transport Layer 3-28
Multiplexing/demultiplexing
application
transport
network
link
physical
P1 application
transport
network
link
physical
application
transport
network
link
physical
P2P3 P4P1
host 1 host 2 host 3
= process= socket
delivering received segmentsto correct socket
Demultiplexing at rcv host:gathering data from multiplesockets, enveloping data with header (later used for demultiplexing)
Multiplexing at send host:
Transport Layer 3-29
How demultiplexing works host receives IP datagrams
each datagram has source IP address, destination IP address
each datagram carries 1 transport-layer segment
each segment has source, destination port number (recall: well-known port numbers for specific applications)
host uses IP addresses & port numbers to direct segment to appropriate socket
source port # dest port #
32 bits
applicationdata
(message)
other header fields
TCP/UDP segment format
Transport Layer 3-30
Connectionless demultiplexing Create sockets with port
numbers: UDP socket identified by
two-tuple:(dest IP address, dest port number)
When host receives UDP segment: checks destination port
number in segment directs UDP segment to
socket with that port number
IP datagrams with different source IP addresses and/or source port numbers directed to same socket
Transport Layer 3-31
Connectionless demux (cont)
ClientIP:B
P2
client IP: A
P1P1P3
serverIP: C
SP: 6428DP: 9157
SP: 9157DP: 6428
SP: 6428DP: 5775
SP: 5775DP: 6428
SP provides “return address”
Transport Layer 3-32
Connection-oriented demux
TCP socket identified by 4-tuple: source IP address source port number dest IP address dest port number
recv host uses all four values to direct segment to appropriate socket
Server host may support many simultaneous TCP sockets: each socket identified
by its own 4-tuple
Transport Layer 3-33
Connection-oriented demux (cont)
ClientIP:B
P2
client IP: A
P1P1P3
serverIP: C
SP: 80DP: 9157
SP: 9157DP: 80
SP: 80DP: 5775
SP: 5775DP: 80
Transport Layer 3-34
UDP: User Datagram Protocol [RFC 768]
“no frills,” “bare bones” Internet transport protocol
“best effort” service, UDP segments may be: lost delivered out of order
to app connectionless:
no handshaking between UDP sender, receiver
each UDP segment handled independently of others
Why is there a UDP? no connection
establishment (which can add delay)
simple: no connection state at sender, receiver
small segment header no congestion control:
UDP can blast away as fast as desired
Transport Layer 3-35
UDP: more
often used for streaming multimedia apps loss tolerant rate sensitive
other UDP uses DNS SNMP
reliable transfer over UDP: add reliability at application layer application-specific
error recovery!
source port # dest port #
32 bits
Applicationdata
(message)
UDP segment format
length checksumLength, in
bytes of UDPsegment,including
header
Transport Layer 3-36
UDP checksum
Sender: treat segment contents
as sequence of 16-bit integers
checksum: addition (1’s complement sum) of segment contents
sender puts checksum value into UDP checksum field
Receiver: check if computed checksum
equals checksum field value: add all the received 16 bit fields
including the checksum
Is the answer all 1s?• NO - error detected• YES - no error detected. But
maybe errors nonetheless? More later ….
Goal: detect “errors” (e.g., flipped bits) in transmitted segment