2: Application Layer 1 06 - P2P applications, Sockets, UDP.

2: Application Layer 1

06 - P2P applications, Sockets, UDP


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


P2P file sharing

Clients connect directly to each other for the purpose of file transfer.

Three different architectures. HTTP for file transfer and

communication.


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


P2P: problems with centralized directory

Single point of failure Performance

bottleneck Copyright

infringement

file transfer is decentralized, but locating content is highly centralized


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


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


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


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#


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


Kazaa tricks

Limitations on simultaneous uploads Request queuing – ensures minimum

bandwidth Incentive priorities Parallel downloading


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


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


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


Example: Client (UDP)

sock = socket(...);

...

sendto(sock, ...);

...

recvfrom(sock, ...);

Create client socket

Send datagramto server

Read datagramfrom server


Example: Server (UDP)

sock = socket(...);bind(sock, ...);

...

recvfrom(sock, ...);

...

sendto(sock, ...);

Createdatagram socket

Receivedatagra

m

Write out datagramto socket


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


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


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


Example: Client (TCP)

sock = socket(…));connect(sock, …);

send(sock, …);

recv(sock, …);

Create client socket,

connect to server

Send lineto server

Read linefrom server


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


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


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 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


networkdata linkphysical



networkdata linkphysicalnetwork

data linkphysical

logical end-end transport


Transport vs. network layer

network layer: logical communication between hosts

transport layer: logical communication between processes relies on, enhances, network layer services


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


application





networkdata linkphysicalnetwork

data linkphysical

logical end-end transport


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:


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


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


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”


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


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


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


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


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

Date post:	22-Dec-2015
Category:	Documents
View:	225 times
Download:	0 times

2: Application Layer 1 06 - P2P applications, Sockets, UDP.

Documents