n

University of Prishtina
Faculty of Computer and Electrical Engineering
Telecommunication Department

Sockets and TCP

Computer Networking

Mentor:
Prof. Dr. Blerim Rexha

Students:
Rreze Halili [rrezehalili@hotmail.com]
Isuf Tredhaku [faradi33@hotmail.com]
Orges Tafilaj [orgestafilaj@hotmail.com]

January 2012, Prishtina

Abstract
This seminar work deals with the role of Sockets and TCP (Transmission Control Protocol) in TCP/IP
protocol suit.
By the fact that today, we use the TCP/IP protocols and Internet, not only for entertainment and information,
but for our business by performing transactions, buying and selling products, and delivering services to
customers. And lot more services that Internet providers offer for their costumers, services those that are
available to users by applications. And by the fact that we are continually extending the need for different
applications, TCP/IP continually is extending the infrastructural support and reliability.
But how this reliability is achieved? One of reasons here is network configurations and huge role plays
TCP/IP protocol suit.
And if we talk about reliability implemented in TCP/IP, the first thing we have in mind is TCP protocol.
As we said this will be the subject of our work here.
In the first chapter we have given a useful explanation for TCP/IP in general, and the role of protocols.
Then the second chapter deals with the role of Socket in transport layer of TCP/IP.
Part of transport layer, TCP presents one of the most successful protocols that provides secure transmission,
basic data transfer, reliability, flow control, multiplexing, byte stream and full duplex data transfer. This is
the reason why we have continued with TCP explanation and its performance. This is achieved by separating
its characteristics in number of parts in third chapter.
In every part we have tried to give a simple, logical, and useful explanation. This is the reason that this text
despite being a seminar, with which our group will be estimated, several features here are designed to make
it particularly easy for students to understand Sockets and TCP, from our point of view.
We would be honored if we have achieved this even in a small level.

Faqja2 / 29

Contents
1

Introduction................................................................................................................................ 4

Socket ....................................................................................................................................... 6

Transport control protocol - TCP .................................................................................................. 9

3.1 Connection oriented ............................................................................................................. 9
3.2 Segment of TCP ................................................................................................................ 11
3.3 Connection establishment ................................................................................................... 14
3.4 Retransmission techniques .................................................................................................. 16
3.4.1 Variable intervals timeout ............................................................................................... 17
3.4.2 Doubling the time interval ............................................................................................... 18
3.5 Flow Control and Receiving Windows ................................................................................. 19
3.6 Congestion Control ............................................................................................................ 21
3.7 Termination of connection .................................................................................................. 24
3.8 Configuration of TCP ......................................................................................................... 25

Conclusion ..................................................................................................................................... 26
Bibliography .................................................................................................................................. 27
Appendix 1........28
Appendix 229

Faqja3 / 29

Socket and TCP

1 Introduction
In everyday life we face up with a lot of different applications, which we use for different purposes.
Every time we ask for the best from them, great performance in every aspect. In this way we perform
with different, secure, fast, reliable, and attractive tasks.
To sum up, these applications are changing the way we learn, live, enjoy, communicate, interact etc.
The modern life activities are getting completely centered around or driven by the Internet
applications.
This is the reason why so many people are taking advantage of opportunities presented by Internet.
This created a huge demand for software designers and engineers with skills in creating new Internetenabled applications or porting existing/legacy applications to the Internet platform. The key elements
for developing Internet-enabled applications are a good understanding of the issues involved in
implementing distributed applications and sound knowledge of the fundamental network programming
models. [KC]
In this way, we can separate people in two groups. The first group are those who are not interested in
the way that those applications are available, just search for the best from them, and do not hesitate to
pay for. And the other part, who in fact understand quite well the logic of this business (if we can call
in this way) and are interested to attract the first part with different services, always trying to offer
secure services, and attractive, and they do not hesitate to be paid for this too.
But how is it possible? We are working in a project, while we surf in a web, send a letter to our friend
(maybe to tell that we can not go out tonight, because we have to finish the project), download a lot of
materials for our task and a lot of other things.
In fact there are thousand of processes that are performed in our computer, and a lot of others in
network, that make possible this. And all this stuff is regulated by the number of rules that we call
protocols.
In our case those rules are defined by OSI model, to be more specific TCP/IP (Transport Control
Protocol/Internet Protocol) protocol suite.
The TCP/IP model includes a number of protocols to insure proper communication between
corresponding layers of networked machines Fig1.1.

Fig.1.1 TCP/IP Protocol layers

Faqja4 / 29

Socket and TCP

As we can see there are seven layers, and for this, questions often are about the use of layered
protocols. Why do we need those layers? And the best way to answer, is taking a simple example.
Two persons want to communicate with each other, and to achieve this they need to speak in the same
transmission medium, and use the same language.
In this way the communication can be seen as a structure with several layers. In the brain layer we
think about what we are going to talk, we prepare the concept for the language layer, which uses the
below layer (the mouth) to produce the sound.
Sound waves use transmission medium to arrive to the destination, where the ear receives
the sound waves, the language is interpreted, and brain receives the information sent by the other
person.

Fig.1.2 Communication

In the same logic work the TCP/IP layers. As we can see from the Fig.1.1 the top layer of TCP/IP is
the Application layer.
The application layer is provided by the program that uses TCP/IP for communication. An application
in a user process cooperating with another process usually on a different host (there is also a benefit to
application communication within a single host). [IBM 2001]
This includes all processes that use Transport layer protocols to deliver data to the Internet layer.
Placed between the Application and Network layer, Transport layer has the task to perform the logical
communication between application processes of different or same host. This host can be directly
connected to it, or may be very far away, and needs to pass routers and a lot of links for the
destination. But how does the Transport layer of the TCP/IP model prepare user data for transmission
to the network? What are some of the issues surrounding Transport layer configuration, management,
and troubleshooting?
Here we can see the importance that Transport layer has. And in this task we face up with the notion
socket, which we are going to explain below.

Faqja5 / 29

Socket and TCP

