Reliable Networking Systems

curvyrawrNetworking and Communications

Oct 23, 2013 (4 years and 18 days ago)

90 views


Reliable Networkin
g Systems



1

Reliable
Networking
Systems


Implementation of

a
r
eliable network application

of a

file sharing network.






15
/
06
/
08

Document Version: 1.0





Galina Sagdeev

Iliya Golub



Supervisor:
Yonatan Kaspi






Software Systems

Laboratory

EE Faculty


Technion


Reliable Networkin
g Systems



2


Contents:


1.

INTRODUCTION

................................
................................
................................
.......
3

1.1.

G
ENERAL

................................
................................
................................
........

3

1.2.

G
OALS OF THE
P
ROJECT

................................
................................
...............

3

1.3.

T
HE
OSI

M
ODEL

................................
................................
...........................

3

1.4.

T
RANSMISSION
C
ONTROL
P
ROTOCOL


TCP

................................
............

4

1.4.1.

Connection Establishment

................................
...........................
5

1.4.2.

Data Transfer
................................
................................
.................
5

1.5.

U
SER
D
ATAGRAM
P
ROTOCOL


UDP

................................
........................

6

2.

IMPLEMENTATION

................................
................................
................................
7

2.1.

D
ESIGN
................................
................................
................................
............

7

2.1.1.

Gui

................................
................................
................................
...
8

2.1.2.

Network Manager
................................
................................
..........
9

2.1.3.

Events Handler

................................
................................
..............
9

2.1.4.

TX
................................
................................
................................
..

10

5.1.2
.

RX
................................
................................
................................
..

11

2.1.6.

Timer Udp
................................
................................
....................

12

3.

SUMMARY

................................
................................
................................
................

13

3.1.
1.

Problems

................................
................................
......................

13

3.1.2.

Expansions

................................
................................
..................

13

4.

REFERENCES
................................
................................
................................
..........

14

























Reliable Networkin
g Systems



3

1.

Introduction

1.1.

General


In t
he RNS

project we build a

reliable networking systems

application with a demo.

The body of the system implements a network that can transmit and receive data using
TCP or UDP protocols

reliably
, m
eaning that there is a guarantee that transmitted file

will be received.



Graphical user interface is used to demonstrate a use of the body system.

It
implements a file sharing application between two remote systems, where local
system downloads files from the remote one.







1.2.

Goals of the Project


The goal
s of this project are:



Learn Java language and using Java networking packages



Learn Multi
-
threaded application programming



Support
concurrency



Implement Reliable Network transmission based both on TCP and UDP



Implement Graphical User Interface



1.3.

The OSI Mo
del


The
Open Systems Interconnection Basic Reference Model

is a layered, abstract
description for communications and computer network protocol design. It was
developed as part of the Open Systems Interconnection (OSI) initiative and is
sometimes known as
the
OSI seven layer model
. From top to bottom, the OSI Model
consists of the Application, Presentation, Session, Transport, Network, Data Link, and
Physical layers. A layer is a collection of related functions that provides services to
the layer above it a
nd receives service from the layer below it. For example, a layer
that provides error
-
free communications across a network provides the path needed by
applications above it, while it calls the next lower layer to send and receive packets
that make up the c
ontents of the path.
1


Reliable Networkin
g Systems



4



The physical layer is about the definition of the physical specifications, such as
voltages, cables etc
. A common examples of

it is Ethernet and IEEE 802.11.


The data link layer describes the means to transfer data between two network entities,
such as order of bits, preambles, the means to correct and/or detect errors.


The network layer provides a means
to communicate between two

or more points in
the same or

different networks
.
The most known example of this layer is the Internet
Protocol (IP). It provides a standard formatting of data, as well as detecting errors and
fragmenting data packets to fit into

specific underlying network that the packets must
travel through
.


The transport layer is responsible for communicating data between users. In this layer
the most commonly known protocols are UDP and TCP, the characteristics of which
are discussed below:



1.4.

Transmission Control Protocol


TCP


The TCP protocol uses the services from the third layer IP protocol to achieve the
following characteristics




TCP is connection oriented protocol. I.e. A connection between two users
must be established before sending

data and terminated afterwards



TCP is a reliable protocol. I.e. all the data that is sent from one user to another
user arrives without any mistakes in data and without any data loss.



TCP has a congestion control mechanism. If the underlying network is bu
sy
due to some reason (like many users for instance) the TCP can adapt to the
condition and reduce traffic to avoid congestion in future.




Reliable Networkin
g Systems



5


The
mechanism
s that allow

the
TCP achieve the following characteristics are
described below:


1.4.1.

