Transcript Application Design based on TCP or UDP

Application Design based on TCP or UDP
Lesson 6
IHA præsentation
1
Outline for today
• The Internet Protocols: UDP & TCP
• Socket programming
• Application Design based on TCP/UPD
IHA præsentation
2
TCP/UPD: Transport services
•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
•rcv side: reassembles
segments into messages,
passes to app layer
•more than one transport protocol
available to apps
•Internet: TCP and UDP
IHA præsentation
application
transport
network
data link
physical
application
transport
network
data link
physical
3
Transport vs. network layer
•network layer: logical
communication between
hosts
•transport layer: logical
communication between
processes
•relies on, enhances,
network layer services
IHA præsentation
4
Internet transport-layer protocols
•reliable, in-order delivery: TCP
•Connection-oriented
• Handshake to setup com.
•congestion control
•flow control
•connection setup
•unreliable, unordered delivery: UDP
•connectionless
•no-frills extension of “best-effort” IP
•services not available:
application
transport
network
data link
physical
network
data link
physical
network
data link
physical
network
data link
physicalnetwork
network
data link
physical
data link
physical
network
data link
physical
application
transport
network
data link
physical
•delay guarantees
•bandwidth guarantees
IHA præsentation
5
UDP: more
•often used for streaming
multimedia apps
Length, in
•loss tolerant
bytes of UDP
•rate sensitive
segment,
•other UDP uses
•DNS
•SNMP
•reliable transfer over
UDP: add reliability at
application layer
•application-specific
error recovery!
32 bits
source port #
dest port #
length
checksum
including
header
Application
data
(message)
UDP segment format
IHA præsentation
6
UDP checksum
Goal: detect “errors” (e.g., flipped bits) in transmitted segment
Sender:
Receiver:
•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
•compute checksum of received
segment
•check if computed checksum
equals checksum field value:
•NO - error detected
•YES - no error detected. But
maybe errors nonetheless?
IHA præsentation
7
TCP: Overview
RFCs: 793, 1122, 1323, 2018, 2581
•point-to-point:
•full duplex data:
•one sender, one receiver
•bi-directional data flow in
same connection
•MSS: maximum segment
size
•reliable, in-order byte steam:
•no “message boundaries”
•pipelined:
•connection-oriented:
•TCP congestion and flow
control set window size
•handshaking (exchange of
control msgs) init’s sender,
receiver state before data
exchange
•send & receive buffers
•flow controlled:
socket
door
application
writes data
application
reads data
TCP
send buffer
TCP
receive buffer
socket
door
•sender will not overwhelm
receiver
segment
IHA præsentation
8
TCP segment structure
URG: urgent data
(generally not used)
ACK: ACK #
valid
PSH: push data now
(generally not used)
RST, SYN, FIN:
connection estab
(setup, teardown
commands)
Internet
checksum
(as in UDP)
32 bits
source port #
dest port #
sequence number
acknowledgement number
head not
UA P R S F
len used
checksum
Receive window
Urg data pnter
Options (variable length)
counting
by bytes
of data
(not segments!)
# bytes
rcvr willing
to accept
application
data
(variable length)
IHA præsentation
9
TCP seq. #’s and ACKs
Seq. #’s:
•byte stream “number”
of first byte in
segment’s data
ACKs:
•seq # of next byte
expected from other
side
•cumulative ACK
Q: how receiver handles
out-of-order segments
•A: TCP spec doesn’t
say, - up to
implementor
Host A
User
types
‘C’
Host B
host ACKs
receipt of
‘C’, echoes
back ‘C’
host ACKs
receipt
of echoed
‘C’
simple telnet scenario
IHA præsentation
time
10
Question
Suppose you want to do a transaction from a remote
client to a server as fast as possible.
Would you use UDP or TCP? Why ?
You would use UDP. With UDP, the transaction can be completed in one
roundtrip time (RTT) - the client sends the transaction request into a UDP
socket, and the server sends the reply back to the client's UDP socket. With
TCP, a minimum of two RTTs are needed - one to set-up the TCP
connection, and another for the client to send the request, and for the server
to send back the reply.
IHA præsentation
11
Socket Programming
IHA præsentation
12
Socket programming
Goal: learn how to build client/server application that communicate
using sockets
socket
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 streamoriented
IHA præsentation
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
13
Socket-programming using TCP
Socket: a door between application process and end-end-transport
protocol (UCP or TCP)
TCP service: reliable transfer of bytes from one process to another
controlled by
application
developer
controlled by
operating
system
process
process
socket
TCP with
buffers,
variables
internet
socket
TCP with
buffers,
variables
controlled by
application
developer
controlled by
operating
system
host or
server
host or
server
IHA præsentation
14
Addressing processes
•to receive messages, process
must have identifier
•host device has unique 32-bit
IP address
•Q: does IP address of host
suffice for identifying the
process?
IHA præsentation
15
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 on
host.
•Example port numbers:
•HTTP server: 80
•Mail server: 25
•to send HTTP message to
gaia.cs.umass.edu web server:
IHA præsentation
•IP address: 128.119.245.12
•Port number: 80
16
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 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)
application viewpoint
TCP provides reliable, in-order
transfer of bytes (“pipe”)
between client and server
IHA præsentation
17
Client/server socket interaction: TCP
Server (running on hostid)
Client
create socket,
port=x, for
incoming request:
welcomeSocket =
ServerSocket()
TCP
wait for incoming
connection request connection
connectionSocket =
welcomeSocket.accept()
setup
create socket,
connect to hostid, port=x
clientSocket =
Socket()
send request using
clientSocket
read request from
connectionSocket
write reply to
connectionSocket
read reply from
clientSocket
close
connectionSocket
close
clientSocket
IHA præsentation
18
Socket programming with UDP
UDP: no “connection” between
client and server
•no handshaking
•sender explicitly attaches IP
application viewpoint
address and port of destination
UDP provides unreliable transfer
to each packet
of groups of bytes (“datagrams”)
•server must extract IP address,
between client and server
port of sender from received
packet
UDP: transmitted data may be
received out of order, or lost
IHA præsentation
19
Client/server socket interaction: UDP
Server (running on hostid)
Client
create socket,
clientSocket =
DatagramSocket()
create socket,
port= x.
serverSocket =
DatagramSocket()
Create datagram with server IP and
port=x; send datagram via
clientSocket
read datagram from
serverSocket
write reply to
serverSocket
specifying
client address,
port number
read datagram from
clientSocket
close
clientSocket
IHA præsentation
20
Application Design
based on
TCP or UDP
IHA præsentation
21
Application Design
• Application Architecure to choose?
• Client-Server architecture
• Peer-to- peer architecture
• Hybrid of client-server and P2P
• What services do the application requires?
• TCP
• UDP
IHA præsentation
22
Client-server architecture
server:
•always-on host
•permanent IP address
•server farms for scaling
clients:
•communicate with server
•may be intermittently
connected
•may have dynamic IP
addresses
•do not communicate directly
with each other
client/server
IHA præsentation
23
Pure P2P architecture
•no always-on server
•arbitrary end systems directly
communicate
peer-peer
•peers are intermittently
connected and change IP
addresses
Highly scalable but difficult to
manage
IHA præsentation
24
Hybrid of client-server and P2P
Skype
• voice-over-IP P2P application
• centralized server: finding address of remote party:
• client-client connection: direct (not through server)
Instant messaging
• chatting between two users is P2P
• centralized service: client presence detection/location
• user registers its IP address with central
server when it comes online
• user contacts central server to find IP
addresses of buddies
IHA præsentation
25
Application Design
• Application Designers should be aware of:
• Silly Window Syndrome
•
IHA præsentation
26
Silly Window Syndrome
• Problem
• Sender only creates data slowly, or
• Receiver consumes data slowly.
• Example
• Packet size 5 – 10 bytes + 20 bytes (TCP Hdr) + 20 IP
Hdr => total of 45-50 bytes
• Network capacity used ineffeciently
• => adds to congestion in the network
IHA præsentation
27
Syndrome created by the sender
Nagle’s Algorithm
1. The sending TCP sends the first piece of data it receives from the
sending application even if it is only 1 byte
2. After sending the first segment, the sending TCP accumelates data in
the output buffer and waits until either the receiving TCP sends ACK or
until enough data has accumelated to fill a maximum-size segment. At
this time the sending TCP can send a segment
3. Step 2 is repeated for the rest of the transmission
IHA præsentation
28
Syndrome created by the sender
Nagle’s Algorithm Effect
•
If sending application is faster than network:
• Transmission buffer becomes full =>
• Segments are larger (maximum-size segments)
•
If network is faster than sending application:
• ACKs received before buffer is full =>
• Segments are smaller
How to enable Nagle’s Algorithm:
Socket option: TCP_NODELAY
IHA præsentation
29
Syndrome created by the receiver
1.
2.
3.
4.
5.
6.
7.
8.
9.
Sender creates data in blocks of 1kbyte
Receiver consumes data 1 byte at a time
Receiver buffer is 4 kbytes
Sender sends 4 kbytes of data
Receiver advertises a window size of zero
Sender stops sending data
Receiving application reads 1 byte
Receiving TCP announces a window size of 1 byte
Sending TCP sends 1 byte of data
Inefficient usage of network
IHA præsentation
30
Syndrome created by the receiver
Clark’s Solution
Send ACK as soon as the data arrives, but Announce a window size of zero
until either there is enough space to accommodate a segment of max. Size
or until half of the buffer is empty
Delayed Acknowledgement
Delay sending ACK. The receiver waits until there is a decent amount of
space in its incoming buffer before acknowledging the arrived segments. =>
Sender can not slid its window, and stops sending data.
What happens if we wait to long before sending ACK?
IHA præsentation
31
Question & repetition
IHA præsentation
32
Eksamen er uden forberedelse
Eksamensspørgsmål udleveres
IHA præsentation
33