2 Socket
Applications involve networking services provided by the transport layer, which is part of the Internet
software stack, often called TCP/IP stack, shown in Fig. 1.3. The transport layer can be one of the two
types of protocols, TCP (Transport Control Protocol) and UDP (User Datagram Protocol).
So we mentioned applications data, and we mentioned transport of these data, but how do we know
which application protocol should data proceed when it comes from the network layer, how those data
will go to the user interface, and how the user will be able to see this.
And why not to ask for the opposite too?
What happens when the user has to send something to network, how the data will find their route or
path to continue?
The fact is that every computer has its own IP address; however, computers often need to
communicate and provide more than one type of service, or to talk to multiple hosts/computers at a
time. For example, there may be multiple FTP sessions, web connections, and chat programs all
running at the same time. To distinguish these services, a concept of ports is used.
Port is a logical access point, represented by a 16-bit integer number. This means that each service
offered by a computer is uniquely identified by a port number.
This is the reason why each packet contains the IP address and the port number on the host in which
the packet was destined.
Just think about this, IP addresses is the house address when a letter is sent via post office, and port
number in the name of a specific person that has to read the letter (it is his letter).
We have come to the fact that packets have IP addresses and port numbers that are useful for the
destination place. This combination of both those, IP address and port number creates a so called
socket address.

Fig.2.1 Socket address

The two processes communicate with each other by sending and receiving messages through their
sockets. A process's socket can be thought of as the process's door: a process sends messages into, and
receives message from, the network through its socket.
When a process wants to send a message to another process on same/another host, it shoves the
message out its door, or out of its socket. [JKKR 2010]
In this way the server A, which is connected with a client B, can stay and wait for clients request,
mean time can open e connection with another one, in a different port number, so the server has to use
different socket now. Fig.2.2.
Furthermore a socket is an endpoint of a two-way communication link between two programs running
on the network. This is the only way how the transport layer protocol can know where data are
destined.

Faqja6 / 29

Socket and TCP

Fig.2.2 Establishment of path for two-way communication between a client and server
By the last sentence we can add too that socket is used like an Application Programming Interface
API.
Interface to what? In our case, it is an interface to use the network, provided by operating system. We
can see this in Fig.2.3.
We can imagine socket like software methodology, a single connection between exactly two pieces of
software that we use to connect different processes (programs) on the same computer or on different
computers.
This looks like plugging in process into another processs socket, with the tendency to make
possible talking by writing and reading the socket. Fig.2.4.

Fig.2.3 Application layers and the interaction with socket

Within the operating system and the application that created a socket, the socket is referred to by a
unique integer number called socket identifier or socket number. The operating system forwards the
payload of incoming IP packets to the corresponding application by extracting the socket address
information from the IP and transport protocol headers and stripping the headers from the application
data.

Faqja7 / 29

Socket and TCP

Fig.2.4 Socket mechanism

2.1 Types of Internet Sockets

The fact is that we have different type of socket, not many, but while we are talking about TCP/IP
protocol suite, we are going to talk more about Internet Socket.
Internet socket can be:
Datagram
Raw
Stream
The first category we refer a connectionless socket too, by the reason that we just form a socket
while it puts the packet in the destined place, and here is the end, it does not care any more for the
packet route. It can be lost during transmission or received out of order, but it is the application's
responsibility and not the socket's to deal with these problems. It supports UDP protocol.
The second type is Raw socket, that supports standard protocols like TCP and UDP. Raw sockets are
used for custom low-level protocol development.
The third type is stream socket, and in the same time represents the most commonly-used type. This
thanks the fact that stream sockets are reliable, two-way connected communication, and implement
"connection-oriented" semantics.
Before any data pass through, the connection is established, and then its time for data. This will result
with secure arrive of packet and in correct order.
How do stream sockets achieve this high level of data transmission quality? They use a protocol called
"The Transmission Control Protocol", known as "TCP", which we are going to explain more.

Faqja8 / 29

Socket and TCP

3 Transport control protocol - TCP

TCP- Transmission Control Protocol is a standard protocol with STD number 7. TCP is described by
RFC 793 [RFC 793]. Its status is recommended, but in practice, every TCP/IP implementation that is
not used exclusively for routing will include TCP. [IBM 2001].
TCP provides a one-to-one, connection-oriented, reliable communications service, byte stream and full
duplex data transfer.
This protocol establishes connections, sequences and acknowledges packets sent, and recovers packets
lost during transmission. Using flow control, timers, congestion control ensures safe delivery of data
and in correct order.
In one sentence, performs reliable data transport services between process above the IP layer that is
unreliable and produce that what we call best effort.
TCP protocol has strict error-detection algorithms built in to ensure the integrity of the data.
All these and lot more function we are going to describe below, from the first action that is taken in
the TCP tasks. This will help us to understand the reasons of this TCPs performance, and explain how
this is achieved. First of all we are going to describe the notion connection oriented, one of the most
important features of TCP.

3.1 Connection oriented

What dose this mean connection oriented? With connection-oriented protocol, a connection must be
established with the communication partner before exchanging data. This means that before sending
appropriate data the sender and receiver should proceeds with a control information called three-way
handshake. This method
Is highly reliable
Requires more computational processing.
Continuing with our previous example, the persons that are taking and exchanging information with
each other, are aware for this, and their response is ready when the other one finishes his sayings.

Fig.3.1 Connection Oriented protocol

So both, the sending and receiving applications must interact with their operating systems (OS). This
interaction is useful because the OS should set up whatever is necessary for communication to take
place.
Using TCP means creating a virtual connection between two TCP-s to send data. But be careful not to
confuse this with circuits switch or virtual circuit transport method, because TCP is just part of hosts,
end systems, and its performance dose not influence the elements between them. TCP protocol is
totally part of end system, and intermediate elements communicate with different protocols.

Faqja9 / 29

Socket and TCP