Connection Establishm
ent


To start establishing the connection the Server must bind to a specific port. Once this

is done the Client can start the connection negotiation. This is done in the following
manner:



The client sends a SYN to the server (synchronization packet)



In res
ponse the server replies with SYN
-
ACK



As a result the Client sends the ACK to the server


1.4.2.

Data Transfer


The TCP is a stream oriented protocol. I.e. the data between two users is ordered in a
single stream. The first byte is the beginning of the stream and

any other byte has
its

sequence number inside the stream. It is important to understand that the user of the
data (higher layer in OSI) only sees continuous data in an ordered manner without
being broken to messages (byte 1, byte 2, byte 3, … , byte N)

In

contrast a non stream oriented protocols, for example SCTP, presents the data to
the upper layer by messages (message 1 : 1000 bytes, message 2 : 1000 bytes, ….)


T
he underlying protocols present

several things that the TCP has to deal with:



The TCP strea
m is broken to s
mall portions, called packets. Each packet
carries a size of data with the sequence number of this data in the stream
.



A packet may be lost in the
network. Thus TCP implements
acknowledge and
retransmission mechanism to prevent loss of data
.



A packet may duplicate in the network or arrive out
-
of order (example stream
bytes 1000
-
2000 arrive before stream number 500
-
999). Thus the TCP
implementation must order the packets in the right order, and ignore the
duplication
.



Also there could be
cong
estion

somewhere in the
network, which results in
loss of packets and also in bad performance (throughput). Thus the TCP
provides congestion avoidance / recovery mechanism
.


To acknowledge the data and also to avoid congestion
,

the sliding window
mechanism

is implemented in TCP. For e
ach segment of data there is an
acknowledge. However the sender can send several data fragments before getting a
sing
le acknowledge,

to enhance performance. The size of the data that can be sent is
defined by the window size. W
hen acknowledged the window moves to a new point
and thus more data can be sent.

When all is ok the windows size can slowly increase. However if a retransmission
needed there is a concern for a congestion and the window is halved (from there it
will slowl
y increase if no losses, or will be halved if additional losses)
.


Reliable Networkin
g Systems



6

1.5.

User Datagram Protocol


UDP


Unlike TCP the UDP protocol is:



Connectionless


no connection is required to send data



Does not guaranty data reliability



Does not guaranty data order



Not stre
am oriented
-

datagrams if arrive, arrive in the same way they were
sent. Not concatenated in a single stream


The UDP can be used in two manners:



For implementing user defined reliable protocol, that can be optimized for a
specific need and work better th
an UDP



For implementing unreliable data delivery, that may be required by some
application (like real
-
time video delivery


if some frame is lost it shouldn’t be
retransmitted because it is already time for different frames)


In our project we implement a
reliable protocol based on UDP. The protocol
organizes the received packets and cares for requesting missing packets.







Reliable Networkin
g Systems



7

2.

Implementation


I
n this chapter the RNS

design

and implementation is presented. As wel
l as a
description of each class
.

2.1.

Design


The

design presented

below was developed
.


The current application supports a download of files from remote system to the local
one, but it can be converted to support multiple systems. This requires making
changes in the application cover: Network manager an
d the Gui classes. But the body

classes don't need to be affected since they are built for multiple systems use.

Further

more, it doesn't have to be used for file download but for any other type of
data transfer. In this case the Read file and Write file c
lasses should be changed
according
to
wanted

functionality of

data receive and transfer.




Reliable Networkin
g Systems



8

2.1.1.

Gui


The Gui



graphical user interface,

is an implementation of INWclient interface.

It
c
onnects between the client and the
network
system
. It h
olds
instance of ne
twork
manager
activates it

and sets client configurations

for the system
.

The class builds

graphical

interface using

javax.swing
. The interface supports a
download of files from remote system to local system.


The files available for download are held wit
hin the class and displayed to the user.

In
order to start the download the following steps must be done:


1. S
elect file from download list by picking on it.


2. S
elect wanted timer type
, can be set once

(see Timer Udp chapter)
.


3. S
elect protocol: TCP
or UDP
.


4. Press the download button.

For next downloads step 2 is
skipped
.


Downloaded file appears in the local files window. The progress can be traced from
the log window where system messages are displayed. The download percentage
appears in the prog
ress bar.


The
class

has the following functions:


constructor



B
uilds the GUI window, initializes all data
structures
.


activateNetman



G
enerates random ports for the UDP and the TCP systems and
activates the network manager instance.

Random ports shoul
d be replaced by the
actual ports assigned for this
application;

they are used only for debug need.


getFile



