1

6B22BCA E08 NETWORK PROGRAMMING

MODULE 1
1.Introduction
When writing programs that communicate across a computer network, one must first invent a
protocol. Protocol means an agreement on how those programs will communicate.For example, a Webserver
is typically thought of as a long-running program that sends networkmessages only in response to requests
coming in from the network. The other side of theprotocol is a Web client, such as a browser, which always
initiates communication with theserver.

Figure : Network application: client and server.

Clients normally communicate with one server at a time, although using a Web browser as anexample,
we might communicate with many different Web servers over, say, a 10-minute timeperiod. But from the
server's perspective, at any given point in time, it is not unusual for aserver to be communicating with multiple
clients.

Figure : Server handling multiple clients at the same time.

The client application and the server application may be thought of as communicating via anetwork
protocol, but actually, multiple layers of network protocols are typically involved. Here we focus on the
TCP/IP protocol suite, also called the Internet protocol suite. Forexample, Web clients and servers
communicate using the Transmission Control Protocol, orTCP. TCP, in turn, uses the Internet Protocol, or
IP, and IP communicates with a datalink layerof some form. If the client and server are on the same
Ethernet, we would have the following arrangements.

Figure : Client and server on the same Ethernet communicatingusing TCP.

Even though the client and server communicate using an application protocol, the transportlayers
communicate using TCP. Note that the actual flow of information between the client andserver goes down
the protocol stack on one side, across the network, and up the protocol stackon the other side. Also note that
the client and server are typically user processes, while theTCP and IP protocols are normally part of the
protocol stack within the kernel.
The client and server need not be attached to the same local area network (LAN) as we showin the
above figure. For instance, in the following figure we show the client and server on different LANs,
withboth LANs connected to a wide area network (WAN) using router

Figure : Client and server on different LANs connected through aWAN.

2.A Simple Daytime Client

The day time protocol is a service in the Internet Protocol suite, defined in RFC 867.It is for testing
and measurement purpose in computer networks. RFC specifies a standard for the ARPA Internet
Community.
The following figure is an implementation of a TCP time-of-day client.This client establishes a TCP
connection with a server and the server simply sends back thecurrent time and date in a human-readable
format.
1 #include unp.h
2 int
3 main(intargc, char *argv)
4{
5 intsockfd,n;
6 char recvline[MAXLINE+1];
7 structsockaddr_inservaddr;
8 if(argc!=2)
9 err_quit(usage: a.out<IPaddress>);
10 if((sockfd=socket(AF_INET,SOCK_STREAM,0))<0)
11 err_sys(socket error);
12 bzero(&servaddr, sizeof(servaddr));
13 servaddr.sin_family = AF_INET;
14 servaddr.sin_port = htons(13); /* daytime server */
15 if (inet_pton(AF_INET, argv[1], &servaddr.sin_addr) <= 0)
16 err_quit("inet_pton error for %s", argv[1]);
17 if (connect(sockfd, (SA *) &servaddr, sizeof(servaddr)) < 0)
18 err_sys("connect error");
19 while ( (n = read(sockfd, recvline, MAXLINE)) > 0) {
20 recvline[n]=0;
21 if(fputs(recvline,stdout)==EOF)
22 err_sys(fputs error);
23 }
24 if(n<0)
25 err_sys(read error);
26 exit(0);
27 }
Figure : TCP daytime client.

If we compile the program into the default a.out file and execute it, we will have the
followingoutput:
solaris % a.out 206.168.112.96our input
Mon May 26 20:58:40 2003the program's output

There are many details to consider in this 27-line program.

Include our own header

