13 - layer 4€¦ · lehrstuhl für informatik 4 kommunikation und verteilte systeme chapter 3.5:...

Lehrstuhl für Informatik 4

Kommunikation und verteilte Systeme

Chapter 3.5: TCP and UDP

Layer 4 - Transport Layer

Core of the protocol hierarchy:

• Network-independent, reliable and economical data transfer

Tasks of the transport layer:

• Connection-oriented or connectionless data transfer

• Addressing of a certain communication process on a computer

• Error detection, error correction

• Flow control

• Multiplexing

1. Upward - several transport connections to one network connection

2. Downward - one transport connection to several network connections (e.g. if not sufficient capacity of a network connection is given)

• Weak quality guarantees: reliability




What do we need a Transport Layer for?

Is layer 4 redundant?

No, because:• The network layer belongs to the network carrier:

A user does not have any control over network details and problems

• Hiding of technical details from higher layers• Addressing of a destination process

• End-to-end view of a data flow• Generally: Improvement of the quality of the data communication on layer 3

Similarity to layer 3:

• Connection-oriented and connectionless data transmission (The Internet layer in connectionless, but in general layer 3 also could be connection-oriented)

• Addressing

• Flow control




TCP (Transmission Control Protocol): Reliable, connection-oriented.

UDP (User Datagram Protocol): Datagram principle, connectionless, unreliable, without flow control, permutation of a packet order can happen.

Connection-oriented Connectionless

ApplicationLayer

TransportLayer

InternetLayer

Host-to-NetworkLayer

Wireless LANEthernet Token Ring Token Bus

FTP Telnet SMTP DNS SNMP TFTPHTTP

UDPTCP

ICMP IP RARPARPIGMP

Transport Protocols in the TCP/IP Reference Model




• Transport protocols are used by the application layer as communication services. They make communication available between application processes.

• UDP is a connectionless and fast protocol• TCP is a connection-oriented and reliable protocol

→ virtual connections only, using the connectionless IP for transmitting data

IP network

A

B

Client process

Server process

The Transport Layer – TCP and UDP




• Connection-oriented and reliable (error-free, keeps packet order, without duplicates)

• Error handling, acknowledgments, flow control (Sliding Window procedure)• Byte stream, not message stream• Segmentation (max. segment size of 64 KByte)

• “Urgent”-messages outside of flow control• Limited QoS

• Addressing of the application by port numbers

Characteristics of TCP

Host-to-network layer

Network layer

Transport layer

Application layerClient Server1Port number

IP address

Server waits on several ports

Server2




Well known TCP ports

20/21 23 25 80 179

FTP telnet

Electronic Mail

SMTP HTTP BGP

File transferWorld Wide Web

Virtual terminalRouting information

1023

RFC 1700

• Port number is 16-bit address

• Ports from 0 to 1023 are reserved for standardized applications

• Ports from 1024 to 65535 can be specified by each host

Port Numbers for TCP-based Applications




TCP as a Safe Connection

• Establishes logical connections between two Sockets: IP address + 16 bit port number (48 bit address information)

• For an application, sockets are the access point to the network

• A socket can be used for several connections at the same time

• TCP connections are always full-duplex and point-to-point connections

• TPDUs exchanged between the two communicating stations are called segments

• Segments are being exchanged for realizing

� Connection establishment,� Data transmission,

� Sending of confirmations,� Connection termination.

For simplicity: only one header format defined for all segments – the task of a segment is marked by special flags




Connection-orientation of TCP

“Connection-oriented” classically means “use a determined connection (path) to send all data packets”

• But: TCP sits on top of the connectionless IP and has no influence on the chosen path

• Thus: TCP in principal transfers the data connectionless, but adds control information in its header for appearing connection-oriented to higher-layer protocols

Simple idea:• Like on layer 2, number all segments before transmission• On receiver side, check the stream of segments on completeness and correct

order• Re-transmit missing segments




The TCP Header

• 20 byte “default” header

• Plus options

• Up to 65495 data bytes

Source Port Destination Port

Data

0 16 24 31Bit position

8

PaddingOptions

Checksum Urgent Pointer