S
ends request to Network Manager to download a file.
Displays
appropriate
messages.


receivedFile



I
ndication that file was received. Displays a
ppropriate messages and
updates the local files list.


displayErrorMessage
-

Displays error message

in log window

and exits.


displayMessage



Displays message in the log window.


setProgressVal



Update the progress bar according to the received data.


ge
tOneFiles



R
eturns local files list


getTwoFiles



Returns remote files list.


keepLogSize



Keeps number of lines displayed by the log window to be
logSize
,
constant that is set in the class.
Done b
y deleting the oldest
events
.


Reliable Networkin
g Systems



9

2.1.2.

Network Manager


The netwo
rk manager is a class that holds and manages the whole network

system
.

It
is r
esponsible to perform the system tasks and inform the client (GUI) about the
progress.

It has an instance of the client that is received as a parameter in the
constructor, so tha
t the network manager will be able to call client methods and by
that communicate with it.


The class supports a download of files from remote system to the local one.


It h
olds and activates the

following parts of the system:
e
vents queue and events
han
dler
,
l
ocal TCP and

UDP system
s,
r
emote TCP and
UDP system
.

Each system has TX and RX

classes which functionality is

explained below.



Network manager supports the following functions:


callTcpTX



activates the TCP transmission of given file from the re
mote system.


callUdpTX



activates the UDP transmission of given file from the remote system.


getPackets



request to transmit the packets given in array. This function is used by
UDP receiver.


getFile



handles request from the client to receive a file
.


receivedFile



sends notification to the client that file was received successfully.


errorMessage



sends error message to the client (see events handler chapter).


message



sends message to the client (see events handler chapter).


setProgressVal



n
otifies the client about the file download progress.



2.1.3.

Events Handler


The events handler is a thread ran from the network manager. It is responsible to
synchronize

the events in the system.

In order to communicate with the network
manager, each of the sub

classes
writes a message to

Events Queue

-

thread safe data
structure.


The events handler reads

event
s

from the queue and
process
es

them.

At first it checks
whether the event is valid

and for each event type it performs the required action.

This
method
prevents

race hazards
-

the classes in the system exchange data by putting
events in the queue

and the events are handled one by one
.


The event types supported are: get file, file received, message and error message.



Reliable Networkin
g Systems



10

Get file

-

is a request to download a

file using TCP or UDP.

File received

-

is a notification that it was
successfully

received.


Message

-

is other kind of notification to the network/user that doesn't caused by
system failure. For example notification that packet number N is received.


Err
or message

-

caused by system failure after which the application should exit.



2.1.4.

TX

TCP


The TX class
is responsible to transfer given file th
rough

the port it is connected to

using TCP
.

It calls a sub class called WriteFile

which
s
ends

the file as

a stre
am of
data
.


The WriteFile

class receives the name of the file to transmit

and
a

port

number.

It
creates data input stream from the file, divides it to packets and transmits them one by
one.
The file is divided to
num_of_packets

packets, constant

set

withi
n the class.

Later on a TCP socket is opened and connected to data out put stream

through

w
h
ich
the packets are sent.

At first step the file information
:

number of packets, file length
,

packet length, file name,

is send
. Then
all packets are sent by readin
g the calculated
amount of bytes from the input stream and writing them to the output stream.

At the
end the steams and the sockets are closed.


We will add that the TCP is a reliable protocol so that it is
guaranteed

that the
packets
will reach the destin
ation
,

and we don’t need to
take care of th
is aspect in this

application

(opposite to UDP)
.


UDP


The TxUdp class is responsible to transfer
given
using UDP
,

and to handle requests to
resend packets.

It calls a sub class called WriteFile
Udp
,

which
s
ends

t
he file as

datagram packets
.

The class

receives the name of a

file to transmit and a port number
.

It opens datagram
channel and sends datagram packets through cannel’s socket.

At first

4

packets
containing the file info is send
: number of packets, file le
ngth, packet length, file
name.

The packet length is a constant set in the
class,

number of packets parameter is

calculated according to it

and the length of the file
.


Each

datagram packet

contains identifying number

so that the receiver can organize
them
. T
he info

packets have negative identifier
,

while the data packets contain their
sequenced number.


The file is
saved in array from which the needed packets will be read and transmitted.


Reliable Networkin
g Systems



11

Data packets are transmitted when the getPackets
function

is called.

Array with
numbers of requested pa
ckets is received, each packet number is translated to indexes
in the file array which are read and sent as datagram packets through the cannel
socket.



The function also simulates a lost of some packets
in order
to chec
k packets re
-
request
algorithm.
It is simply generates a random number and by it decides
whether

to send
the packet or not.