1:We include our own header, unp.h. This header includesnumerous system headers that are needed
by most network programs and defines variousconstants that we use (e.g., MAXLINE).
Command line arguments
23:This is the definition of the main function along with the command-line arguments. Wehave
written the code is assuming an American National Standards Institute (ANSI) Ccompiler (also referred to
as an ISO C compiler).
Create TCP socket
1011:The socket function creates an Internet (AF_INET) stream (SOCK_STREAM) socket,
whichis a fancy name for a TCP socket. The function returns a small integer descriptor that we canuse to
identify the socket in all future function calls (e.g., the calls to connect and read thatfollow).
If the call to socket fails, we abort the program by calling our own err_sys function. It printsour error
message along with a description of the system error that occurred (e.g., "Protocolnot supported" is one
possible error from socket) and terminates the process.
Specify server's IP address and port
1216:We fill in an Internet socket address structure (a sockaddr_in structure namedservaddr) with
the server's IP address and port number. We set the entire structure to 0 usingbzero, set the address family to
AF_INET, set the port number to 13 (which is the well-knownport of the daytime server on any TCP/IP host
that supports this service), and set the IP address to the value specified as the first command-line
argument(argv[1]). The IP address and port number fields in this structure must be in specific formats:We
call the library function htons ("host to network short") to convert the binary port number,and we call the
library function inet_pton ("presentation to numeric") to convert the ASCIIcommand-line argument (such as
206.62.226.35 when we ran this example) into the properformat.
Establish connection with server
1718:The connect function, when applied to a TCP socket, establishes a TCP connection withthe
server specified by the socket address structure pointed to by the second argument. Wemust also specify the
length of the socket address structure as the third argument to connect,and for Internet socket address
structures, we always let the compiler calculate the lengthusing C's sizeof operator.
Read and display server's reply
1925:We read the server's reply and display the result using the standard I/O fputs function.
Terminate program
26:exit terminates the program. Unix always closes all open descriptors when a process
terminates, so our TCP socket is now closed.

3.Protocol Independence
The above program is protocol-dependent on IPv4. We allocate and initialize asockaddr_in structure,
we set the family of this structure to AF_INET, and we specify the firstargument to socket as AF_INET. To
modify the program to work under IPV6, we must change the code. The following figure shows a version
that works under IPV6, with the changes highlighted in bold
1 #include unp.h

2 int
3 main(intargc, char *argv)
4{
5 intsockfd,n;
6 char recvline[MAXLINE+1];
7 structsockaddr_in6servaddr;
8 if(argc!=2)
9 err_quit(usage: a.out<IPaddress>);
10 if((sockfd=socket(AF_INET6,SOCK_STREAM,0))<0)
11 err_sys(socket error);
12 bzero(&servaddr, sizeof(servaddr));
13 servaddr.sin6_family = AF_INET6;
14 servaddr.sin6_port = htons(13); /* daytime server */
15 if (inet_pton(AF_INET6, argv[1], &servaddr.sin6_addr) <= 0)
16 err_quit("inet_pton error for %s", argv[1]);
17 if (connect(sockfd, (SA *) &servaddr, sizeof(servaddr)) < 0)
18 err_sys("connect error");
19 while ( (n = read(sockfd, recvline, MAXLINE)) > 0) {
20 recvline[n]=0;
21 if(fputs(recvline,stdout)==EOF)
22 err_sys(fputs error);
23 }
24 if(n<0)
25 err_sys(read error);
26 exit(0);
27 }
Only five lines are changed, but what we now have is another protocol-dependent program;this time,
it is dependent on IPv6. It is better to make a program protocol-independent.Protocol-independent by using
the getaddrinfofunction (which is called by tcp_connect).

4.Error Handling: Wrapper Functions

In the above programs we check for errors from socket, inet_pton, connect, read, and fputs, and
whenone occurs, we call our own functions, err_quit and err_sys, to print an error message andterminate the
program. We find that most of the time, this is what we want to do.Occasionally, we want to do something
other than terminate when one of these functionsreturns an error, when we must check for an interrupted
system call.Since terminating on an error is the common case, we can shorten our programs by defining
awrapper function that performs the actual function call, tests the return value, and terminates
on an error. The convention we use is to capitalize the name of the function, as in
sockfd = Socket(AF_INET, SOCK_STREAM, 0);
Our wrapper function is shown below
int
Socket(int family, int type, int protocol)