So here we start, one host A that we call client want to start a connection with the other host B that we
call server. (We are going to use host A and host B quite often so get used with it)
Host A begins the connection by sending host B a segment (special name for type of data being in TCP
layer, that we will explain later) with the "Synchronize sequence numbers" (SYN) bit set.
This segment tells host B that A wishes to set up a connection, and it tells B what sequence number
host A will use as a starting number for its segments. (Sequence numbers are used to keep data in the
proper order.) Host B responds to A with a segment that has the "Acknowledgment" (ACK) and SYN
bits set. B's segment acknowledges the receipt of A's segment, and informs A which Sequence Number
host B will start with. Finally, host A sends a segment that acknowledges receipt of B's segment, and
from the last transfer, third stage can transfers the first actual data. [OReilly]. Fig.3.2.

Fig.3.2 Three way handshake

But each data that have to be transmitted by the transport layer, comes after the demand made by
application layer. But how TCP knows what should be transported, and is this important for this
protocol layer?
In fact TCP dose not know what is written by application layer, it takes the data in a stream through
the socket and divide them in independent way. In this way TCP will take chunks of data from the
send buffer, and add to them the TCP header. This process will create a TCP segment.
The maximum amount of data that can be taken and placed in a segment is limited by the Maximum
Segment Size (MSS).
The MSS depends on the TCP implementation (determined by the operating system) and can often be
configured. Here is important to achieve the fact that after encapsulation in IP will fill into a single
link-layer frame, which is specified by MTU (maximum transmission unit), common values for MTU
are 1,500 bytes, 536 bytes and 512 bytes. [JKKR 2010]
So in this way between different processes, TCP creates an environment in which seems to be
connected by an imaginary "tube" that carries their data across the Internet.Fig.3.3.

Fig.3.3 Streaming transportation between processes

Faqja10 / 29

Socket and TCP

In fact after segmentation this would continue to the network layer where would be encapsulated in IP
datagram, and then achieve the destination where would pass through the opposite action explained
above.
With stream data transfer, TCP delivers an unstructured stream of bytes identified by sequence
numbers. This service benefits applications because they do not have to chop data into blocks before
handing it off to TCP. Instead, TCP groups bytes into segments and passes them to IP for
delivery.[CIS 2011]
So data coming from the application is referred as a flowing stream. Data can flow fast or slow. To
insure efficient flow of data to and from the application, TCP provides both input and output buffers.
TCP has to think where to put bytes that come from above, and want to take the way to network, it just
can not answer everyone in immediate way.
In the Fig.3.4 we have taken a simple example how this all works. There are two buffers, the sending
buffer and the receiving buffer, one for each direction. Normally the buffers are hundreds or thousands
of bytes, but we have taken a symbolic small number just to explain how it works. We also show the
buffers are in the same size, which is not always the case. In the sending buffer we have the colored
part of the sectors, when we put bits that have been sent but we have not accept jet the confirmation
for correct arrive in destination process.
And the other part of the buffer, when we have bits, that should be put in the segments and sent to
network.
The operation of the buffer at the receiver site is simpler. We have the part that is white and waits for
bytes from source, and the colored sectors that contain received bytes that can be read by the receiving
process. When a byte is read by the receiving process, the sector is recycled and added to the pool of
empty sector.

Fig.3.4 TCP segments and buffers

3.2 Segment of TCP

As we have explained earlier, when a stream of bytes comes from the application layer this can not be
send in this way in network layer, but should be sent in packets.
So the data handed to TCP for transmission is known as a stream; more specifically, an unstructured
stream.
A stream is a flow of bytes of data and an unstructured stream is an unknown type of data flow of
bytes. [MN 1999]
This is the reason why the transport layer, (in our case TCP), groups a number of bytes and form a
packet, that in TCP we call segment. But what we see in this segment? How this is made off and what

Faqja11 / 29

Socket and TCP

does it contains? This is the subject of this part where we are going to talk more about structure of the
TCP segment.

Fig.3.5 TCP segment structure

As we can see in the Fig.3.5 the segment structure of TCP that contains:
The segment consists of a 20- to 60-byte header, followed by data from the application program.
Source port address. This is a 16-bit field that defines the port number of the application program in
the host that is sending the segment, which we use to multiplex/demultiplex the data from the upper
application layer.
Destination port address. This is a 16-bit field that defines the port number of the application program
in the host that is receiving the segment, and has the same function like source port, mux/demux the
application data.
Sequence number field. As we have said before TCP view data as unstructured, ordered, and stream of
bytes, that is the reason that to achieve connectivity, each byte that has to be transmitted, is numbered.
[JKKR 2010]
The sequence number filed tells the destination which byte in this sequence is the first byte in the
segment so we use too to reassemble data in the order in which it was sent.
During connection establishment, when we do not posses data, it uses a random number generator to
create an initial sequence number (ISN), which is usually different in each direction. This is 32 bit
long.
Acknowledgment number. What TCP is characterized, is reliability of data transferred, and one of the
main reasons for this, is the acknowledgment technique that uses TCP. This 32-bit field defines the
byte number that the receiver of the segment is expecting to receive from the other party. If the
receiver of the segment has successfully received byte number x from the other party, it defines x + 1
as the acknowledgment number. Acknowledgment and data can be piggybacked together.

Faqja12 / 29

Socket and TCP

Header length. This 4-bit field is the part that tell the number of 4-byte words in the TCP header. As
we said before this value can be between 20 and 60 bytes. It indicates where the TCP header ends and
the data begins.
Unused field. Is this part that makes possible to change the value of TCP header, and we let this like a
reserved. We can use in the future, but for now they must be zero.
Control or flag field. This field defines 6 different control bits or flags as shown in fig 1.x. One or
more of these bits can be set at a time. A brief description of each bit is shown in Table 3.1.
Table 3.1
Flag

Description

URG

The value of the urgent pointer field is valid.

ACK

The value of the acknowledgment field is valid.

PSH

Push the data.

RST

Reset the connection.

SYN

Synchronize sequence numbers during connection.

FIN

Terminate the connection.