Window Size6 FlagsHL Res.

Acknowledgement Number

Sequence Number




• Source and Destination Port: port number of sender resp. receiver• Sequence Number/Acknowledgment Number: Segments have a 32 bit sequence

and acknowledgement number for the window mechanism in flow control (Sliding Window).

• Sequence and acknowledgement number count single bytes!• The acknowledgement number indicates the next expected byte!

• Sequence numbers begin not necessarily with 0! A random value is chosen here to avoid a possible mix-up of segments for a new connection with old segments from the last connection which could maybe arrive late.

• Piggybacking, i.e. an acknowledgement can be sent in a data segment.

• HL: As in case of IP, also the TCP header has an indication of its length. The length is counted in 32-bit words.

• Res = Reserved for later use.• Window Size: Size of the receiver’s buffer for the connection. Used in flow control:

the window of a flow indicates, how many bytes at the same time can be sent – the size of the buffer indicates, how many bytes can be stored within the receiver. The window of flow control is adapted to this value.

The TCP Header




• Flags:� URG (URGENT): When this flag is set the field “urgent pointer” becomes valid,

to submit important data immediately even if flow control would not allow for.

� ACK: This bit is set, if an acknowledgement is sent.� PSH (PUSH): Immediate forwarding of the data, no more waiting for further

data (i.e. immediate transmission on sender side, immediate processing on receiver side without long buffering).

� RST (RESET): Reset a connection, e.g. during a host crash or a connecting rejection. The connection immediately is termindated.

� SYN (Synchronize): set to 1 for the establishment of a connection.� FIN (Final): set to 1 for the termination of a connection.

• Urgent pointer: indicates, at which position in the data field the urgent data end (byte offset of the current sequence number).

• Option: additional functions: negotiation of a window scale; use of e.g. Selective Repeat instead of Go-Back-n in the event of an error; Indication of the Maximum Segment Size (MSS) to determine the size of the data field.

The TCP Header




Source address (IP)

Destination address (IP)

The checksum is computed using a pseudo header. The pseudo header is placed in front of the TCP header, the checksum is computed from both headers (the checksum field is occupied here with 0). The checksum is computed as the 1-complement of the sum of all 16-bit words of the segment including the pseudo header. The receiver also places the pseudo header in front of the received TCP header and executes the same algorithm (the result must be 0).

Length of the TCP segmentProtocol = 600000000

• Checksum: serves among other things for the verification that the packet was delivered to the correct device.

TCP Pseudo Header

Now: how are connection establishment, reliable data transmission, and connection termination implemented in TCP?




Sounds easy…

… is however nevertheless quite complicated: the network can lose packets, store packets, duplicate packets.

Solution:• Sequence numbers• Three-Way Handshake

A connection establishment consists of three parts:� The Connection Request (CR),

� The confirmation of the receiver that the connection establishment is accepted,

� The confirmation of the sender that the confirmation of the receiver was received and the sending request is still given.

A compromise between reliability and complexity is to be obtained by this principle.

• Two variants of this procedure are implemented in TCP

REJECT (ACK=y)

ACK (seq=y, ACK=x)

ACK (seq=x+1, ACK=y)

Host 1 Host 2

CR (seq=x)

Host 1 Host 2

CR (seq=x)

ACK (seq=y, ACK=x)

Duplicate

Connection Establishment




1. Regular TCP Connection Establishment

Server

SYN, SEQ-No=x

SYN, ACK, SEQ-No=y,

ACK-No=x+1

Client

ACK, ACK-No=y+1, SEQ-No=x+1

• The server has to run and wait for connection requests on a certain port.

• The client connects by with a segment indicating the destination port, initial sequence number (x), and having set the SYN flag to 1 (to indicate that a new connection is to be established).

• The connection is accepted on server side if the destination port is identical to the one the server waits on, and if the server has enough resources (buffer space) for a new connection. Otherwise it is rejected (set RST flag).

• The server sends back a segment with set SYN flag to the client, and acknowledges at the same time the receipt of the client’s SYN segment (with ACK-No=x+1). Also, an own initial number is passed to the client (y).