{
int n;
if ( (n = socket(family, type, protocol)) < 0)
err_sys("socket error");
return (n);
}
Whenever you encounter a function name in the text that begins with an uppercaseletter, that is one
of our wrapper functions. It calls a function whose name is the samebut begins with the lowercase letter
While these wrapper functions might not seem like a big savings, we will find that thread functions
do not set the standard Unix errno variable whenan error occurs; instead, the errno value is the return value
of the function. This means thatevery time we call one of the pthread_ functions, we must allocate a
variable, save the returnvalue in that variable, and then set errno to this value before calling err_sys. To
avoidcluttering the code with braces, we can use C's comma operator to combine the assignmentinto errno
and the call of err_sys into a single statement, as in the following:
int n;
if ( (n = pthread_mutex_lock(&ndone_mutex)) != 0)
errno = n, err_sys("pthread_mutex_lock error");
NOTE:
Unixerrno Value: When an error occurs in a Unix function (such as one of the socket functions), the
globalvariable errno is set to a positive value indicating the type of error and the function normallyreturns
1. Our err_sys function looks at the value of errno and prints the correspondingerror message string (e.g.,
"Connection timed out" if errno equals ETIMEDOUT).The value of errno is set by a function only if an
error occurs. Its value is undefined if thefunction does not return an error. All of the positive error values are
constants with alluppercasenames beginning with "E," and are normally defined in the <sys/errno.h>
header.No error has a value of 0.Storing errno in a global variable does not work with multiple threads that
share all global variables.
5. A Simple- Day Time Server
We can write a simple version of a TCP daytime server, which will work with the client from
. We use the wrapper functions.
1 #include "unp.h".
2 #include<time.h>
3 int
4 main(intargc, char **argv)
5{
6 intlistenfd, connfd;
7 structsockaddr_inservaddr;
8 char buff[MAXLINE];
9 time_t ticks;
10 listenfd = Socket(AF_INET, SOCK_STREAM, 0);
11 bzeros(&servaddr, sizeof(servaddr));
12 servaddr.sin_family=AF_INET;

13 servaddr.sin_addr.s_addr = htonl(INADDR_ANY);
14 servaddr.sin_port = htons(13); /* daytime server */
15 Bind(listenfd, (SA *) &servaddr, sizeof(servaddr));
16 Listen(listenfd, LISTENQ);
17 for ( ; ; ) {
18 connfd = Accept(listenfd, (SA *) NULL, NULL);
19 ticks = time(NULL);
20 snprintf(buff,sizeof(buff),%.24s\r\n, ctime(&ticks));
21 Write(connfd, buff, strlen(buff));
22 Close(connfd);
23 }
24 }
Figure : TCP daytime server.
Create a TCP socket
10 :The creation of the TCP socket is identical to the client code.
Bind server's well-known port to socket
1115 :The server's well-known port (13 for the daytime service) is bound to the socket byfilling in
an Internet socket address structure and calling bind. We specify the IP address as INADDR_ANY, which
allows the server to accept a client connection on any interface, in case server host has multiple interfaces.
Convert socket to listening socket
16 :By calling listen, the socket is converted into a listening socket, on which incomingconnections
from clients will be accepted by the kernel. These three steps, socket, bind, andlisten, are the normal steps
for any TCP server to prepare what we call the listeningdescriptor (listenfd in this example).The constant
LISTENQ is from our unp.h header. It specifies the maximum number of clientconnections that the kernel
will queue for this listening descriptor.
Accept client connection, send reply
1721: Normally, the server process is put to sleep in the call to accept, waiting for a
clientconnection to arrive and be accepted. A TCP connection uses what is called a three-wayhandshake to
establish a connection. When this handshake completes, accept returns, and thereturn value from the
function is a new descriptor (connfd) that is called the connecteddescriptor. This new descriptor is used for
communication with the new client. A new descriptoris returned by accept for each client that connects to
our server.
for(; ; ;)
{
..
} represent the infinite loop.
The current time and date are returned by the library function time, which returns the numberof
seconds since the Unix Epoch: 00:00:00 January 1, 1970, Coordinated Universal Time(UTC). The next
library function, ctime, converts this integer value into a human-readablestring such as
Mon May 26 20:58:40 2003.
A carriage return and linefeed are appended to the string by snprintf, and the result iswritten to the
client by write. Calls to sprintf cannot check for overflow of the destination buffer.snprintf, on the other

