User Datagram Protocol

User Datagram Protocol

Ref.: Comer, Internetworking with TCP/IP Vol.1 Chapter 12

12.1 Introduction

We have seen how IP Packets are transferred from one machine to any other machine

We now require a mechanism, which allows us to address packets to a particular destination within a machine

The mechanism must allow multiple applications within a machine to send and receive datagrams independently

12.2 Identifying the Ultimate Destination

An operating system supports multiple applications executing simultaneously

Each application executes as an independent computation or process

The ultimate destination of a datagram is therefore a process within a machine

The process ID CANNOT be used to address datagrams for four reasons:

Processes are created and destroyed dynamically, so a sender seldom

knows the PID of a particular process

Applications should be able to use any PID which the OS assigns

We should identify destination processes based on the duty they perform

rather than their PID

A particular process may be capable of handling more than one application

or function

A machine will therefore will be viewed as containing a number of abstract destinations called protocol ports

Each port is identified with a small positive integer

The OS provides a mechanism for mapping ports to processes that use them for communications

The OS provides synchronous access to ports

For a particular process this means:

Computation stops during a port access operation

Example: If a process reads from a port, the thread is blocked until data

arrives

Ports are buffered, i.e. data arriving before a process requests it are not

lost

The OS places data arriving at a protocol port into an OS port

To communicate with a foreign application, a sender needs to know both the IP address of the destination AND the protocol port number of the application at that destination

Each packet will therefore carry a destination port number and a source port number to which replies should be sent

Application

SockIO

UDP P1 P2 .. Pn

IP

Ifn 1 Ifn 2

12.3 The User Datagram Protocol

UDP defines a header which specifies destinations and source port numbers

UDP uses IP to transport datagrams

Datagrams are NOT acknowledged

No flow control or sequencing of datagrams is supported

UDP is thus (like IP) a best-effort delivery service between protocol ports

The application software accepts full responsibility for handling reliability issues

12.4 Format of UDP Datagrams

UDP datagrams are contained within the data field of an IP packet

UDP datagrams consist of a header and a data field

The header format is shown in Fig. 12.1

The CHECKSUM field is optional, if not used it is set to 0

Question: What if a computed checksum is zero ?

Recall that one's complement arithmetic has two representations of 0:

all 1's or all 0

A computed checksum of 0 therefore uses the all 1's representation of 0,

no checksum uses the all 0's representation of 0.

12.5 The UDP Pseudo-Header

The UDP checksum is calculated over the UDP header AND a pseudo-header

The pseudo-header consists of the information shown in Fig. 12.2 and is NOT actually transmitted

The pseudo-header is used to verify that a datagram has arrived at the correct destination machine

The receiver extracts the pseudo-header from the IP Header

This is a clear violation of the LAYERING PRINCIPLE but will be justified later

12.6 UDP Encapsulation and Protocol Layering

UDP is a simple Transport Protocol

It thus resides at Level 4 of the Protocol Hierarchy

Applications use UDP directly

The sole purpose of UDP is to provide the port-mapping function within machines

12.7 Layering and the UDP Checksum Computation

As noted, the UDP checksum computation violates the layering principle

There exist important reasons for this:

UDP must verify that the datagram has arrived at the correct IP address

destination (recall that a machine may have multiple IP addresses. To IP, all

of those addresses are valid)

UDP identifies datagrams based on Source IP address AND protocol port

number, UDP must therefore verify the source address too

A sending process DOES NOT KNOW IN ADVANCE over which IP interface

a datagram will leave a machine, so it cannot compute the checksum

without interacting with the IP layer

Once again, we see that the Layering Principle, if strictly applied to an implementation, results in clumsy and inefficient communications software

12.8 UDP Multiplexing, De-multiplexing, and Ports

UDP allows datagrams for multiple applications to pass over a single communications link

This feature is called MULTIPLEXING

Separating arriving datagrams for transfer to a particular application is called DEMULTIPLEXING

All multiplexing and de-multiplexing is achieved through the port mechanism

Before an application communicates, it must obtain a protocol port number from the OS

All datagrams sent by that application will leave the machine via that conceptual protocol port

At the receiving machine, all arriving datagrams are de-multiplexed on the basis of destination protocol port numbers (see Fig. 12.5)