• The client sends an acknowledgement for the SYN segment of the server (ACK-No=y+1). The connection is established.

ACK-No = acknowledgement numberSEQ-No = sequence numberThe ACK-No value only is valid if the ACK flag is set to 1!




SYN, SEQ-No=x

SYN, SEQ-No=y

Client/Server Client/Server

SYN, ACK, SEQ-No=x, ACK-No=y+1

SYN, ACK, SEQ-No=y,

ACK-No=x+1

• Maybe, two computers at the same time try to establish a connection to each other

• Connections are characterized by their endpoints; only one connection is established between a pair of endpoints. The endpoints are uniquely characterized:

(IP Address1, Port1, IP Address2, Port2)

2. Irregular TCP Connection Establishment




SEQ=101, ACK=201, DATA 10 Byte

SEQ=201, ACK=111

SEQ=111, ACK=201, DATA 50 Byte

SEQ=201, ACK=161

Client Server

• Full-duplex connection

• Segmentation of a byte stream into segments. Usual sizes are 1500, 536 or 512 byte; thus IP fragmentation is avoided.

• Usual acknowledgement mechanism: all segments up to ACK-1 are confirmed. If the sender has a timeout before an ACK, he repeats the segment.

• To be more efficient: sliding window mechanism

• Usual procedure for repeating: Go-Back-N or Selective Repeat.

Data Transmission

After connection establishment, all data is transferred in segments:




Initial window

Window slides

3 bytes acknowledged

1 2 3 4 5 6 7 8 9 10

• The window size counts transmitted bytes (instead as frames as on layer 2)

• Window is shifted by n byte as soon as an ACK for n byte arrives

• Exception: Urgent data (URGENT flag is set) is sent immediately

• Characteristic: the window size can be changed during the transmission phase! Why?

� Segments have to be buffered to allow a sorting of out-of-order segments

� Segments are buffered till the receiving application process is able to process them

� Variable number of connections can exists, all sharing the same buffer

Flow Control – Sliding Window

To provide reliable data transfer, as on layer 2 a sliding window mechanism is used. Differences:

1 2 3 4 5 6 7 8 9 10




A waits for buffer space

B waits that A sends dataDanger of deadlock; send control segments in regular time intervals

Dynamic Buffer Assignment

B informs A about 4 buffer places←<ack = 6, buf = 4>16

A sends segment 6; A is blocked (no more buffer)→<seq = 6, data = byte7>→14

B acknowledges segments 5+6, but sender remains blocked←<ack = 6, buf = 0>←15

B informs A about 1 buffer place←<ack = 4, buf = 1>←11

B acknowledges segments 2 - 4 – sender is stopped (no buffer)←<ack = 4, buf = 0>←10

B informs A about 2 buffer places←<ack = 4, buf = 2>←12

A sends segment 5→<seq = 5, data = byte6>→13

A sends segment 0 (only 1 byte per segment, for simplicity)→<seq = 0, data = byte1>→3


A sends segment 2, segment is lost<seq = 2, data = byte3>→5

B ack’s segments 0 and 1, buffer places are reduced to 3←<ack = 1, buf = 3>←6



A repeats segment 2→<seq = 2, data = byte3>→9

B grants 4 buffer places for A and waits for segment 0←<ack = 15, buf = 4>←2

A asks for 8 places in B’s buffer (8 bytes)→<request 8 buffers>→1

BMessageAack/seq ∈{0, …, 15}

Timeout for segment 2 }




Dynamic Sliding Window - Example

Sender ReceiverApplication writes 2 KB

2K SEQ = 0

Receiver buffer

Empty

0 4K

ACK=2048 WIN=2048

2K SEQ = 2048

ACK=4096 WIN=0

ACK=4096 WIN=2048

1K SEQ = 4096

Full

Application writes 2 KB

Sender can transfer up to 2 KB

Sender is blocked

2K

2K

2K1K

Application reads 2 KB




Solution of Clark:The receiver must wait with the next window actualization until the receiver buffer again is reasonably empty

Receiver buffer is full

Application reads 1 byte

Space for 1 byte

Transfer segment for window actualization

