cn project reportcs.lamar.edu/faculty/osborne/5328/fall10/team6.pdf · cyclic redundancy check of...

Remote File Synchronization Group 6

1

PROJECT REPORT

ON

Remote File

Synchronization

Computer Networks

SUBMITTED TO :-

Dr. Lawrence Osborne

SUBMITTED FROM :-

Rishi Dhanju

Kachhadia Bhumika


2

ACKNOWLEDGEMENT

We are very much thankful to Dr. Lawrence J. Osborne for giving us a great

opportunity to learn various concepts in the Synchronization of file and to

implement a Project on Remote File Synchronization. We are very grateful for

helping us with any query that we had during the whole project which helped us to

gain a lot of valuable information.


3

ABSTRACT

The problem that we have focused in this project is the File Synchronization. We

have to develop prototypes in such a way that the client and server have same files

at a given time i.e. the files are synchronized.

Project covers the basic aspects of File Synchronization and File Transfer. We

have tried to make our network as reliable as possible using following features

Cyclic Redundancy Check of packets at Client and Server side, Sequence number

of sending and Receiving packets. Basically, we take check timestamps at both the

client and server side and copy the files accordingly to make both the files

synchronized.


4

Table Of Contents

1. PROJECT PROFILE ........................................................................................................... 5

2. ABOUT SYSTEM ................................................................................................................. 6

3. SYSTEM ANALYSIS ........................................................................................................... 7

3.2 C (PROGRAMMING LANGUAGE) ............................................................................................ 7

3.3 GRAPHIC USER INTERFACE ................................................................................................... 8

3.4 CLIENT .................................................................................................................................. 8

3.5 SERVER ................................................................................................................................. 8

4. DESIGN OVERVIEW :........................................................................................................ 9

5. FEASIBILITY STUDY ........................................................................................................ 9

5.1 OPERATIONAL FEASIBILITY .................................................................................................... 9

5.2. TECHNICAL FEASIBILITY ..................................................................................................... 10

5.3. SCHEDULE FEASIBILITY ....................................................................................................... 10

5.4. ECONOMICAL FEASIBILITY .................................................................................................. 10

6. SYSTEM DESIGN .............................................................................................................. 11

7. WORKING OF OUR PROJECT ...................................................................................... 15

8. TRIVIAL FILE TRANSFER PROTOCOL (TFTP) :- ................................................... 16

8.1 FINITE STATES MACHINES (TFTP 2010) ......................................................................... 16

8.2 DESIGN TO IMPLEMENT TFTP ........................................................................................ 17

8.3 NETWORK PACKET DESIGN ............................................................................................. 17

8.4 RELIABILITY IN UDP IMPLEMENTATION ......................................................................... 18

8.5 USER INTERFACE DESIGN................................................................................................ 18

8.6 NETWORK SUPPORT DESIGN ........................................................................................... 18

8.7 FILE SYSTEM MODULE DESIGN ........................................................................................ 19

8.8 RELIABILITY DESIGN ...................................................................................................... 19

9. ADDITIONAL FEATURES .............................................................................................. 19

9.1 FILE SYNCHRONIZATION ...................................................................................................... 19

9.2 CRC- CYCLIC REDUNDANCY CHECK ................................................................................... 20

9.3 SEQUENCE NUMBERS AND ACKNOWLEDGMENT NUMBERS:- ............................................... 20

9.4 TIMEOUT AND RETRANSMISSION:- ....................................................................................... 20

9.5 ROUND TRIP TIME (RTT):- ................................................................................................... 21

10 TESTING ............................................................................................................................. 21

10.1 TESTING OBJECTIVES ..................................................................................................... 21

10.2 TEST CASES .................................................................................................................... 21

11 FURTHER ENHANCEMENT .......................................................................................... 23

12 BIBLIOGRAPHY ............................................................................................................... 23


5

1. Project Profile

The problem that we have focused in this project is the File Synchronization. We have to develop

prototypes in such a way that the client and server have same files at a given time i.e. the files are

synchronized.

Project covers the basic aspects of File Synchronization and File Transfer. We have tried to make our

network as reliable as possible using following features Cyclic Redundancy Check of packets at Client

and Server side, Sequence number of sending and Receiving packets. Basically, we take check

timestamps at both the client and server side to make both the files synchronized.

Purpose: - The purpose of this project is to explore a service specific and reliable file transfer