If a datagram arrives for a protocol port number which has no application servicing it, UDP requests that an ICMP port unreachable message is sent and the datagram is discarded

12.9 UDP Port Numbers

Some port numbers are reserved for WELL KNOWN applications (see Fig. 12.6)

Other port numbers can be used for any purpose

The ECHO port (7) is used for testing reachability of the UDP software at a

particular site.

On some Operating Systems (UNIX, NT, 2000) port numbers <= 1024 are
reserved i.e. a user application cannot listen at those ports unless the user
has privilege.

The SOCKETS Interface

Ref: Comer and Stevens, Internetworking with TCP/IP Vol. 3

Chapter 5, Appendix 1 and Appendix 2

a socket is a data structure used by underlying protocol software to send and

receive packets

SOCKETS can be used to send and receive data using any available protocol

stack

we will study UDP and TCP sockets only

the details of sockets are complex due to their generality

we will study a SOCKIO library designed for TCP and UDP and documented in

the above reference

the following steps are required by a client to communicate via a UDP Socket:

create a socket using function connectUDP

write data using function sWrite or sWriteTo

read data using function sRead or sReadFrom

delete the socket using function sClose

the following steps are required by a server to communicate via a UDP Socket:

create a socket using function passiveUDP

write data using function sWrite or sWriteTo

read data using function sRead or sReadFrom

delete the socket using function sClose

all SOCKIO functions are available in the CSN Application

Note that SOCKIO functionality is available on any Windows machine, as long as
Microsoft TCP/IP is installed.

For machines with no Network Adapters:

Install a standard modem type

Install Dial-Up Networking

The CSN Application can then be run and tested on a single PC

A skeleton UDP Echo Server is shown below.

DO NOT submit this code as part of your assignment solution.

// uechod.c - uechod

#include <windows.h>

#include 'dev.h'

#include 'sockio.h'

#define BLEN 1472 // we don't want fragmentation

*

* uechod - Skeleton UDP Echo daemon (SAMPLE ONLY)

*

*-------- ----- ------ ----- ----- -----------

*/

int uechod()

A Socket Library for WINSOCK

Introduction

This sockio library for WINSOCK contains functions which simplify the programming of WIN32 networking applications. The library eliminates the tedious programming of the typical sequences required for name resolution, socket allocation, binding and connection establishment.

The sockio library contains no support for the asynchronous WINSOCK extensions. Those functions are not required under WIN32 because blocking operations can easily be run in separate threads.

Function Prototypes

All function prototypes and required data structures are contained in sockio.h.

Sample Code

The distribution contains several examples of simple UDP and TCP clients and servers. The code is documented in Comer and Stevens: Internetworking with TCP/IP Volume 3, Winsock Edition, Prentice-Hall, 1997.

Function Overview

WSinit() WINSOCK-specific, must be called once in each application.

WSclose() WINSOCK-specific, must be called before an application exits.

connectUDP(host, service) Establishes an active UDP socket. Automatically resolves host
names and services.

connectTCP(host, service) Establishes an active TCP connection. Automatically resolves host names and services.

passiveUDP(service) Establishes a passive UDP socket. Automatically resolves
services.

passiveTCP(service, qlen) Establishes a passive TCP connection. Automatically resolves services.

sAccept(s, &sa) Accepts a connection from TCP socket s.

sRead(s, buf, len) Reads from a socket.

sReadT(s, buf, len, time) Reads with a timeout of time milliseconds.

sReadFrom(s, buf, len, &sa) Reads from socket, returns address and port number in sa.

sReadFromT(s, buf, len, &sa, time) Timed sReadFrom.

sWrite(s, buf, len) Writes to a socket.

sWriteTo(s, buf, len, &sa) Writes to a socket with a specified address and port number.

sClose(s) Closes a specified socket and releases its resources.

sShutdown(s) Closes a specified TCP socket in the send direction.

wname2ip(ip, name) Resolve a DNS name

wip2name(name, ip) Find the DNS name for an IP address

wip2dot(pdot, ip) Create a dotted decimal string of ip in buffer pdot.

hl2net(long) Byte order conversion functions

hs2net(short)

net2hl(long)

net2hs(short)

Reliable Stream Transport Service (TCP)

Ref.: Comer, Internetworking with TCP/IP Vol. 1 Chapter 13

13.1 Introduction