New byte arrives

Receiver buffer is full

Header

1 byte

Header

“Silly Window” Syndrome




TCP Connection Termination

FIN, SEQ-No=x, ACK-No=y

ACK, SEQ-No=y, ACK-No=x+1

ACK, SEQ-No=x+1, ACK-No=y+1

Client Server

• Termination as two simplex connections

• Send a segment with set FIN flag

• If the FIN-segment is confirmed, the corresponding direction is “switched off”. The opposite direction remains however still opened, data can still be sent. The same procedure as above is to be repeated

• Use of timers to protect against data loss

FIN, SEQ-No=y, ACK-No=x+1




To protect against data loss, timers are used – otherwise, if one machine crashes during termination, the other one would wait “forever”before releasing reserved resources

Host 1 Host 2

FIN

FIN, ACK

ACK

send FIN and start

timer

send FIN and start

timer

terminate connection


send confirmation

Host 1 Host 2

FIN

FIN, ACK

ACK

send FIN and start

timer

send FIN and start

timer

Timeout



ACK

FIN

FIN,

ACK

send FIN and start

timer

send FIN and start

timer



Timeout

send FIN and start

timerFIN

send FIN and start

timerFIN, ACK

FIN

FIN,

ACK

send FIN and start

timer

send FIN and start

timer

Timeout


N Timeouts


Timeout

send FIN and start

timer

FIN

::

FIN

FIN

Connection Termination Timers

send confirmation

send confirmation




Normal path of server Normal path of client

Unusualevents

Event/action pair

• Event: System call by user, arrival of segment, timeout

• Action: Send a control segment

The Entire TCP Connection




States during a TCP Session

Wait for late packetsLAST ACK

The other side initiates a connection terminationCLOSE WAIT

Connection terminationCLOSING

Wait for late packetsTIME WAIT

The other side confirms the connection terminationFIN WAIT 2

Application starts a connection terminationFIN WAIT 1

Connection established, transmit dataESTABLISHED

Application began to open a connectionSYN SENT

A connection request was received and processed, wait for the last ACK of the connection establishment

SYN RCVD

The server waits for a connection requestLISTEN

No active communicationsCLOSED

DescriptionState




Persistence timer

• Prevents a deadlock with a loss of the buffer release message of a receiver

• With expiration of the timer, the sender transfers a test segment. The response to this transmission contains the current buffer size of the receiver. If it is still zero, the timer is started again.

Keep-alive timer

• If a connection is inactive for a longer time, at expiration of the timer it is examined whether the other side is still living

• If no response is given, the connection is terminated

• Disputed function

Time Wait timer

• During the termination of a connection, the timer runs for the double packet life time to be sure that no more late packets arrive

Used Timers




The Entire TCP Connection – Example

ServerClientSYN/SEQ=2999/ACK=x/Window=2500/MSS=1460

SYN, ACK/SEQ=2000/ACK=3000/Window=4200/MSS=1400ACK/SEQ=3000/ACK=2001/Window=2500

DATA 1400 byte/SEQ=3000/ACK=2001/Window=2500



ACK/SEQ=2001/ACK=4400/Window=4200



DATA 1400 byte/SEQ=7000/ACK=2001/Window=2500DATA 1400 byte/SEQ=8400/ACK=2001/Window=2500



FIN, ACK/SEQ=9800/ACK=2001

FIN, ACK/SEQ=2001/ACK=9801ACK/SEQ=9801/ACK=2002




Capacity of the receiver:Flow Control Window (Buffer)

Capacity of the network:Congestion Window

Flow Control - Network Bottlenecks

Next problem: when sending as much data as the receiver allows, the network can get overloaded

Necessary: Congestion Control (by using a second transmission window)

Assumption: packet loss is rarely because of transmission errors, rather because of overload situations




Control Algorithm in the Internet

• Each sender maintains two windows for the number of bytes which can be sent:

1. Flow Control Window: granted receiver buffer

2. Congestion Window: “network granted” capacity (cwnd)

• Minimum of both windows is the number of bytes which can be sent maximally