protocol using UDP. This project is being developed in SUN SOLARIS system and main purpose is to

understand main issues that arise in File Synchronization.


6

2. About System

Project Name Establishment of File Synchronization Protocol with an effort to make the

File Transfer as reliable as possible using UDP. (TFTP)

University Name LAMAR UNIVERSITY

Project Guide Dr. Osborne

Project Team

Rishi Dhanju

Bhumika Kacchadia

Project

Description/Narrative

The problem that we have focused in this project is the File

Synchronization. We have to develop prototypes in such a way that the

client and server have same files at a given time i.e. the files are

synchronized.

Project covers the basic aspects of File Synchronization and File

Transfer. We have tried to make our network as reliable as possible

using following features Cyclic Redundancy Check of packets at Client

and Server side, Sequence number of sending and Receiving packets.

Basically, we take check timestamps at both the client and server side

and copy the files accordingly to make both the files synchronized.

Front End Tools C Programming, Graphic User Interface, SUN SOLARIS (OS), CLIENT (1),

SERVER (1).

Back End Tools Files

Project Duration NOV-2010 to DEC-2010


7

3. System Analysis

3.1 Sun Solaris (operating system) (Sun Solaris n.d.)

Solaris is a Unix operating system introduced by Sun Microsystems in 1992 as the successor

to SunOS.

Solaris is known for its scalability, especially on SPARC systems, and for originating many

innovative features such as DTrace and ZFS. Solaris supports SPARC-based and x86-

based workstations and servers from Sun and other vendors, with efforts underway to port to

additional platforms.

Solaris is certified against the Single Unix Specification. Although it was historically developed

as proprietary software, it is supported on systems manufactured by all major server vendors, and

the majority of its codebase is now open source software via the OpenSolaris project.

. Its features include:-

• Security

• Observability

• Performance

• Networking

• Virtualization

• Data Management

• Interoperability

3.2 C (Programming Language)

C is an imperative (procedural) systems implementation language. It was designed to be

compiled using a relatively straightforward compiler, to provide low-level access to memory, to

provide language constructs that map efficiently to machine instructions, and to require

minimal run-time support. C was therefore useful for many applications that had formerly been

coded in assembly language.


8

3.3 Graphic User Interface

My GUI has two Text Fields, one Button and a Message Box. One text field takes server name as

an input and other ask for the choices to select for the user :- rlist, llist and rsynch. The result of

these three commands is displayed in the message box. The button when clicked causes all these

commands to occur.

3.4 Client

My project works for one client at a single time.

3.5 Server

My project works for one server at a single time.


9

4. Design Overview :

The project requires a communication between servers and client. We used C to implement this project.

To make a communication between servers and client in C can be achieved by two ways. One is by RPC

and other is by socket programming. We used Socket programming (Calvert n.d.)to create communication

between client and servers. We studied Unix Network Programming book by Stevens to get knowledge of

how sockets works and functions which make communication possible between two machines. Apart

from this book the example given by Dr Osborne was really helpful.

5. Feasibility Study

The feasibility of a project can be ascertained in terms of technical factors, economic factors, or both. A

feasibility study is documented with a report showing all the ramifications of the project.

Initially, I explored internet and referred to many books, papers, presentations & sites regarding

the related technologies like networking etc. for feasibility study point of view.

The four categories of feasibility tests are:

5.1 Operational Feasibility

Operational feasibility measures how well the solution will work in the organization and how will end-

user and management feels about system. Proposed system is helpful for single user at the client side.

On studying the operational feasibility of the project, the following conclusion could be derived:

� Operationally the software will be most feasible due to its strong requirement for the client

company.

� Tried to make network as reliable as possible using Two Phase Commit, Cyclic Redundancy

Check and Sequence number of Sending and Receiving packets.

� Due to its easy functionalities end-user, who may are not from IT background, easily can use the

software.


10

� Also since the software is technically feasible it can be easily extended so these features increase

its operational feasibility.

5.2. Technical Feasibility

Technical feasibility tries to answer the following questions to make the software feasible.

� The software or tools necessary for building or running the application are easily available

or not?

� The compatibility amongst software exists or not?

� One of the technology used in this project is C and Socket Programming, which is most

feasible for this application due to following reason:

5.3. Schedule Feasibility

Projects are initiated with specific deadline. Time is the one of the critical factor in the development of