hand, requires that the second argument be the size of thedestination buffer, and this buffer will not
overflow.

Terminate connection
22 :The server closes its connection with the client by calling close. This initiates the normal TCP
connection termination sequence: a FIN is sent in each direction and each FIN is acknowledged by the other
end.
TRANSPORT LAYER
Here we focus on the transport layer: TCP, UDP, and Stream Control TransmissionProtocol (SCTP).
Most client/server applications use either TCP or UDP. SCTP is a newerprotocol, originally designed for
transport of telephony signaling across the Internet. Thesetransport protocols use the network-layer protocol
IP, either IPv4 or IPv6.
UDP is a simple, unreliable datagram protocol, while TCP is a sophisticated, reliable bytestream
Protocol. SCTP is similar to TCP as a reliable transport protocol, but it also providesmessage boundaries.
1. Transmission Control Protocol(TCP)
The service provided by TCP to an application is different from the service provided by UDP.TCP is
described in RFC 793 [Postel 1981c], and updated by RFC 1323 [Jacobson, Braden, andBorman 1992],
RFC 2581 [Allman, Paxson, and Stevens 1999], RFC 2988 [Paxson and Allman2000], and RFC 3390
[Allman, Floyd, and Partridge 2002]. First, TCP provides connectionsbetween clients and servers. A TCP
client establishes a connection with a given server,exchanges data with that server across the connection,
and then terminates the connection.
TCP also provides reliability. When TCP sends data to the other end, it requires anacknowledgment
in return. If an acknowledgment is not received, TCP automaticallyretransmits the data and waits a longer
amount of time. After some number ofretransmissions, TCP will give up, with the total amount of time spent
trying to send datatypically between 4 and 10 minutes (depending on the implementation).
TCP contains algorithms to estimate the round-trip time (RTT) between a client and
serverdynamically so that it knows how long to wait for an acknowledgment. For example, the RTTon a
LAN can be milliseconds while across a WAN, it can be seconds. Furthermore, TCPcontinuously estimates
the RTT of a given connection, because the RTT is affected by variations in the network traffic.
TCP also sequences the data by associating a sequence number with every byte that it sends.For
example, assume an application writes 2,048 bytes to a TCP socket, causing TCP to sendtwo segments, the
first containing the data with sequence numbers 11,024 and the secondcontaining the data with sequence
numbers 1,0252,048. (A segment is the unit of data thatTCP passes to IP.) If the segments arrive out of
order, the receiving TCP will reorder the twosegments based on their sequence numbers before passing the
data to the receivingapplication. If TCP receives duplicate data from its peer , it candetect that the data has
been duplicated (from the sequence numbers), and discard theduplicate data.
TCP provides flow control. TCP always tells its peer exactly how many bytes of data it is willingto
accept from the peer at any one time. This is called the advertised window. At any time, thewindow is the
amount of room currently available in the receive buffer, guaranteeing that thesender cannot overflow the
receive buffer. The window changes dynamically over time: As datais received from the sender, the window

size decreases, but as the receiving application readsdata from the buffer, the window size increases. It is
possible for the window to reach 0: whenTCP's receive buffer for a socket is full and it must wait for the
application to read data fromthe buffer before it can take any more data from the peer.
Finally, a TCP connection is full-duplex. This means that an application can send and receivedata in
both directions on a given connection at any time. This means that TCP must keeptrack of state information
such as sequence numbers and window sizes for each direction ofdata flow: sending and receiving.

TCP Connection Establishment and Termination