• With connection establishment, the sender initializes the congestion window to the size of the maximum segment (MSS, the MTU the sender is able to send)

• Maximum segment is sent

• If an acknowledgement arrives before timeout, double the congestion window (Slow Start Algorithm), otherwise reset it to the initial value. Thus a “grope” takes place up to the transmission capacity.

• Enlargement stops with reaching the flow control window

• Refinement by introduction of a threshold value ssthresh (at the beginning 64 Kbyte):

- Only linear enlargement by one maximum segment size (Congestion Avoidance)

- With a timeout the threshold value is put back to half of the maximum window size reached before




Control Algorithm in the Internet

Start with one segment

Slow start, fast utilization of the free capacity

Congestion Avoidance, groping to the maximum capacity

Overload assumed, reduce the data amount

Be more careful in the next attempt




Fast Retransmit and Fast Recovery

Slow Start is not well suited when only a single packet is lost…

Fast Retransmit• The receiver should send a duplicate ACK immediately when an out-of-order

segment arrives

• When the sender has received 3 duplicate ACKs, it performs a retransmission of the segment which seems to be missing. Hopefully, the acknowledgement for the repeated segment arrives before a timeout for this segment occurs.

Fast Recovery• When the third ACK is received, reduce ssthresh to max(current size/2, 2*MSS)• Retransmit the missing segment, set cwnd to ssthresh + 3*MSS

• For each more duplicated ACK, increment cwnd by MSS• This reduces cwnd by the amount of lost segments to adapt to the network

situation

• If the new cwnd (and the receiver’s buffer) allows, send a segment• When the next (normal) ACK arrives, set cwnd to ssthresh to go on normally

Fast Retransmit has to be enhanced to be useful in overload situations…




TCP uses several timers:

• Retransmission timer (for repeating a transmission)• But: how to select the timer value?• Probability density of the time till an acknowledgement arrives:

10 20 30 40 500

0.1

0.2

0.3

Wah

rsch

ein

lich

keit

Roundtrip-Time [ms]

Data Link Layer

10 20 30 40 500

0.1

0.2

0.3

Wah

rsch

ein

lich

keit

Roundtrip-Time [ms]

Transport Layer

T T2T1

Problem on the transport layer:

• T1 is too small: too many retransmissions

• T2 is too large: inefficient for actual packet loss

Timer Management with TCPP

rob

abili

ty

Pro

bab

ility

Round Trip Time [ms] Round Trip Time [ms]




Only meaningful solution: dynamic algorithm, which can adapt the timer by current measurements of the network performance.

Algorithm of Jacobson (1988):

• TCP manages a variable RTT (Round Trip Time) for each connection

• RTT is the momentarily best estimation of the round trip time to the target computer and back

• When sending a segment, a timer started which measures, which time the acknowledgement needs and initiates a retransmission if necessary.

• If the acknowledgement arrives before expiration of the timer (after a time unit t), RTT is updated:

RTT = α • RTT + (1 - α) • t

• α is a smoothing factor, typically 0.875

• The choice of the timeout is based on RTT: Timeout = β • RTT

• At the beginning, β was chose as 2, but this was too inflexible

Retransmission Timer




• Improvement (Jacobsson): select β proportionally to the standard deviation of the arrival time of acknowledgements

• Computation of β:

β = α • β + (1 - α) • |RTT - t|

• The factor α does not need to be the same as during the RTT computation

• Standard timeout interval: Timeout = RTT + 4 • β

• The factor 4 was determined on the one hand by trying out, on the other hand because it is fast and simple to use in computations.

Alternative, very simple proposal, which is used in most TCP implementations:

• Double the timeout as long as an acknowledgement arrives in time.

Retransmission Timer




Working with TCP

Server side

• The receiving application process (server) has to run at first

• The server provides a socket over which connection requests are received (i.e. a port is made available)

• In order to be able to receive requests of several clients, the server provides a new socket for a connection request of each client

Client side

• The client generates a socket

• The client creates a request with IP address and port of the server

• When the client creates its socket, a connection establishment to the server is made




Socket Primitives in TCP

Release of the connectionCLOSE

Receive data on the connectionRECEIVE