Even from the table we can see that the URG bit tells that the sending part of application has put data
that are considered urgent.
ACK bit is used to tell that the data received from the acknowledgment is valid.
PHD bit we use when we need to tell the destination that data should pass immediately in the
application layer.
RST we use to reset the connection. One function for this is to not accept a connection request.
SYN we use to synchronize sequence numbers, and FIN to terminate the connection, no more data for
receiver. [BFSF 2007]
Receive window. The field that is 16 bit field long means that the maximum size of the window is
65,535 bytes, but this can be decided by the receiver. We use this field for flow control that we will
explain later.
Internet checksum. This field is used to detect errors over the entire user.
Urgent data pointer. This l6-bit field, we use when the urgent flag is set, and defines the number that
must be added to the sequence number to obtain the number of the last urgent byte in the data section
of the segment.
Options filed we use when we negotiate the number of TCP header.

Faqja13 / 29

Socket and TCP

3.3 Connection establishment

Now after we have done the TCP segment, we are ready to put the segment in network, which means
we are ready to start communication with the other part.
As we have said TCP connection is connection oriented and full-duplex too, which means that when a
host A, in fact application layer data A send data to application layer data of host B, in the same time
application layer data in host B, can send data to application layer of host A.
In the first sight this sound really mess, confusing and the very little chance of control and achieve
reliable data transfer, but the functions taken here are very simple. These functions include OPEN and
CLOSE a connection, SEND and RECEIVE (information) to that connection, and STATUS to receive
information for a connection.
In general this is like this: send a packet and then wait for an acknowledgment from the receiver,
before sending the next packet. If the ACK is not received within a certain amount of time, retransmit
the packet. Fig.3.6.
Furthermore TCP protocol provide point to point communication, bur not point to area (a single
sender and more receivers).

Fig. 3.6 Connection principles

We start with the three way handshaking process that we have mentioned earlier too, this to achieve
connection establishment.
Just to make a digression here, we have to make a difference between a passive and active connection.
See Fig.3.7.
When the server program tells its TCP that it is ready to accept a connection, is called a request for a
passive open.
And when the client program issues a request for an active open .A client that wishes to connect
to an open server tells its TCP that it needs to be connected to that particular server. [BFSF 2007]

Fig. 3.7 Active and Passive open

Faqja14 / 29

Socket and TCP

After connection is established, bidirectional data transfer can take place. The client and server can
both send data and acknowledgments.
Despite the fact that sequence numbers are put in random manner in TCP header, they have important
role, by the fact that they have the control of putting data in the proper order and make possible to
evident if some of segment are missing. Furthermore sequence numbers speak about bytes in TCP and
not packet, which fact enhance even more the security of data transfer.
Same are acknowledgment numbers.
TCP uses acknowledgments to confirm the receipt of data segments. So Acknowledgment Segment
(ACK) performs two functions: positive acknowledgment and flow control. By its function we know
how much data has been received, and how much more the receiver can accept. [OReilly 1999]. And
ACK number speaks, about the bytes and not for packet, segment or datagram.
For example suppose that we have done with the handshaking and we are transferring data
information. And the receiver buffer or the number of bytes that can have is 6000 bytes.
We will explain later the window concept, but for now is enough to know the main role of it.
This tells the sender that can continue sending segments, as long as the total number of bytes that it
sends, is smaller than the buffer of bytes the receiver can accept.
It will put as a sequence number 0 and will transfer 2000 bytes, which means the SEQ=0 and
ACK=2001 (ACK No. = sequence number + bytes read in the segment + 1).
And as the receiver can have until 6000 bytes, will take them and send a segment back, which is form
SEQ=2001, ACK=3001.
The sender will turn back the answer by putting in the SEQ=3001 ACK=4001. So in this way each
byte will be transferred for sure. See Fig.3.8

Fig.3.8 TCP data stream

This way of working of TCP protocol in the transport layer makes that what we call fast and reliable
transfer, however not always happen like this.
The fact that TCP performs above the unreliable layer like IP, and data pass through a lot of more
paths, routers, links which makes TCP to look like a very little price of cake in this scenario, because
what TCP will do, if data has been lost during channel transmission.
For example segments of above example are sent again, but after the sender has finished sending three
segments, has received just one acknowledgment ACK=2001, the second is missing.
The sender has received no acknowledgment for the bytes from 2001 on, but continues sending data as
long as it is within the window. If the sender fills the window and receives no acknowledgment, it
will, after an appropriate time-out, send the data again starting from the first unacknowledged byte.
In fact the strategy used by TCP overcome even with this problem, but the way how it solve this we
are going to explain in later sections below, by flow control, retransmission technique, and congestion
control.

Faqja15 / 29

Socket and TCP

3.4 Retransmission techniques