2.1.5.

RX

TCP


The RX class is responsible to receive
a stream of data
. Instead of opening thread for
each
file

received it uses a select
or which
controls the input of data from various
sources
. S
o

instead of using many threads

and
consuming system
resources,

it uses
system threads which
makes the
application

more efficient.


The Rx is a thread which

is ran once when the system starts. It c
alls OurSelector class.
The

class
contains instance of java selector implementation and opens it at the start.

It
also opens a server socket channel and binds
its

socket to the
given

port & host.

T
hen
infinite loop is started
.
Within

the loop

the selector
selects a pending request in the
channel
, accepts it and hand it over to ReadFile class.



ReadFile class is responsible to receive a file sent via TCP
, so

it doesn’t need to check
the received data since TCP is a reliable protocol.


UDP


The RxUdp

class i
s responsible to receive

datagram packets
,
organize the packets in
the correct order and re
-
request missing packets using
TimerUdp
.


It is

a thread
that

is ran once at system start.
I
t calls the UdpSelector class
which

also
uses a java selector

as describe
d

for TCP

above.

UdpSelector class opens datagram
channel, binds it to the given host & port, and registers it with the selector.

Afterwards
infinite loop is started. Within the loop the selector selects a pending request in the
datagram channel, accepts i
t and hand it over to ReadUdp class.



As ReadUdp receives
4
datagram packets with file info
:
num

o
f

p
ackets,

file length,
packet length

and

file name
, it is ready to receive the data packets.
T
he data packets
are

written

to array

according to their sequen
ced number, since in UDP packets may
arrive out of order.
A special array holding the number of received packets is updated
so that the
TimerUdp

class will be able to re
-
request
missing packets
.

ReadUdp class
has
finishReceiving

function, which is called f
rom TimerUdp when all packets
received.

It writes the file array to new file, initializes all parameters and notifies
Network manager that the file was received.




Reliable Networkin
g Systems



12

2.1.6.

Timer

Udp


This class is a thread started once at the UdpSelector beginning.

It receives an
istance
of the ReadUdp class to get a necessary data about file receiving progress.


I
t also receives the timer type

which is set by the user in Gui
.
There are two possible
timer types
:

constant timer and changing timer.

Timer type
determine
s

which

functio
n
will run

as the tread starts, so it can be set once and
cannot change
during the run of
the application.



The constant timer a
ctivates every T milliseconds
, is a parameter set within the class.

It gets the array of received packets from ReadUdp class an
d requests
NumReqPackets

packets,
NumReqPackets

is also parameter set in the class. The
packets requested may be missing packets that were requested and didn’t arrive, or
newly requested packets.

If all packets are received
ReadUdp

finishReceiving

function

is called. This function explained in Rx Udp part.


The c
hanging timer

activates every T
milliseconds

and requests N packets each time.

Its functionality is similar to constant timer except that
T and N are parameters that
are changing during the run as
following:

If requested packets weren’t received, T is increased and N is decreased.


timeout *= timeIncFactor

numPacks /= packsDecFactor

If requested packets are received, T is decreased and N is increased.


timeout
-
= timeDecFactor

numPacks += packsIncF
actor


When timeIncFactor, packsDecFactor, timeDecFactor, packsIncFactor
,
maxNumReqPacks, minNumReqPacks, maxtimeOut, mintimeOut
are parameters set
in the class and can be matched to application
's
specific

use
.





Reliable Networkin
g Systems



13

3.

Summary

3.1.1.

Problems


During the project imple
mentation we experienced several difficulties:




Using the java selector implementation
in

TCP and UDP receivers.

The

difficulty was caused mainly because this class is not
well
documented

and it's
hard to understand how to use it. Also the use of this clas
s is different for UDP
and TCP.



Additional obstacle was that we needed to change the UDP implementation
entirely
since

the original

implementation wasn't
correct
.



3.1.2.

Expans
ions


The project can be further
expended in several ways
:




Support
of multiple syst
ems can be added, it
currently implements two
systems (local & remote).



Support initial connection between systems (handshakes, exchanging file lists,
etc.).



Implement more complicated algorithms for the Timer.



Reliable Networkin
g Systems



14

4.

References




1.

wikipedia.org

2.

http://java.sun.com/j2se/1.4.2/docs/api/index.html

3.

http://j
ava.sun.com/docs/books/tutorial/networking/index.html

4.

http://java.sun.com/docs/books/tutorial/essential/concurrency/index.html

5.

TCP/IP Illustrated, Volume 1: The Prot
ocols
, Addison
-
Wesley, 1994, ISBN 0
-
201
-
63346
-
9.