Three-Way Handshake
The following scenario occurs when a TCP connection is established:
1. The server must be prepared to accept an incoming connection. This is normally done bycalling
socket, bind, and listen and is called a passive open.
2. The client issues an active open by calling connect. This causes the client TCP to send a
"synchronize" (SYN) segment, which tells the server the client's initial sequence number for the data
that the client will send on the connection. Normally, there is no data sent with the SYN; it just
contains an IP header, a TCP header, and possible TCP options .
3. The server must acknowledge (ACK) the client's SYN and the server must also send its own SYN
containing the initial sequence number for the data that the server will send on the connection. The
server sends its SYN and the ACK of the client's SYN in a single segment.
4. The client must acknowledge the servers SYN.

Fig:TCP three- way handshake

We show the client's initial sequence number as J and the server's initial sequence number asK. The
acknowledgment number in an ACK is the next expected sequence number for the endsending the ACK.
Since a SYN occupies one byte of the sequence number space, theacknowledgment number in the ACK of
each SYN is the initial sequence number plus one.Similarly, the ACK of each FIN is the sequence number
of the FIN plus one.

10

TCP Connection Termination

1. One application calls close first, and we say that this end performs the active close. This end's TCP
sends a FIN segment, which means it is finished sending data.
2. The other end that receives the FIN performs the passive close. The received FIN is acknowledged
by TCP. The receipt of the FIN is also passed to the application as an endof- file (after any data that
may have already been queued for the application to receive), since the receipt of the FIN means the
application will not receive any additional data on the connection.
3. Sometime later, the application that received the end-of-file will close its socket. This causes its TCP
to send a FIN.
4. The TCP on the system that receives this final FIN acknowledges the FIN.

Fig: Packet exchanged when TCP connection is closed

11

TCP State Transition Diagram

12

There are 11 different states defined for a connection and the rules of TCP dictate thetransitions from
one state to another, based on the current state and the segment received inthat state. For example, if an
application performs an active open in the CLOSED state, TCPsends a SYN and the new state is
SYN_SENT. If TCP next receives a SYN with an ACK, it sendsan ACK and the new state is
ESTABLISHED.
The two arrows leading from the ESTABLISHED state deal with the termination of a connection.If
an application calls close before receiving a FIN (an active close), the transition is to theFIN_WAIT_1 state.
But if an application receives a FIN while in the ESTABLISHED state (apassive close), the transition is to
the CLOSE_WAIT state.
We denote the normal client transitions with a darker solid line and the normal servertransitions with
a darker dashed line.
Watching the Packets
The following figure shows the actual packet exchange that takes place for a complete TCP
connection:the connection establishment, data transfer, and connection termination.

Figure: Packet exchange for TCP connection.

TIME_WAIT State

13

In the above figure we can see that the end that performs theactive close goes through time_wait
state. The duration that this endpoint remains in this state istwice the maximum segment lifetime (MSL),
sometimes called 2MSL.
Every implementation of TCP must choose a value for the MSL. The recommended value in RFC
1122 is 2 minutes. This means the duration of the TIME_WAIT state is 4 minutes.
There are two reasons for the TIME_WAIT state:
1. To implement TCP's full-duplex connection terminationreliably
2. To allow duplicate segments to expire in the network.
The first reason can be explained by looking at the above figure and assuming that the final ACK islost.
The server will resend its final FIN, so the client must maintain state information, allowingit to resend the
final ACK. If it did not maintain this information, it would respond with an RST(a different type of TCP
segment), which would be interpreted by the server as an error. If TCPis performing all the work necessary
to terminate both directions of data flow cleanly for aconnection (its full-duplex close), then it must
correctly handle the loss of any of these foursegments. This example also shows why the end that performs
the active close is the end thatremains in the TIME_WAIT state: because that end is the one that might have
to retransmitthe final ACK.
To understand the second reason for the TIME_WAIT state, assume we have a TCP connectionbetween
12.106.32.254 port 1500 and 206.168.112.219 port 21. This connection is closed andthen sometime later, we
establish another connection between the same IP addresses andports: 12.106.32.254 port 1500 and
206.168.112.219 port 21. This latter connection is calledan incarnationof the previous connection since the
IP addresses and ports are the same. TCPmust prevent old duplicates from a connection from reappearing at
some later time and beingmisinterpreted as belonging to a new incarnation of the same connection. To do
this, TCP willnot initiate a new incarnation of a connection that is currently in the TIME_WAIT state.
Sincethe duration of the TIME_WAIT state is twice the MSL, this allows MSL seconds for a packet inone
direction to be lost, and another MSL seconds for the reply to be lost. By enforcing thisrule, we are
guaranteed that when we successfully establish a TCP connection, all oldduplicates from previous
incarnations of the connection have expired in the network.
2.User Datagram Protocol (UDP)
UDP is a simple transport-layer protocol. It is described in RFC 768. Theapplication writes a
message to a UDP socket, which is then encapsulated in a UDP datagram,which is then further
encapsulated as an IP datagram, which is then sent to its destination.There is no guarantee that a UDP
datagram will ever reach its final destination, that order willbe preserved across the network, or that
datagrams arrive only once.
The problem that we encounter with network programming using UDP is its lack of reliability. Ifa
datagram reaches its final destination but the checksum detects an error, or if the datagramis dropped in the
network, it is not delivered to the UDP socket and is not automaticallyretransmitted. If we want to be certain
that a datagram reaches its destination, we can buildlots of features into our application: acknowledgments
from the other end, timeouts,retransmissions, and the like.
We also say that UDP provides a connectionless service, as there need not be any longtermrelationship between a UDP client and server. For example, a UDP client can create a socketand send a
datagram to a given server and then immediately send another datagram on thesame socket to a different