any system but this kind of feasibility is hardly perfect in any system.

I had to follow the schedule determined using project planning methods to meet the deadline.

Hence, it is feasible to develop a system in predetermined time interval.

5.4. Economical Feasibility

I am using Open source software for our project. Open source software include following benefits:-

� Possibly zero purchase price

� Potentially no need to account for copies in use, reducing administrative overhead

� Claimed reduced need for regular upgrades (giving lower/nil upgrade fees, lower management

costs)

� Claimed longer uptimes and reduced need for expensive systems administrators

� Near-zero vulnerability to viruses eliminating need for virus checking, data loss and downtime

� Claimed lower vulnerability to security breaches and hack attacks reducing systems

administration load

� Claimed ability to prolong life of older hardware while retaining performance

So, the cost of actual software is reduced to almost zero so this software economically feasible.


11

6. System Design

llist :client side

Start

Enter command llist

co

Display the file name along

with timestamp on client

End

Retrieve the file list

Retrieve the timestamp


12

rlist :client side

Start

Enter command rlist

co

Display file name along with

timestamp on client

End

Create socket and send packet to the

server

Receiving packet about rlist from the

server


13

rsynch : client side

yes

No

yes

No

Start

Enter command

rsynch

End

If

TR(s)=TL(s

)

Both file are

synchronized

The c.file copy to

server side

If

TR(s)>TL(s

)

R.file copy to

the client side

cmpr the c.file and r.file timing


14

System flow chart

yes

no

yes

no

Enter the choice llist,

rlist,rsynch

Enter rlist

End

Enter Rsync

Enter llist

The c.file copy to

server side

Display

Create socket/send

pkt to server

To retrieve

List

End

Retrieve list from

server

Make pkt and send

to client

Compare rfile and

cfile timing

Display rlist

End

Both file are

synchronized

If

TR(s)>TL(s

)

R.file copy

to the client

If

TR(s)=TL(s

)


15

7. Working of our project

Our project has two parts client and server. Client will send operation to the servers and server will

perform those operations and send the result to the client.

Client Part: -

Firstly, at the client side, one of the three operations is selected. Based on the selection, respective

operations are performed. If llist is selected, there is no client server communication. The client code

list outs the files in the current directory along with their timestamps and displays in the Message

Box. If rlist is selected, client sends a packet to server indicating it is rlist command. Server code

performs operations to list out the files in the current directory along with their timestamps. If rsynch

command is selected, a name of the file which we want to be synchronized should be given. Now the

comparison is done on the client side. If the file is found on the client side but not on the server side,

the file is copied from the client to the server. If the file is found on the server side but not on the

client side, the file is copied from the server to the client. If the file is not found on both the sides, a

message is displayed on both the sides “File does not exist”. If the timestamp of the file on the client

side is more than that on the server side, file is copied from the client to the server. If the timestamp

of the file is more on the server side than that on the client side, the file is copied from the server to

the client. If the timestamp of the file is same on both the sides, a message is displayed “Files are

synchronized now”. The client timeouts when the packets are not received in the given timeout. We

have used select() function to timeout and retransmit.

Server Part: -

The server performs operations according to the commands send by the client. If the client sends

the rlist command, server puts the list of files in the current directory in packets and sends them to the

client. It performs according to the given conditions which are sent by the client.


16

8. Trivial File Transfer Protocol (TFTP) :-

8.1 Finite States Machines (tftp 2010)

• What is a FSM

– A FSM is a 6-tuple: FSM =<S, E, A, f, g, q0>

• where S, E and A are the finite sets of states, events and actions, respectively, and q0 is the initial state

of the FSM,

• f: S × E -> S is the transfer function to determine the next state given an event in E and the current

state,

• g: S × E -> A is the output function which defines the action to take given an event in E and the current

state.

Interactive Network application vs. FSM

• When no event occurs, the program blocks on the receiving statement until the next event occurs.

• The action to process an event depends on the event itself and the current state of the application.

• There can be many states in which the application can be used. A state is defined by the value of a

collection of variables of the program and used to represent a certain history of the execution.

• Interactive network applications can be best described through an abstract machine model called Finite

State Machine (FSM).

• FSM representations

– A FSM can be defined by a state diagram or

– A FSM can be defined by a set of tables for the transfer function f and output function g.

TFTP protocol:-

• TFTP is a simplified version of File Transfer Protocol (FTP).