Internet's connection oriented services are group of services that are reliable, and TCP we said before
that is part of them. And one of the techniques that are provided by TCP to achieve reliability is
retransmission.
TCP is communication protocol that provides this aspect. As we have said before TCP perform in
transport layer that is the layer above the network layer which is completely unreliable in this aspect.
So how is possible to perform reliable services?
Despite the famous phrase The hardness of chain depends exactly on the hardness of his weakest
link, TCP protocol has achieved to enhance the hardness of chain above the hardness of his weakness
link.
So the data sent in the network layer and finish in the transport layer can be taken with a enough
reliability. This of course is achieved by the acknowledgments and retransmissions.
If the receivers of the packet do not send back an acknowledgment, to prove that the packet is in the
destination where it was sent, the sender will transmit again that data packet. To sum up this action is
called retransmission.
So in this way services that use TCP protocol for their transport layer, are sure that their packets have
achieved that desired destination.
If the packet does not arrive in the destination, or for different reasons is not in the correct place, then
the sender will send packet again and will not be interested to learn what happed with the packet, if it
last, corrupted, or is late in its way to come to the destination. It is very simple the sender did not take
the ACK, that would prove the acknowledgment of the packet to the receiver, will send it again.
We will explain this technique better by one example that we are going to take, always with host A
and host B.( we told you that we are going to mention quite often these hosts, so do not get bored)
Host A is sending a data packet P to the host B. Sequential number of the packet P is SEQ=92 and it
will contain eight bytes of data. If packet P will arrive to destination to the host B, then host A will
wait for the acknowledgment ACK=100 from host B.
In fact host A will wait always for the ACK from host B, or to be more accurate will start waiting from
the moment it sends the packet to the network layer.
But packets have lost during transmission, and of course we do not possess the ACK from B. The host
A do not lose time thinking (it can not think in fact), but retransmit the packet in the same direction.
But what happened with the first packet? (Think about this, anyway I am sure you thought before)
Maybe it has reached the destination, but its ACK has been lost during transmission, or its ACK is in
its way to the destination to the sender, but maybe it is lost for sure. Maybe, maybe stop. Happened
what happen we should continue. So what we have done, if the packet have been lost, the problem is
simple we have sent this packet again and we are waiting for the ACK, we came to the point that we
are just how we were in the beginning.
But if the packet is in the destination place and we have sent it again, host B now has two same
packets. This is not reliable transfer but this is exactly duplication of packet! What is the role of TCP
in this part?
Host B detects that packet P is the same with the packet taken before, and the same packet is in his
buffer, so it discard it, and send another ACK to host A. Fig.3.9.
Now we hope that ACK will get to the sender, and will continue with the other packets.
This will cause us too, because we have to carry on with the explanation further.
Now we suppose that our host A have sent two data packets P1 and P2 one after other.
Packet P1 is with SEC=92 and has eight bytes, while P2 has SEQ=100 and carries twenty data bytes.
Suppose that both of them have arrived to the destination. Host B send the ACK for both of them, but
they do not reach the destination inside the time that was expected. After this, host A resend the first
packet and restart the timer again. If the second ACK arrive during this second timeout that was
restarted by the host A, this packet will not be retransmitted. Fig.3.10.
But network is network and here can happen anything, for example what if both packets were sent, but
the first ACK is lost, but the second arrive within first timeout.
Just to be more accurate, host A have received the ACK=120, before the timeout ends.
This proves that every byte until 119 is in the correct pace in the host B.

Faqja16 / 29

Socket and TCP

So why to resend another demand for ACK=100? That is the reason why host A stays without going
anything.Fig.3.11.

Fig.3.9 Double packet at host B

Fig.3.10 ACK2 arrive in ACK1 timer

Fig.3.11 ACK2 has arrived before ACK1

We mention here timer and timeout, what are these, in fact if you understood the retransmission
technique, you have an idea for what serve those, and why do we use them. But we are going to give a
clean view for these concepts.

3.4.1 Variable intervals timeout

In the last discussion we talked about TCPs capability how to know when to send a retransmission of
a packet. This is a fairly complex subject that will only be briefly discussed here.
Since data runs on an Internet that has varying delays caused by routers and low- or high-speed
networks, it is nearly impossible to determine an exact timer delay for an acknowledgment.
Every TCP implementation use an algorithm to put a timeout value to use for round trip time (RTT,
we are going to explain later) of the segments. To do this, TCP records the time at which a segment
was sent, and the time at which the ACK is received.
A weighted average is calculated over several of these round trip times, to be used as a timeout value
for the next segment(s) to be sent. This is an important feature, because delays can vary in IP network,
depending on multiple factors, such as the load of an intermediate low-speed network or the saturation
of an intermediate IP gateway. [IBM 2001]
So how we create an algorithm? Despite the fact that Internet has very heterogeneous nature this time
is quite variable, this is the reason why we should record every packet time, from the moment it leave
the source host, arrive to the destination host, and turns back with a correct ACK. This time we call

Faqja17 / 29

Socket and TCP

RTT, and we mention before the reasons that this time is not a constant, in fact is dynamic, and in this
way we have to take it.
But here is the master here, we take every RTT and using this delta, TCP builds a sample round-trip
delay time. TCP uses this time to build an average time for a packet to be sent and an acknowledgment
to be received. When it calculates a new value from another sample, it will slowly change its timer
delay for the waiting of the ACK packet.
This sample with change from packet to packet, so we have to take an average one to use in general.
Here we come with the notion EstimatedRTT, which is kind of average value for samples that we take
for RTT.
And the expression for this is:
EstimatedRTT = (1-x) EstimatedRTT + x SampleRTT(1)

We have written in the programming language. But we have done this, use just to explain that
EstimatedRTT takes the value of previusEstimatedRTT and adds to this newest value taken lie
SampleRTT.
The value of x is recommend to be taken x=0.125.
So here is the point after we have EstimatedRTT, we know the value after we will resend packet, so
this value is timeout (that I promised that we are going to explain), and if packet do not bring ACK
that we look for, we restart the timer again, which will start running from the EstimatedRTT value
until the end, where it will be zero.
But we hope now the ACK is in correct place, in contrary we have to restart again. And if we repeat
again and again these demands, for ACK that we are looking for. Where is the role of TCP? We are
going to cause congestion in network, we are going to lose the sense of fast transmissions, and cause
confusion here.
But if we want our packet, we do not have another choice. (Only if somebody has found, and we still
do not know).
3.4.2 Doubling the time interval
When we have resent a demand for ACK that we do not have, and the timeout is finished, we said
before that we have to resend again. This in previous explanations would last forever if we have such
problems, but we have TCP implementations that overcome this problem too.
TCP in such case would resend again, but would put another timeout interval. Of course you think this
is different because of formula (1), (I thought like this), but is not, TCP sets the reset timeout interval
twice that the previous one.
If the first timeout interval was set 1 ms, and now the packet was not acknowledgment this will be
another value and will be 2 ms.
And we have that famous question. What happen if this time for mentioned reasons grows
exponentially, will we get the ACK ever?
But again, this is better implemented like this, because packet do not arrive in the desalination for no
reason, they have to travel from routers to routers and from path to path, and is understandable that
they can meet congestion during their way, so they can be late, or even dropped. And if we continue to
send more requests for ACK, this part really gets worse.
That is the reason why each TCP sender resends the demand for ACK later and later.
But the last case that we have to mention here is the fact that, when TCP sender sends packet and the
receiver only resend the first ACK, the sender understands that is missing the second packet, and
performs with the fast retransmission of second packet before the timeout expires. Fig.3.12.
To sum up a retransmission occurs if the retransmission timeout expires or three duplicate ACK
segments have arrived.