14

server. Similarly, a UDP server can receive several datagrams on asingle UDP socket, each from a different
client.

3. Stream Control Transmission Protocol (SCTP)

SCTP provides services similar to those offered by UDP and TCP. SCTP is described in RFC 2960,
and updated by RFC 3309. Anintroduction to SCTP is available in RFC 3286. SCTP providesassociations
between clients and servers. SCTP also provides applications with reliability,sequencing, flow control, and
full-duplex data transfer, like TCP. The word "association" is usedin SCTP instead of "connection" . An
association refers to a communicationbetween two systems, which may involve more than two addresses
due to multihoming.
SCTP provides a multihoming feature, which allows a single SCTP endpoint to supportmultiple IP
addresses. This feature can provide increased robustness against network failure.An endpoint can have
multiple redundant network connections, where each of these networkshas a different connection to the
Internet infrastructure. SCTP can work around a failure of onenetwork or path across the Internet by
switching to another address already associated withthe SCTP association.
SCTP Association Establishment and Termination
SCTP is connection-oriented like TCP, so it also has association establishment and
terminationhandshakes.
Four-Way Handshake
The following scenario, similar to TCP, occurs when an SCTP association is established:
1.The server must be prepared to accept an incoming association. This preparation isnormally done
by calling socket, bind, and listen and is called a passive open.
2. The client issues an active open by calling connect or by sending a message, whichimplicitly
opens the association. This causes the client SCTP to send an INIT message(which stands for
"initialization") to tell the server the client's list of IP addresses, initialsequence number, initiation tag to
identify all packets in this association.
3. The server acknowledges the client's INIT message with an INIT-ACK message, whichcontains
the server's list of IP addresses, initial sequence number, initiation tag, and a state cookie. The state cookie
contains all of the state that the serverneeds to ensure that the association is valid, and is digitally signed to
ensure its validity.
4. The client echos the server's state cookie with a COOKIE-ECHO message. This message may also
contain user data bundled within the same packet.
5.The server acknowledges that the cookie was correct and that the association wasestablished with a
COOKIE-ACK message. This message may also contain user databundled within the same packet.

15

Fig:SCTP four way handshake

The SCTP four-way handshake is similar in many ways to TCP's three-way handshake, except for
the cookie generation, which is an integral part. The INIT carries with it a verification tag, Ta, and an initial
sequence number, J. . The peer also chooses a verification tag, Tz, which must be present in each of its
packets for the life of the association. Along with the verification tag and initial sequence number, K, the
receiver of the INIT also sends a cookie, C. The cookie contains all the state needed to set up the SCTP
association, so that the server's SCTP stack does not need to keep information about the associating client.
Association Termination
Unlike TCP, SCTP does not permit a "half-closed" association. When one end shuts down
anassociation, the other end must stop sending new data. The receiver of the shutdown requestsends the data
that was queued, if any, and then completes the shutdown.