IP provides a best-effort datagram transport service

UDP provides a best-effort port-to-port delivery service

TCP provides a reliable port-to-port delivery service

TCP provides a stream delivery service

13.2 The Need for Stream Delivery

The network provides unreliable delivery, packets may be:

lost

duplicated

delivered out of order

delivered after substantial delay

network may impose packet size constraints

Applications require reliable transfer of large amounts of data

Without TCP, applications must provide error recovery

Most application programmers do not have the technical background required to write correct protocol software of this complexity

13.3 Properties of the Reliable Delivery Service

The TCP/Application Interface has the following features:

Data is transferred as a stream (an unstructured sequence of bytes).

TCP has no notion of lines, records, packets or any other structure

A switched virtual circuit is used to transfer data. The connection must be

established, and cleared when transfer is complete

An application transfers data to TCP using whichever buffer size it finds

convenient. Even single bytes of data can be passed to the TCP interface

A receiver makes data available to an application as soon as it has been

verified

TCP can send data in any desired segment size, independent of the size of

data it receives from an application for transfer

TCP supports a push mechanism for forcing the transfer of arbitrary

amounts of data immediately

Streams are unstructured. Thus if an application sends 128 byte records to

TCP, the protocol may choose to transfer it across the network to the

receiver 1024 bytes at a time

TCP transport is full duplex

13.4 Providing Reliability

Reliability is provided through positive acknowledgement with retransmission

A further problem is duplication:

Duplication occurs when an acknowledgement for a correctly received

packet is delayed and the source retransmits the packet unnecessarily

TCP numbers each byte sent to detect this condition

13.5 Sliding Windows

The sequence shown in Fig. 13.1 is inefficient because no data is sent while the source awaits an ack

The sliding window concept is shown in Fig. 13.3

Sliding windows increase efficiency

A correctly tuned sliding window will saturate a communications link

Fig. 13.4 shows a sequence

13.6 TCP

TCP is a protocol, we will first study only the TCP specification, not its

implementation

TCP does not specify how an application interfaces to a TCP implementation

TCP can operate on a wide variety of transmission links

13.7 Ports, Connections and Endpoints

TCP ports are different to UDP ports (although the numbers mostly match)

recall that UDP ports could be thought of as queues into which the OS placed arriving datagrams

TCP also uses Protocol Ports, but connection identifiers are used to characterise a connection

Connection identifiers consist of a pair of endpoints, e.g.:

(137.92.11.54, 513) and (137.92.11.125, 2)

and

(137.92.11.54, 513) and (137.92.11.100, 5)

Note that both of the above connections could be active simultaneously

A TCP daemon can thus service multiple connections simultaneously

13.8 Passive and Active Opens

Connections must be established before use

A server contacts the OS to indicate it will accept incoming connections at some particular port (passive open)

A client contacts the OS to request a connection to some remote port (active open)

A connection request is transferred over the network to the remote site (which must have previously performed a passive open)

more details on this later

13.9 Segments, Streams and Sequence Numbers

TCP views the data stream as a sequence of bytes which is divided into segments for transmission

A segment travels across the Internet as a single IP packet

TCP uses a sliding window mechanism for error detection and flow control

The TCP sliding window operates at the byte level, not the segment level

Each byte of the data stream is numbered sequentially (from some random initial value)

The sender keeps three pointers for every connection:

pointer 1 marks the lower window edge, separating bytes which have been

sent and acked from bytes yet to be sent/acked

pointer 3 marks the upper window edge, indicating the highest byte in the

stream which can be sent before an ack must be received

pointer 2 marks the boundary inside the window that separates bytes

already sent (but not yet acked) from bytes still to be sent

the entire window slides from left to right rapidly, as network capacity allows

The receiver maintains a similar window

Each direction is independent

Four windows are maintained

13.10 Variable Window Size and Flow Control

a unique feature of TCP is that the window size may vary over time

each ack contains a window size advertisement that indicates how many additional bytes a receiver is able to accept (flow control)

in the extreme case, a window ad of 0 will stop data flow

the mechanism does not deal with network congestion, this is done at the IP layer

13.11 TCP Segment Format

The unit of transfer used by TCP software is called a segment

Segments are used to:

establish connections

transfer data

send acks

advertise window sizes

close connections