Faqja18 / 29

Socket and TCP

Fig.3.12 The retransmission of three packets

3.5 Flow Control and Receiving Windows

As we have mention before TCP connection has its own buffers in both sides, in the sender and
receiver. These buffers are used to maintain the packet data for a while.
This fact tells that data packet stay in first seconds in the buffer, then they decide for their way through
specific socket and pass to the specific application layer, where are read by application layer parts.
This time that data spend in buffer is for the reason that not always receiver application are ready to
read data that come. For example application layer can be busy in another task while streams of data
want to make their path to it.
In these conditions we can not stay without thinking! How much should be the size of buffer, and are
there any possibilities that this buffer would full up with data until the border of it, before the
application layer is ready to reads them?
Well knowing that buffer is just a memory, and memories have specified capacity, the answer is
positive!
But here we have another overcome from TCP protocol, and the answer to this problem is Flow
Control.
Flow Control is mechanism, which helps TCP layer to avoid overflow of the buffer in the
sender/receiver part.
This task is performed thanks to a feedback, which minimize the data streams being sent from the
sender to the receiver and all this depends on the free space that buffer posses.
This kind of feedback which is information that receiver use to tell the sender for its free space we call
Receiver Window. This information is carried in each packet that receiver send back to the sender.
In this way, with this information and with the differences between last sent byte and last ACKed byte,
the sender is informed if the buffer is overflow or is informed for its capability to accept further bytes
of data.
And in the beginning we have said that TCP performs with streams data, which fact helps now
because in any moment can stop their flown towards network. If the packet data size would be
constant, this action (stopping data flown) would cause uncontrolled transport of them, and for sure
would cause mistakes in chopping them.

Faqja19 / 29

Socket and TCP

Fig. 3.13 Recivere window and reciever buffer

However even this TCP protocol solution, in real condition can not overcome all problematic
situations that reality can produce. One of these situations that can happen we are going to explain
here.
For example if the receiver buffer (remember host B), would become full, and the sender (host A)
would take this information then of course it would not send data anymore. In the first sight this looks
that we solve the problem. But for a moment the receiver buffer would become free, how the sender
will understand this?
By the sentences that we have written until now, we can understand that the only way that the sender
knows about buffer condition in the receiver side is by the receiver window, which is placed in a data
packet that the receiver sends to the sender.
But when the sender doses not have to send data packet?! This means that the sender will never
understand that the buffer size has become free, and it can send the other data packet.
This disability is overcame in a way that the sender always send a packet data even if they carries a
single bit, and when the receiver send back the ACK to the sender, the last(sender) takes the window
size and understands if has become free. Then if this has happened the sender continue to take more
data streams and make data packet for the receiver.
Finally to sum up all this what we have written Flow control mechanism, that works thanks to the
window size and in this way TCP protocol overcomes another chance to congestion, or uncontrolled
packet transfer.

Fig. 3.14 TCP - Window principle applied to TCP

Faqja20 / 29

Socket and TCP

Just to explain with a simple example in the fig.3.14. We have taken a graphical view that tells more
about window size.
Where:
A: Bytes that are transmitted and have been acknowledged.
B: Bytes that are sent but not yet acknowledged.
C: Bytes that can be sent without waiting for any acknowledgment.
D: Bytes that cannot be sent yet.

3.6 Congestion Control

One of the big advantages that TCP has is the congestion control algorithm. The TCP congestion
algorithm prevents a sender from overrunning the capacity of the network (for example, slower WAN
links). TCP can adapt the sender's rate to network capacity and attempt to avoid potential congestion
situations.
In a simple manner (as we trying from the start of this seminar) congestion can be explained with this
situation: a huge number of senders send packet data, with large speed in a constant network capacity.
This undoubtedly brings different problems like data bytes lost, latency in communication process. By
the fact that these situations are quite present in network, there are a lot of jobs done to handle with
this problem.
So this is the why we use the term Congestion control.
Several congestion control enhancements have been added and suggested to TCP over the years. This
is still an active and ongoing research area, but modern implementations of TCP contain four
intertwined algorithms as basic Internet standards:
Slow start
Congestion avoidance
Fast retransmission
Fast recovery [IBM 2001]
One big problem that we face up here is when a big size of data bytes are sent through the links, is the
big latency that is displayed because of ACK bytes that should be transported between sender and
receiver. This latency tries to infinite, when that size of data that pass through the link in based in link
capacity. You an see this in figure below. Fig.3.15.

Fig.3.15 Congestion control

Here we don have taken the fact of lost bytes in buffers and routers that the data bytes pass through
the path to the destination. If we take into consideration even this fact, that when the data speed grows

Faqja21 / 29

Socket and TCP