Send data over the connectionSEND

Attempt of a connection establishmentCONNECT

Accept a connecting requestACCEPT

Wait for arriving connecting requestsLISTEN

Assign a local address with the socketBIND

Creation of a new network access pointSOCKET

MeaningPrimitively

For communication via TCP, a set of primitives exists which an application programmer can use for initializing and carrying out a communication. The essential primitives are:




Socket Programming in TCP

wait for incomingconnection requestconnectionSocket =welcomeSocket.accept ()

create socket,port=x, forincoming request:welcomeSocket =

ServerSocket () create socket,

connect to hostid, port=xclientSocket =

Socket ()

closeconnectionSocket

read reply fromclientSocket

closeclientSocket

Server (on host hostid) Client

send request usingclientSocketread request from

connectionSocket

write reply toconnectionSocket

TCPConnection establishment




Example: Java Client (TCP)

import java.io.*;import java.net.*;class TCPClient {

public static void main(string argv[]) throws Exception{

String sentence;String modifiedSentence;BufferedReader inFromUser =new BufferedReader(new InputStreamReader(System.in));

Socket clientSocket = new Socket(“hostname”, 6789);

DataOutputStream outToServer =new DataOutputStream(clientSocket.getOutputStream ());

Buffers for user input are provided

Create client socket, establish connection

Create data stream for the socket

CONNECT




Example: Java Client (TCP)

BufferedReader inFromServer = new BufferedReader(newInputStreamReader(clientSocket.getInputStream()));

sentence = inFromUser.readLine();

outToServer.writeBytes(sentence + “\ n”);

modifiedSentence = inFromServer.readLine();

System.out.println(“FROM SERVER: ” + modifiedSentence);

clientSocket.close();

} }

Create data streamfrom the socket

Send to server

Receive from server

SEND

RECEIVE




Example: Java Server (TCP)

import java.io.*; import java.net.*;

class TCPServer {

public static void main(string arg []) throws Exception {

String clientSentence; String capitalizedSentence;

ServerSocket welcomeSocket = new ServerSocket(6789);

while (true) {

Socket connectionSocket = welcomeSocket.accept();

BufferedReader inFromClient = new BufferedReader(newInputStreamReader(connectionSocket.getInputStream()));

Provide default socket on port 6789

Wait for incoming connection requests

Link buffer with the socket

LISTEN

BIND




Example: Java Server (TCP)

DataOutputStream outToClient = newDataOutputStream(connectionSocket.getOutputStream());

clientSentence = inFromClient.readLine();

capitalizedSentence = clientSentence.toUpperCase() + “\ n”;

outToClient.writeBytes(capitalizedSentence); }

} }

Read from socket

Link outgoing data stream with the socket

Write on socket

Go back, wait on next request

SEND

RECEIVE




The User Datagram Protocol (UDP)

Alternative to TCP; principle: “Keep it simple!”

• 8 byte header

• Like IP: connectionless and unreliable• Small reliability, but fast exchange of information

• Used for fast data transfer, and for transfer of only short messages (to avoid the connection establishment overhead)

• No acknowledgement of packets on the UDP layer, incorrect packets simply are discarded. Duplication, sequence order permutation, and packet loss are possible.

• The checksum offers the only possibility of testing the packets on transfer errors

• Possible: ACKs and retransmissions are controlled by the application.• Use in multicast (not possible with TCP)

Why at all a protocol if no function is implemented?

→ Only the addition of a port to a network address marks communication clearly.




• Addressing of the applications by port numbers• Message length indicates the overall length (header + data) in 32-bit words

• Checksum (optional!) – IP does not have a checksum for the data part, therefore it can be a meaningful addition here. Execution of the computation as for TCP

• Data are filled up if necessary to an even byte number (because Message Length is indicated in 32-bit words)

Source Port Destination Port

Message Length Checksum

Data

0 8 16 24 31Bit Positon

UDP Header




Well known UDP ports (up to 1023)

53 67/68 69 161/162 520

DNS BOOTP

File Transfer

TFTP SNMP RIP

Name serviceNetwork Management

Automatic Address AssignmentRouting Information