Fig: Packets exchanged when an SCTP association is closed.

16

Watching the Packets

The following figure shows the actual packet exchange that takes place for a sample SCTP
association:the association establishment, data transfer, and association termination.

17

SCTP State Transition Diagram

18

Port Numbers
At any given time, multiple processes can be using any given transport: UDP, SCTP, or TCP.
Allthree transport layers use 16-bit integer port numbers to differentiate between theseprocesses.
When a client wants to contact a server, the client must identify the server with which it wantsto
communicate. TCP, UDP, and SCTP define a group of well-known ports to identify wellknownservices. For
example, every TCP/IP implementation that supports FTP assigns the well-knownport of 21 (decimal) to the
FTP server. Trivial File Transfer Protocol (TFTP) servers areassigned the UDP port of 69.
Clients, on the other hand, normally use ephemeral ports, that is, short-lived ports. These
portnumbers are normally assigned automatically by the transport protocol to the client. Clientsnormally do
not care about the value of the ephemeral port; the client just needs to be certainthat the ephemeral port is
unique on the client host. The transport protocol code guaranteesthis uniqueness.
The Internet Assigned Numbers Authority (IANA) maintains a list of port number
assignments.Assignments were once published as RFCs; RFC 1700 is the last inthis series. The port
numbers are divided into three ranges:
1. The well-known ports: 0 through 1023. These port numbers are controlled and assignedby the
IANA. When possible, the same port is assigned to a given service for TCP, UDP,and SCTP. For example,
port 80 is assigned for a Web server, for both TCP and UDP, eventhough all implementations currently use
only TCP.
2.The registered ports: 1024 through 49151. These are not controlled by the IANA, but theIANA
registers and lists the uses of these ports as a convenience to the community. Whenpossible, the same port is
assigned to a given service for both TCP and UDP. For example,ports 6000 through 6063 are assigned for an
X Window server for both protocols, eventhough all implementations currently use only TCP.
3. The dynamic or private ports, 49152 through 65535. The IANA says nothing about theseports.
These are what we call ephemeral ports.

Figure: Allocation of port number

19

We note the following points from this figure:

Unix systems have the concept of a reserved port, which is any port less than 1024.These ports can
only be assigned to a socket by an appropriately privileged process. Allthe IANA well-known ports
are reserved ports; hence, the server allocating this port(such as the FTP server) must have superuser
privileges when it starts.
Historically, Berkeley-derived implementations have allocatedephemeral ports in the range 1024
5000.
There are a few clients (not servers) that require a reserved port as part of theclient/server
authentication: the rlogin and rsh clients are common examples. Theseclients call the library
functionrresvport to create a TCP socket and assign an unusedport in the range 5131023 to the
socket. This function normally tries to bind port 1023,and if that fails, it tries to bind 1022, and so
on, until it either succeeds or fails on port513.
Socket Pair :
The socket pair for a TCP connection is the four-tuple that defines the two endpoints of
theconnection: the local IP address, local port, foreign IP address, and foreign port. A socket pairuniquely
identifies every TCP connection on a network. For SCTP, an association is identified bya set of local IP
addresses, a local port, a set of foreign IP addresses, and a foreign port. In itssimplest form, where neither
endpoint is multihomed, this results in the same four-tuple socketpair used with TCP. However, when either
of the endpoints of an association are multihomed,then multiple four-tuple sets (with different IP addresses
but the same port numbers) mayidentify the same association.
The two values that identify each endpoint, an IP address and a port number, are often called a
socket.
TCP Port Numbers and Concurrent Servers
With a concurrent server, where the main server loop spawns a child to handle each new Connection.
Consider an example. First, the server is started on the host which is multihomed with IP addresses
12.106.32.254 and 192.168.42.1, and the server does a passive open using its well-known port number (21,
for this example). It is now waiting for a client request, that is shown in the following figure.