through the link, and the grow ness becomes in that point that cause that the data bytes in the router
can be processed less than the data that can achieve the buffer, then here it starts the problem.
Depend on the size of buffer, after a while the data will start to get lost. In this way the sender have to
retransmit again those data packet.
In addition, how many data packet get lost in buffer, will cause the degrees of the communication
system.
Despite those all problems, which we have talked before, we have more. Ridicules but this is the truth.
This thank to the fact that data packet pass through a lot routers and different paths, but still some of
them pass through more routers than others.
If we have the time that we face with a lot traffic (so the packet data from host to host is quite large),
the data packet that pass through less routers have more possibility to be saved in buffer, in contrast
others that have passed through more routers have less possibility to be saved.
While we are talking here until now, we are sure that the concept of the congestion control is being
clear, so we do understand that congestion control is TCPs characteristic.
This can be explained further by a simple example that will help us to get a better view for this
subject.
During a normal transmission of the data packet from host A to host B, for a number of bytes we have
taken a ACK but for some of others bytes happens that their ACK is becoming late for a while.
Meanwhile a sender can still send packet data under supposition that before datas configurations are
going to come in moments.
But now TCP use congestion control, which is used to control the number of data packet sent and not
being acknowledged.
This control specifies a number in which is based on, and is used to know the number of data packet
that we can sent without getting a ACK form them, this specified number we call Congestion Window.
With this number that is decided we degrees the possibility of losing data. But here is our question.
How much this threshold should be?
If this number is little, then we do not posses good use of link, the reason is that the number of data
that can pass through is small.
In contrary if we put this number larger one, this threshold would cause larger data place reserved in
buffer, but this can result in data loss too, and we do not need this. So we have to put a correct number
that will not cause these actions described above. That is the reason why this threshold is not a
constant, but is variable number, and it depends on the traffic size. So this threshold changes nonstop
during time.
This number is configured in that way that in the beginning of transmission is small and it gets longer
time by time, always tending to have all ACKs.
When those ACKs start not to come back to the sender, so the packet data start to be lost in their way
to the destination, TCP degrees this threshold until it gets the ACKs that was searching for.
When this is achieved TCP start again to increase this number, threshold or window until has the
ability to maintain with the capacity.
To be more accurate we will take an example here. We have host A and host B that we would like to
use here again. Lets suppose that the connection between them is established (handshaking procedure
is finished), and in fact packet are in their way towards network.
By the fact that application process, host A, want to send data using the TCP protocol, this will
maintain Congestion control in this way.
Divide the streams in segments, and send only the first segment in network, (his congestion window
has one segment). Then wait for ACK for the first segment. So here it comes ACK for the first
segment, and host A send another two segments too( his congestion window now has 2 segments), and
after their ACKs reach destination in the A host, then host A send another four segments, (his
congestion window now is four) and wait. Fig.1.22.
As a conclusion, we can say that the Congestion window is growing in exponential way. And this will
continue growing in exponential way until the window congestion will reach the threshold, then it
stops growing like this. Anyway it will not stop growing all, but now it will grow in linear way.

Faqja22 / 29

Socket and TCP

Because, when it comes to the point that the TCP has passed the threshold, the congestion window
will free place just one by one, so when the destination host send back an ACK to the sender, the
window congestion will have a free place.
The TCP congestion window (cwnd) controls the number of packets/bytes that a TCP flow may have
in the network at any time. A bulk application will always have data available to transmit. The rate it
sends is therefore limited by the maximum permitted by the receiver and congestion windows. In
contrast, a variable-rate application may experience periods when the sender is either idle or is unable
to send at the maximum permitted rate. This latter case is called application-limited. [GFIB 2011]

Fig.3.16 Exponential increase of window congestion

But imagine, until when the Congestion window will continue to increase?
This window will continue to increase, until some of our packet that was been sent will not bring back
the ACK that sender is waiting for, normally during the timeout that the sender have put.
In this case TCP protocol provides degrees of the threshold in exponential way too.
In our previous example the TCP protocol will degrees the threshold twice.
In this way Congestion window will have place for one segment.
After the threshold is passed, then congestion window will be increase in exponential way, after a
while it stars the procedure of linearity and continue in this way again and again. Fig.3.17.

Fig.3.17 Evolution of TCP's congestion window

Faqja23 / 29

Socket and TCP

If we put all those that we have said until in a graphical view, we can see the grow ness completely
exponential in the beginning. Then we can see the linear grow after the first threshold, then again the
exponential grow which differ very little with the previous linear.
So here we can make an approximation, and take the last grow linear too.
The first phase that is the face with exponential grown, we call slow start (the phase that data start to
flow). After the slow start, it comes the normal grown that we call additive. So both of them we call
additive-increase, multiplicative decrease (AIMD) algorithm that is implemented by TCP protocol.
This procedure we know like Tahos algorithm.
For the same reason is used Renos algorithm but the last one (Reno) implements fast retransmission
mechanism too.
What is fast retransmission mechanism?
Fast retransmission avoids having TCP wait for a timeout to resend lost segments. So when the sender
send packet and the receiver sends three times ACK, the sender understand that the packet after this
ACK has lost and send this back again.
There are different congestion control algorithm but TCP uses Renos one.

3.7 Termination of connection

Finally, TCP must be able to gracefully terminate a connection. We tried to explain every thing that
can happen during a connection when is used TCP as a transport protocol, but host A and host B will
not stay all life sending/receiving data packets, so in a moment there has to be a last
packet sent. But how is this performed?
First (do not worry here in fact is the end), any of the two parties involved in exchanging data (client
or server) can close the connection, although it is usually initiated by the client.
This is done by using the FIN bit in the TCP header. And by the fact that the connection is full-duplex,
each side (host A and host B) must be aware for this process.
In our famous example, host A want to terminate the connection and start this by sending a packet to
host B with a FIN bit set.
Host B take the packet and no longer accepts data from host A. Now host B can still accept data from
its application layer, to send to host A.
Host A despite the fact that want to end the connection still acknowledge the application data from
host B, it has to wait until the host B send a FIN bit set packet.
Host A receive this FIN bit packet and send the ACK to host B. Host B take the ACK from host A,
and now for sure, is the end.
No more data are sentanyway, until the next connection (We are not going to talk about the
second connection).

Fig.3.18 The termination of connection

Faqja24 / 29

Socket and TCP

3.8 Configuration of TCP

To be able to use TCP services we need to be able to perform the configuration of this protocol, so we
have given a short description of this duty.
Both sides of link source and receiver must be configured to support configuration of TCP.
This would make possible window scaling or the default of 65,535 bytes will apply as the maximum
window size. In table below we have introduce useful steps for this task, and the explanation of the
steps.
To support ECN, the remote peer must be ECN-enabled because the ECN capability is negotiated
during a three-way handshake with the remote peer.[CIS 2011]
Table 3.2.
Steps
1

Command or Action
enable

Purpose
Enter your password if prompted.

configure terminal

Enters global configuration mode.

ip tcp synwait-time seconds

Sets the amount of time the Cisco IOS software

will wait to attempt to establish a TCP connection.

ip tcp path-mtu-discovery
[age-timer {minutes |
infinite}]

Enables Path MTU Discovery.