Only one segment type exists, its format is shown in Fig 13.7

The operation a segment should perform is encoded in the CODE field as shown in Fig. 13.8

13.12 Out of Band Data

Sometimes an interrupt function is required (e.g. when a long listing is being displayed)

A mechanism is required which causes the TCP receiver to accept data without first accepting other data already in its input stream

Data can be specified as urgent, which means it should be processed immediately, regardless of its position in the stream

13.13 Maximum Segment Size Option

TCP uses the OPTIONS field to negotiate a max. segment size it is willing to process

The MSS depends on the size of the receive buffers available on the machine

The MSS should be as close as possible to the MTU of the underlying network

The default MSS is 536 bytes

On an Ethernet, MSS should be negotiated to a higher value

The MSS must not be so large that fragmentation occurs anywhere along the path of the connection

Finding the optimum MSS is difficult

13.14 TCP Checksum Computation

The CHECKSUM is calculated over the entire segment and includes a pseudo header (cf. UDP)

The pseudo header lets the receiver verify that the segment reached the correct destination

13.15 Acknowledgements and Retransmission

Acks refer to the position of data in the stream

The receiver collects data from arriving segments and reconstructs an exact copy of the stream being sent

The receiver uses the sequence number to reorder data received out of order

The receiver may have the first 100 bytes, then a gap of 26 bytes, then further 200 bytes

The receiver acks only the first 100 bytes, the remaining 226 bytes will be acked when the missing 26 bytes arrive

Further details: see textbook

13.16 Timeout and Retransmission

TCP, when used over the Internet, cannot know a priori, how long a transmission will take and how long the ack will take to come back

Fig. 13.10 is a plot of Round Trip Times measured for 100 successive datagrams

TCP uses an adaptive retransmission algorithm, in which it attempts to calculate reasonable timeout intervals for changing network response times

Study Sections 13.16 - 13.19 for more details on calculating timeout intervals

13.20 Response to Congestion

Even though TCP is an end-to-end protocol, it must respond to network congestion

Retransmission aggravates congestion instead of alleviating it

Excessive retransmission leads to congestion collapse

TCP must reduce transmission rates when congestion starts to occur

TCP must increase transmission rates as congestion starts to decrease

TCP calculates its actual transmission window as:

allowed_window = min(advertisement, congestion_window)

The congestion window is halved for every segment lost

When congestion dissipates, the congestion window is increased by one for every segment acknowledged

13.21 Establishing a TCP Connection

TCP uses a three-way handshake (see Fig. 13.13)

The three-way handshake is both necessary and sufficient for correct synchronisation between the two ends of a connection

13.22 Initial Sequence Numbers

The three-way handshake allows both sides to agree on initial sequence numbers

Initial sequence numbers are chosen at random, they must not always be the same value (see Exercise 13.10)

13.23 Closing a TCP Connection

TCP uses the modified three-way handshake of Fig. 13.14 to close a connection

A connection is first closed in one direction, and then in the other direction when all data has been sent

Note that this feature means that a misbehaving application can keep connections open indefinitely (in one direction)

13.24 TCP Connection Reset

A reset is an instantaneous abort, used only when protocol errors occur

13.25 TCP State Machine

The operation of TCP is described by means of a state diagram (see Fig. 13.15)

States are shown as circles, transitions between states are shown as labelled arrows

A label shows what TCP received to make the transition and what it sends (if anything) in response

Example: In state LISTEN, if a SYN is received, a SYN with ACK is sent and the state changes to SYN RECVD

Italic labels show an operation requested by the application

Example: In state LISTEN, if a send is requested, a SYN is sent and the state changes to SYN SENT

13.26 Forcing Data Delivery

TCP normally buffers data for transmission until a segment is filled

Sometimes, it is necessary to send data even though a segment is not completely full

TCP provides a PUSH operation for this purpose

13.27 Reserved TCP Port Numbers

Fig. 13.16 gives shows some of them

Some services are available over UDP, in which case the port numbers are identical

13.28 TCP Performance

With careful implementation and efficient Ethernet Cards (not the type used in PCs), TCP can sustain 8 Mbps over a 10 Mbps Ethernet

TCP can be used over 100 Mbps networks if copying of data is avoided (See paper by Comer & Lin, March 1994)

Exercises