Figure: TCP server with a passive open on port 21.

20

We use the notation {*:21, *: *} to indicate the server's socket pair. The server is waiting for a
connection request on any local interface (the first asterisk) on port 21. The foreign IP address and foreign
port are not specified and we denote them as *:*. We also call this a listening socket.
When we specify the local IP address as an asterisk, it is called the wildcard character. If the host on
which the server is running is multihomed (as in this example), the server can specify that it wants only to
accept incoming connections that arrive destined to one specific local interface. This is a one-or-any choice
for the server. The server cannot specify a list of multiple addresses. The wildcard local address is the "any"
choice.
At some later time, a client starts on the host with IP address 206.168.112.219 and executes an active
open to the server's IP address of 12.106.32.254. We assume the ephemeral port chosen by the client TCP is
1500 for this example.

Figure: Connection request from client to server.

When the server receives and accepts the client's connection, it forks a copy of itself, letting the child
handle the client.

Figure: Concurrent server has child handle client.

The next step assumes that another client process on the client host requests a connection with the
same server. The TCP code on the client host assigns the new client socket an unused ephemeral port
number, say 1501. On the server, the two connections are distinct: the socket pair for the first connection

21

differs from the socket pair for the second connection because the client's TCP chooses an unused port for
the second connection (1501).

Figure : Second client connection with same server.

Buffer Sizes and Limitations
Certain limits affect the size of IP datagrams. We first describe these limits and then tie them all together
with regard to how they affect the data an application can transmit.
The maximum size of an IPv4 datagram is 65,535 bytes, including the IPv4 header. This is because
of the 16-bit total length field.
The maximum size of an IPv6 datagram is 65,575 bytes, including the 40-byte IPv6 header. IPv6 has
a jumbo payload option, which extends the payload length field to 32 bits, but this option is
supported only on data links with a maximum transmission unit (MTU) that exceeds 65,535.
Many networks have an MTU (maximum transmission unit) which can be dictated by the hardware.
For example, the Ethernet MTU is 1,500 bytes. Other data links, such as point-to-point links using
the Point to- Point Protocol (PPP), have a configurable MTU.
The smallest MTU in the path between two hosts is called the path MTU. Today, the Ethernet MTU
of 1,500 bytes is often the path MTU.
When an IP datagram is to be sent out an interface, if the size of the datagram exceeds the link MTU,
fragmentation is performed by both IPv4 and IPv6. The fragments are not normally reassembled
until they reach the final destination. IPv4 hosts perform fragmentation on datagrams that they
generate and IPv4 routers perform fragmentation on datagrams that they forward. But with IPv6,
only hosts perform fragmentation on datagrams that they generate; IPv6 routers do not fragment
datagrams that they are forwarding.
If the "don't fragment" (DF) bit is set in the IPv4 header , it specifies that this datagram must not be
fragmented, either by the sending host or by any router. A router that receives an IPv4 datagram with
the DF bit set whose size exceeds the outgoing link's MTU generates an ICMPv4 "destination
unreachable, fragmentation needed but DF bit set" error message.

22

Since IPv6 routers do not perform fragmentation, there is an implied DF bit with every IPv6
datagram. When an IPv6 router receives a datagram whose size exceeds the outgoing link's MTU, it
generates an ICMPv6 "packet too big" error message.
IPv4 and IPv6 define a minimum reassembly buffer size, the minimum datagram size that we are
guaranteed any implementation must support. For IPv4, this is 576 bytes. IPv6 raises this to 1,500
bytes.
TCP has a maximum segment size (MSS) that announces to the peer TCP the maximum amount of
TCP data that the peer can send per segment.
Standard Internet Services

Following figure lists several standard services that are provided by most implementations of
TCP/IP. Notice that all are provided using both TCP and UDP and the port number is the same for both
protocols.

Figure: Standard TCP/IP services provided by most implementations.

Protocol Usage by Common Internet Applications
Following figure summarizes the protocol usage of various common Internet applications.

23

Figure: Protocol usage of various common Internet applications.