ip tcp selective-ack

Enables TCP selective acknowledgment

ip tcp timestamp

Enables the TCP time stamp.

ip tcp chunk-size characters

Sets the TCP maximum read size for Telnet or

rlogin.

ip tcp window-size bytes

Enables ECN for TCP. Sets the TCP window size.

ip tcp ecn

Enables ECN for TCP.

10

ip tcp queuemax packets

7
8

Sets the TCP outgoing queue size.

Faqja25 / 29

Socket and TCP

Conclusion
In this project we have tried to explain shortly Socket as a connection between application and transfer
layers, and TCP as a successful protocol in TCP/IP suit.
As we have promised in the beginning of seminar, we have tried to explain TCP protocol in a way
which, even for the reader who is not very familiar with such things, will find something interesting,
first to understand and then learn too. But, in the other hand, this doesnt mean that the reader, who is
familiar with computer network, couldnt profit anything from this project.
We have started this project with an introduction, in which we talked about the protocols of different
layers in general, and their logic of performing their tasks. Continuing with description of interface
between two highest layers, which is called Socket and its important role.
Next, we explained TCP protocol in some details. Starting with what does the TCP protocol do with
data packets, how does it realize the connection between processes in different hosts?, then describing
the techniques which TCP use to realize a reliable data transfer (especially retransmission techniques),
which is one of the most important properties of TCP.
Finally, we treated some of the problems of these communications, and some of the mechanisms to
manage these, such as flow control and congestion control.
To sum up if the data are sent by TCP, it is absolutely sure that these data will go from source to
destination uncorrupted and in the right order.
If we dont add anything else after this sentence, it can be predicted that TCP is an ideal solution for
communication. Unfortunately, this is wrong.
Always by the project, it can be seen that the techniques which are used by TCP, exactly those
techniques with which is achieved reliable data transfer, produce delays and other problems like this.
These problems perhaps cannot be significant to transfer data, but surely these are absolutely
unbearable for audio and video content transfer (especially in real time communication). For these
reasons, TCP is not used in such forms of communication, and now the other rival, UDP comes to
scene.
But in our opinion, we think that the grown of hardware power, which has caused the development of
software possibility and other improvements too, will soon cause for TCP to overcome this problem.
By reaching the bit rate which is happening time by time, improvement in physical layer, we are
optimistic that TCP will soon perform with reliable and very fast data transfer.

Faqja26 / 29

Socket and TCP

Bibliography
[JKKR 2010]

James F. Kurose and Keith W. Ross, Computer Networking A Top-Down

Approach Featuring the Internet, 2010.

[GFIB 2011]

G. Fairhurst, I. Biswas "Updating TCP to support Variable-Rate Traffic",

December 24, 2011

[CIS 2011]

CISCO " Configuring TCP" 16 November, 2011

[IBM 2001]

IBM, TCP/IP Tutorial and Technical Overview, August 2001

[MC 2003]

, Adolfo Rodriguez, John Gatrell, John Karas, Roland Peschke,TCP /IP

Fundamentals for Microsoft Window, Microsoft Corporation,
ibm.com/redbooks, 2003

[OReilly 1999] Craig Hunt, TCP/IP Network Administration, O'Reilly & Associates, 1999
[BFSF 2007]

Behrouz A. Forouzan, Sophia Chung Fegan, DATA COMMUNICATIONS

AND NETWORKING, McGraw-Hill Forouzan Networking Series, 2007

[MN 1998]

Matthew G. Naugle, Illustrated TCP/IP, Wiley Computer Publishing, John

Wiley & Sons, Inc, 1998.

[SM 2000]

TCP/IP Network Administration, Sun Microsystems Inc., 901 San Antonio

Road, Palo Alto, California, 2000

[SV 2002]

Steven Low, TCP Congestion Control: Algorithms & Models,

netlab.caltech.edu IPAM, 2002.

[BH 2001]

Brian "Beej" Hall, Using Internet Sockets, Beejs Guide to Network

Programming
HYPERLINK "mailto:beej@piratehaven.org" beej@piratehaven.org , 2001.

[NS 2006]

Nikhil Shetty, Socket ProgramminSocket Programming, GSI, EECS122

Spring 2006.

[KC]

Kameswari Chebrolu, Socket Programming, Dept. of Electrical Engineering,

IIT Kanpur

[RFC 793]

J. Postel, "Transmission Control Protocol", September 1981

Faqja27 / 29

Socket and TCP

Appendix 1

Abbreviations
AIMD
API
DNS
ECN
ECN
FTP
HTTP
IBM
IP
ISN
MSS
MTU
OS
OSI
RFC
RTT
SMTP
TCP
UDP

additive-increase, multiplicative decrease

Application Programming Interface
Domain Name System
Explicit Congestion Notification
Explicit Congestion Notification
File Transfer Protocol
Hypertext Transfer protocol
International Business Machines
Internet Protocol
Initial Sequence Number
Maximum Segment Size
Maximum Transmission Unit
Operating System
Open System Interconnection
Request For Comments
Round Trip Time
Simple Mail Transfer Protocol
Transport Control Protocol
User Datagram Protocol

WAN

Wide Area Network

Faqja28 / 29

Socket and TCP

Appendix 2

List of Figures

Number
1.1
1.2
2.1
2.2
2.3
2.4
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
3.10
3.11
3.12
2.13
3.14
3.15
3.16
3.17
3.18

Description
TCP/IP Protocol layers
Communication
Socket address
Establishment of path for two-way communication between a client and server
Application layers and the interaction with socket
Socket mechanism
Connection Oriented protocol
Three way handshake
Streaming transportation between processes
TCP segments and buffers
TCP segment structure
Connection principles
Active and Passive open
TCP data stream
Double packet at host B
ACK2 arrive in ACK1 timer
ACK2 has arrived before ACK1
The retransmission of three packets
Recivere window and reciever buffer
TCP - Window principle applied to TCP
Congestion control
Exponential increase of window congestion
Evolution of TCP's congestion window
The termination of connection

Faqja29 / 29