– It takes away many features of FTP such as directory listing and authentication from FTP, but

concentrates on the file transfer only.

• The file transfer is implemented using UDP; it is a complicated process, because

– We have to ensure the every byte of the file to be delivered to the destination

– A separate formal protocol in the form of FSMs for each client and server.

– Both the client and the server can be the sender and receiver.


17

8.2 Design to implement TFTP

8.2.1 User Interface design: - This is used by the client to interact with user. User command put or

get starts a file transfer.

8.2.2 File Transfer design: - This component requires two FSMs for the client and the server as the

formal protocol. It concentrates on the network packets between the server and the receiver for the file

transfer. The events considered are only the receiving of the network packets.

8.2.3 File system module design: - This component is responsible for accessing the file systems of

the sender and receiver. The sender and receiver have to read and write corresponding files, respectively.

These operations are part of the actions in the FSMs

8.2.4 Network Module design: - This is to hide the details of the network operations and provides a

higher-level interface to the FSMs for the actions which needs network interactions.

Overall design for TFTP

8.3 Network packet design

To identify the event sets of the FSMs, we need to design the format of the possible network packets

between the client and the server. The following five formats are necessary.

FSM for the server

The initial state of the server is STANDBY. Its event set E includes the receiving of the five types of

packets from the client.

FSM for the client

State INIT is a state of the user interface, does not belong to the state set of FSM client.


18

8.4 Reliability in UDP implementation

• Using UDP to implement TFTP could result in the data lose. To add reliability to the transmission, the

technology of time-out and retransmission need to be used.

– a time-out is setup when a data packet Data(k) or an acknowledgement ACK(j) is sent

– if the corresponding ACK(k) or Data(j+1) is not received within the time-out, the same Data(k) or

ACK(j) is retransmitted.

• The time-out and retransmission can be handled at the code level, they need not to appear in the FSM.

8.5 User interface design

• Main program of client

• Commands dispatch

• Command format and parser

• command processing

8.6 Network support design

• Since the client and the server is not symmetric, we need two sets of network operations functions for

them

• For the client

net_recv() receive a network packet from the server

net_send() send a network packet to the server

net_close() close the communication socket

net_open() create a socket to communicate with the server

For the server

net_initi() initialize the network connection for the server

net_recv() receive a network packet from the client

net_send() send a network packet to the client

net_close() close the communication socket

net_open() receive the first packet from a client and fork a child


19

8.7 File system module design

• This module would include many file system functions at a level higher than the file system calls.

• These functions themselves are implemented by using the file systems call such as read() and write in

Unix OS.

• The file system module is system-dependent; the rest of application is system-independent.

– This makes the port of the same application from one OS to another easy.

8.8 Reliability design

• UDP implementation must use the technique of timeout and retransmission to ensure the reliability

required.

• The client and server expect to receive the SIGALRM signal generated by the timeout.

• The Jacobson/Karel model for timeout and retransmission will be used.

Reliability module design

• In the beginning of each iteration of for(;;) loop, statements

Signal(SIGALRM, func_timeout);

Tout_flag = 0;

Alarm(rtt_start(&rttinfo));

Accept().

• Set the SIGALRM signal handler to be func_timeout() which set tout_flag, reset

tout_flag and set the timeout clock with timeout value returned by rtt_start().

9. Additional Features

9.1 File Synchronization

File synchronization in computing is the process of making sure that files in two or more locations are

updated through certain rules.

In one-way file synchronization, also called mirroring, updated files are copied from a 'source' location to

one or more 'target' locations, but no files are copied back to the source location. In two-way file


20

synchronization, updated files are copied in both directions, usually with the purpose of keeping the two

locations identical to each other. File synchronization is commonly used for home backups on external

hard drives.

9.2 CRC- Cyclic Redundancy Check

A cyclic redundancy check (CRC) or polynomial code checksum is a non-secure hash function designed

to detect accidental changes to raw computer data, and is commonly used in digital networks and storage

devices such as hard disk drives. A CRC-enabled device calculates a short, fixed-length binary sequence,

known as the CRC code or just CRC, for each block of data and sends or stores them both together. When

a block is read or received the device repeats the calculation; if the new CRC does not match the one

calculated earlier, then the block contains a data error and the device may take corrective action such as

rereading or requesting the block be sent again, otherwise the data is assumed to be error free.