You should attempt all of the exercises at the end of Chapter 13.

Some are difficult, in that they require study of RFC 793 and RFC 1122 (available on the network)

Using TCP

TCP is the most widely used Internet Protocol

Examples of Application Protocols which use TCP are:

Simple Mail Transfer Protocol (SMTP)

Post Office Protocol (POP)

Hypertext Transfer Protocol (HTTP)

File Transfer Protocol (FTP)

Telnet

All of the above protocols have several common characteristics:

ASCII-coded, human-readable messages are used

because TCP ensures reliability, the above protocols are very simple

We will now briefly outline the operation of some of the above protocols

Electronic Mail

The email paradigm is an extension of the traditional office memo

an email address consists of two parts:

a mailbox identifier

host name

example: user@ise.canberra.edu.au

an email message consists of a header, one blank line, followed by the message

body

the body can contain arbitrary text

the header consists of several lines, each line has the following format:

keyword: text

Some keywords are:

From sender's address

To recipients' address

Cc addresses for carbon copies

Date date on which message was sent

Subject topic of the message

Reply-To address to which reply should go

SMTP

a TCP connection to Port 25 on the destination host is established

the following sign-on message will be received

220 xinu.canberra.edu.au Sendmail 4.1/SMI-4.1 ready at Mon, 9 May 94 21:58:35 EST

a dialog like the following occurs (each line is terminated with CR LF):

Send: mail from: csn_student@isepc29

Recv: 250 postmaster Sender ok

Send: rcpt to: chrisc

Recv: 250 chrisc Recipient ok

Send: data

Recv: 354 Enter mail, end with '.' on a line by itself

Send: Subject: I love networking

Send: .

Recv: 250 Mail accepted

Send: quit

Recv: 221 xinu.canberra.edu.au delivering mail

the connection is then closed

SMTP is only used to send email to the recipient's machine

A user wishing to fetch email from a machine on which he/she has an account

can use the Post Office Protocol

POP is used to transfer email from one machine for reading on another machine

POP is described in RFC1225
HTTP 1.0

defines how WEB pages are requested and transferred over the Internet

specified in RFC1945

a client (browser) opens a TCP connection to Port 80

the client then issues a command such as the following:

GET /welcome.html HTTP/1.0 [return]

the server then sends the document /welcome.html and closes the

connection

another example:

HEAD /welcome.html HTTP/1.0

HTTP/1.0 200 OK

Date: Fri, 10 October 1997 04:48:52 GMT

Server: Apache/1.1.1 UKWeb/1.0

Content-type: text/html

Content-length: 3406

Last-modified: Fri, 09 Aug 1997 14:21:40 GMT

the server then closes the connection without sending the document

many commands exist, see the RFC for details Using the Sockio Library

// c_techod.cpp - c_techod

#include <string.h>

#include 'dev.h'

#include 'sockio.h'

extern 'C'

// wait for Connection Requests

while (1)

xprintf('[%u.%u.%u.%u] ',

from.sin_addr[0],

from.sin_addr[1],

from.sin_addr[2],

from.sin_addr[3]);

while (1)

}

return SYSERR;

use the above code as a starting point for Assignment 3

use the following version of cmd.c

// cmd.c - initialise the command table

#include <windows.h>

#include 'dev.h'

#include 'cmd.h'

extern int

c_echo(int, char **),

c_exit(int, char **),

c_help(int, char **),

c_httpd(int, char **),

c_kill(int, char **),

c_ps(int, char **),

c_sleep(int, char **),

c_techo(int, char **),

c_techod(int, char **),

c_terminate(int, char **),

c_test(int,char **),

c_uecho(int, char **),

c_uechod(int, char **);

struct cmdent cmds[] = ;

int ncmds = sizeof(cmds)/sizeof(struct cmdent);

rebuild csn.exe, run it, and then run the echo daemon as:

techod &

Note that it will never terminate, as is usual for daemons (they run forever)

Start a second instance of csn.exe on the same or different machine and then use command:

techo machine_name

where machine_name is either 'localhost', the DNS name of the machine running the daemon, or the IP address of that machine.

You can determine the IP address of a machine by examining its routing table.

You can determine the DNS name of a machine by typing:

ping -a x.x.x.x

The techo command should send each line of text entered to the echo daemon.

An empty line of text should terminate the command.