UDP-based Applications




Socket Programming with UDP

closeclientSocket

Server (on host hostid)

read reply fromclientSocket

create socket,clientSocket =DatagramSocket()

Client

Create, address (hostid, port=x),send datagram request using clientSocket

create socket,port=x, forincoming request:serverSocket =DatagramSocket()

read request fromserverSocket

write reply toserverSocketspecifying clienthost address,port number




Example: Java Client (UDP)


class UDPClient { public static void main(String arg []) throws Exception {

BufferedReader inFromUser = new BufferedReader(new InputStreamReader(System.in));

DatagramSocket clientSocket = new DatagramSocket();

InetAddress IPAddress = InetAddress.getByName(“hostname”);

byte[] sendData = new byte[1024]; byte[] receiveData = new byte[1024];

String sentence = inFromUser.readLine(); sendData = sentence.getBytes ();

Provide buffer for input data stream

Create client socket

Translate hostname into IP address




Example: Java Client (UDP)

DatagramPacket send-pack = new DatagramPacket(sendData, sendData.length, IPAddress, 9876);

clientSocket.send(send-pack);

DatagramPacket receivePacket = new DatagramPacket(receiveData, receiveData.length);

clientSocket.receive(receivePacket);

String modifiedSentence = new String(receivePacket.getData());

System.out.println(“FROM SERVER:” + modifiedSentence); clientSocket.close(); }

}

Create datagram

Send datagram

Read datagram from the server




Example: Java Server (UDP)


class UDPServer { public static void main(String args[]) throws Exception

{

DatagramSocket serverSocket = new DatagramSocket(9876);

byte[] receiveData = new byte[1024]; byte[] sendData = new byte[1024];

while (true) {

DatagramPacket receivePacket = new DatagramPacket(receiveData, receiveData.length);

serverSocket.receive(receivePacket);

Create datagram socket

Reserve buffer for received datagrams

Receive datagram




Example: Java Server (UDP)

String sentence = new String(receivePacket.getData());

InetAddress IPAddress = receivePacket.getAddress();

int port = receivePacket.getPort();

String capitalizedSentence = sentence.toUpperCase();

sendData = capitalizedSentence.getBytes();

DatagramPacket sendPacket = new DatagramPacket(sendData, sendData.length, IPAddress, port);

serverSocket.send(sendPacket); }

} }

Get IP address and port of the client

Write datagram to socket

Wait for the next datagram

Create datagram for the client




Layer 4 Conclusion

• TCP is used by most application layer protocols (web pages, file transfer, e-mail, …), UDP is used if the connection establishment causes too much overhead (network management, name service, …)

• If speed is important, also UDP is to be preferred (nevertheless, for Internet radio, implementations for both protocols exist)

• Also further layer 4 protocols were developed but have not become prominent except RTP:

� RTP sits on top of UDP (still a layer 4 protocol)� Adds no control functionality

� Adds additional header information for providing information like sequence numbers

� Applications can use of RTP to make use of these information forimplementing own control functionality

� Thus, using RTP allows an application for a trade-off between speed and reliability




Implementation Example

In the following: exemplarily implementation of a simplified TCP-like transport protocol, which covers the following segment types:

Control data for the management of the window sizeCREDIT

Data transmissionDATA

Answer to CLEAR REQUESTCLEAR CONFIRMATION

Attempt of a connection terminationCLEAR REQUEST

Answer to CALL REQUESTCALL ACCEPTED

Attempt of a connection establishmentCALL REQUEST

MeaningTPDU





A connection can have one of the following states:

• Idle – no connection is established.

• Waiting – a CONNECT took place, CALL REQUEST is sent.

• Queued – the CALL REQUEST was received but not yet processed.

• Established – connection establishment finished.

• Sending – wait for transmission permission.

• Receiving – the receiver executed a RECEIVE.

• Disconnecting – local call of DISCONNECT.




Representation of the protocol as finite state machine





Representation of protocol as finite State Machine (graphical form)

13 - layer 4€¦ · lehrstuhl für informatik 4 kommunikation und verteilte systeme chapter 3.5:...

Documents