We have implemented 16bit CRC in my project. The mechanics of computing an n-bit binary CRC are

simple. The bits representing the input are lined up in a row, and the (n+1)-bit pattern representing the

CRC's divisor (called a "polynomial") is positioned underneath the left-hand end of the row. If the input

bit above the leftmost divisor bit is 0, do nothing and move the divisor to the right by one bit. If the input

bit above the leftmost divisor bit is 1, the divisor is EXCLUSIVE-ORed into the. The divisor is then

shifted one bit to the right, and the process is repeated until the divisor reaches the right-hand end of the

input row.

9.3 Sequence Numbers and Acknowledgment Numbers:-

The packets are broken into datagrams. The client side and the server side send and

receive these datagrams. These datagrams should be received in the only order that the client and

server are expected. Because it may result in Segmentation Fault if a datagram is received if the

recvfrom() function does not receive the datagram it is expecting. To solve this issue, each

datagram on both the sides is given a sequence number. It should match with the same sequence

number on the receiving side otherwise it is discarded. This manages the sequence of send and

receives on client and the server. Same is repeated with Acknowledgement Number.

9.4 Timeout and Retransmission:-

The client timeouts when the packets are not received in the given timeout. We have used select ()

function to timeout and retransmit. We have used RTT to decide when to timeout. (select n.d.)


21

9.5 Round Trip Time (RTT):-

Firstly, RTT is calculated by sending a packet from the client to the server. It is called as SampleRTT.

Then, estimated RTT is found using the formula :-

EstimatedRTT = 0.875 * EstimatedRTT + 0.125 SampleRTT. (Ross 2010)

10 Testing

10.1 Testing Objectives

Testing phase and outlines the various tests that need to be carried out in order to successfully conclude

that the system does indeed meet the performance requirements that were stated earlier.

10.2 Test Cases

Test Case 1 :

Run Steps:

Name Status Description Expected Actual

Step 1 Passed Packets are dropped

due to unknown

reasons during the

transaction

Server should Abort

the transaction

Transaction is

aborted at server

side and client

timeouts after

waiting for 10

seconds for the

reply.CRC

implemented

Successfully.

Test Case 2:

Run Steps:


Step 1 Passed File is on the client

side but not on the

Server side.

File is copied from the

client to the server.

File is copied from

the client to the

server.

Test Case 3:

Run Steps:


22


Step 1 Passed File is on the Server

side but not on the

Client side.

File should be copied

from the server to the

client.

File is copied from

the server to the

client.

Test Case 4 :-


Step 1 Passed File is neither on the

Server side nor on the

Client side.

A message should be

displayed “File does

not exists”.

A message is

displayed “File

does not exists”.

Test Case 5 :-


Step 1 Passed Timestamp of the file

on the client side is

more than that on the

server side.


from the client to the

server.

File is copied from

the client to the

server.

Test Case 6 :-




less than that on the

server side.


from the server to the

client.

File is copied from

the server to the

client.

Test Case 7 :-




same as that on the

server side.

A message should be

displayed “File does

not exists”.

Not working

because physical

clocks are used.

This would be

possible when

logical clocks are

used.


23

11 Further Enhancement

� Logical clocks could have been used to avoid having ping pong situation of updating of files. In

that case, the last test case would have worked.

� This same project could have been implemented using single server and multiple clients. This

would have solved the file synchronization issues that arise nowadays due to several updates

occurring on the server side. If there are various clients located at different locations and also far

from the server, this solves the problem of having same file synchronized on all the sides. In that

way, the latest updated file is always accessed.

12 Bibliography

Calvert, Michael Donahoo and Kenneth. “TCP-IP Sockets in C - Practical Guide for Programmers .” In TCP-

IP Sockets in C - Practical Guide for Programmers , by Michael Donahoo and Kenneth Calvert.

Ross, Kurose and. “Computer Networking, 5/e James F. Kurose Keith W. Ross ISBN: 0-13-607967-9.”

2010.

2010. http://www.sci.usq.edu.au/courses/CSC8415/slides/week6.pdf (accessed 2010).

select. http://opengroup.org/onlinepubs/007908775/xsh/select.html.

Sun Solaris. http://www.sun.com/software/solaris/features.jsp (accessed 2010).

cn project reportcs.lamar.edu/faculty/osborne/5328/fall10/team6.pdf · cyclic redundancy check of...

Documents