Project Report

Multithreaded File-Sharing System

By
Akhil Khandelwal
Ankur Mahajan
Karthik Rajagopal
Sachin Prakash

Page 1 of 61
 TABLE OF CONTENTS

REQUIREMENT ANALYSIS

Abstract 3
Introduction 4
Purpose
Scope
Overall Description 5
Product Perspective
Product Functions
Constraints
Software Environment 7
Description of Technologies Used 9

SYSTEM DESIGN

Basic Architecture 22
Dataflow Diagrams 23
Flowcharts 26
Sequence Diagrams 31

IMPLEMENTATION

Screenshots 36
For Command Line Interface 37
For Graphical User Interface 49

Bibliography 59
Conclusion 60
Future Enhancements 61

Page 2 of 61
 ABSTRACT

The Multithreaded File-sharing System (MUFSYS) is based on a client-server

model and allows transfer of files from the server to the client and vice-versa
in a fast and efficient manner.
File sharing is one of the most important tasks encountered on the computer
networks. Though the File Transfer Protocol (FTP) already is the de facto
standard for file transfer on the Internet, but it uses two connections for each
transfer- one for control and the other for data. The major advantage that
MUFSYS provides is that it uses a single connection and uses the concept of
multithreading.

Threads are often called lightweight processes that run in the same address
space. Multithreading is a technique that allows parallel execution of multiple
threads. The enables file transfer between client and server with the help of
POSIX (Portable Operating System Interface for Computer Environments)
threads. Since threads are very small as compared to the processes, thread
creation is relatively cheap in terms of CPU costs.

Advantages of using multithreading

• The file-server needs to handle file request over a relatively short
period.
• It is more efficient to create a single thread for each request.

Salient features of MUFSYS:-

• MUFSYS is cross platform compatible on Linux and Windows.

• This file sharing system will allow multiple users to share files over a
network.
• The server performs the basic and necessary functions like user
authentication. Only after authentication will the user be allowed file
transfer.
• The system would be suitably designed to be helpful to even first-time
users.
• The Graphical User Interface (GUI) makes the systems a pleasant
experience even for the new user.

Page 3 of 61
 INTRODUCTION

1. PURPOSE

File sharing is one of the primary requirements on a network so much so that

nearly 70% of the traffic on the Internet comprises of file transfers. The
Multithreaded File-Sharing System (MUFSYS) shall work on a client-server
model. A client is any computer that requests for a particular service and the
server is a computer that fulfils that request. In case of MUFSYS, the request
is for remotely retrieving or transferring files. MUFSYS shall provide an easy
to use interface such that even novice users can use the system.
The intended audience of this document is the development/ testing team
and the end users

2. SCOPE

MUFSYS shall comprise of modules for both the client and the server. It shall
be a secure system that will provide a username and password protected
access. Multithreading will make the system more efficient since it reduces
the overhead that would otherwise be required for separate processes.
The system will run on mostly all Linux distributions and on Windows.

Page 4 of 61
 OVERALL DESCRIPTION

1. PRODUCT PERSPECTIVE

MUFSYS will be a Linux/Windows-based cross-platform and self contained

system and will independently compile on Unix-based C compilers and/or on
Microsoft’s Visual C++.

1.1 User Interfaces

• The system will be user friendly graphical user interface (GUI)-based

with an option for command line handling as well.
• It will provide a login screen for entering the username and the
password.
• It would then prompt the user for entering the desired service. File
retrieval or transfers will require user authentication but certain
services shall be provided to all the users, for example, help on the
system commands.
• The system would then ask for further attributes of the service, for
example, the name of the file to be retrieved from the the server if the
service desired happens to be that of getting a file.
• The system will also display the time taken for file transfer.

1.2 Hardware Interfaces

• The system is designed to work in a networked environment so a LAN

is required.
• Colour or monochrome monitor with a resolution of 800X600 or
higher.

1.3 Software Interfaces

• Any Linux distribution such as Fedora Core or Microsoft Windows is

required.
• An Open-Source compiler for the C language such as the GNU C
Compiler (GCC).
• Software for designing the graphical user interface such as QT. These
software are provided as packages with Linux distribution itself. The
GUI software will be required for development only.

Page 5 of 61
1.4 Memory Constraints

At least 256 MB of RAM is required.

At least 10 GB of storage for housing the Linux distribution at the time of
development is required.

1.5 Site Adaptation Requirements

The client and server programs will execute on Linux or Windows.

2. PRODUCT FUNCTIONS

The system will require user authentication prior to any file transactions.

A summary of the major functions of the software are:-

• The client will first be required to establish a connection with the
server.
• The server will create a separate thread for the client.
• A login facility for enabling authorization of the user will be provided at
the server.
• General functions like help, list, etc. are provided to all the users.
• The user is asked to enter the service that he requires from the server.
• The server checks for the service and prompts the user at the client
side to enter the file name.
• The file-size will be calculated and the number of packets to be
transmitted is calculated.
• The individual packets will then be transmitted and acknowledgements
will be returned.
• Besides this, the time taken for file transfer will also be displayed.
• Apart from retrieving files from the server, the clients will also be able
to transfer their file to the server.

3. USER CHARACTERISTICS

The user should be comfortable with the English language. Although help will
be available on all the services, but a basic knowledge of the Linux operating
system is required to become the system administrator.

Page 6 of 61
4. CONSTRAINTS

The software requires that a C compiler be installed on the user’s computer

system. Some popular compilers are GNU’s C Compiler (GCC) and Microsoft’s
VC++ compiler.

Page 7 of 61
 SOFTWARE ENVIRONMENT

OPERATING SYSTEM

The operating systems used were Redhat Linux Fedora Core 4 and
Windows XP Professional. The server runs on Linux or Windows and can
support both Linux and Windows clients. Being cross-platform in Windows
and linux is one of the prime features of MUFSYS.

LANGUAGE USED
The GNU C language has been used for coding the server as well as the
client. GNU C was used for implementing Linux Socket Programming.

TOOLS USED

Trolltech Qt Designer has been used for designing the GUI for Linux
clients. Qt comes in-built on Linux platforms and uses C++ as its base. It as
poetable on other platforms such as Windows as well and that makes it a
good choice for GUI design.

Microsoft Visual C++ has been used to create the client–side executable
files for creating a command-line interface. Winsock sockets are used for
implementing sockets in a windows environment.

Page 8 of 61
 DESCRIPTION OF TECHNOLOGIES USED

LINUX Socket Programming (in GNU C Language)

Linux Socket Programming is the underlying technology employed for

MUFSYS. The fundamental of network programming is the socket. Just as
file input/output connects one with the file system, the socket connects one
to the network. The socket acts like a junction that allows one to address,
receive and send packages.

Several years ago, networking involved a dedicated serial line from one
computer to another. No other computers shared the same circuit and UNIX
used UUCP (UNIX-to-UNIX File Copy) to move files around. As transmission
technology improved, the concept of sharing the transmission lines became
feasible. This meant that each computer needed to identify itself uniquely
and take turns transmitting. At times, computers transmit simultaneously,
causing a packet collision. Today, the hardware and low level drivers handle
such issues as collision and retransmission. The socket API (Application
Programming Interface) provides the programmers a conduit to send and
receive packets.

Socket programming differs from typical application programming because

one has to handle concurrently running programs and systems.

Before any communication can take place between the client and the server,
a socket needs to be created. The client program must follow the following
steps to connect to the server. Each client interfaces with the system by
making several calls in succession. The steps needed are:-
1. Create the socket by using the socket() system call. One also has to
choose the network domain (Eg. Internet) and the socket type
(stream). One also optionally set other socket options.
2. Bind to address/port i.e., specify IP addresses from where to accept
connections. Otherwise the operating system assumes any IP address
and random port number.
3. Connect to peer/server. This step establishes a bidirectional channel
between the two programs. Skipping these steps leads to a
connectionless channel.
4. Limit the channel to either sending or receiving.
5. Send/receive messages.
6. Close the connection. Long running programs may use up all available
file-descriptors if defunct connections are not closed.

Page 9 of 61
 The following schematic diagram presents an outline of the successive
steps that need to be followed.

Socket()

bind()

connect()

read() write()

close()

The TCP/IP protocol suite uses standard IP addresses that are 32 bit (4
byte) long. The standard format for IP addresses is [0-255]- [0-255]- [0-
255]- [0-255] for example 168.192.50.149. TCP/IP considers data as a
collection of packets. Each packet consists of the data, the originator
address, and the destination address. Each layer adds its own signature and
wrapper data which is removed by the corresponding receiving layer. Every
computer connected to the network has an IP address which uniquely
identifies the computer on the network. TCP/IP takes the addressing system

Page 10 of
61
one step further by the concept of ports. A port is a logical abstraction and
does not have a physical form. A socket can be considered to be a named
port, i.e. a combination of IP address and the port number.

BRIEF DESCRIPTION OF SYSTEM CALLS

Socket () system call has the following format:-

int socket(int domain, int type, int protocol);

The domain can be PF_INET,PF_LOCAL or AF_INET, AF_LOCAL.

The type specifies the data flow to and from the socket. It can be any of the
SOCK_STREAM, SOCK_RDM, SOCK_DGRAM, SOCK_RAW. The
SOCK_STREAM type defines a reliable, sequential data flow of streaming
bytes.
The socket() call requires the header files sys/socket.h and sys/types.h to be
included in the program.

bind () system call has the following format:-

int bind(int sockfd, struct sockaddr *my_addr, int addrlen);

sockfd is the socket file descriptor returned by socket(). my_addr is
a pointer to a struct sockaddr that contains information about your address,
namely, port and IP address. addrlen can be set to sizeof(struct sockaddr).

Connect() system call has the following format:-

int connect(int sockfd, struct sockaddr *serv_addr, int addrlen);

sockfd is a socket file descriptor, as returned by the socket() call, serv_addr
is a struct sockaddr containing the destination port and IP address, and
addrlen can be set to sizeof(struct sockaddr).
The accept() system call has the following format:-

int accept(int sockfd, void *addr, int *addrlen);

sockfd is the listening socket descriptor. Mostly, addr will usually be a pointer
to a local struct sockaddr_in. This is where the information about the
incoming connection goes (and with it one can determine
which host is calling and from which port). addrlen is a local integer variable
that should be set to sizeof(struct sockaddr_in) before its address is passed
to accept(). Accept will not put more than that
many bytes into addr. If it puts fewer in, it will change the value of addrlen
to reflect that. Accept() returns -1 and sets errno if an error occurs.

The send() system call has the following format:-

int send(int sockfd, const void *msg, int len, int flags);

Page 11 of
61
sockfd is the socket descriptor where one intends to send the data. msg is a
pointer to the data one wants to send, and len is the length of that data in
bytes.

The recv() system call has the following format:-

int recv(int sockfd, void *buf, int len, unsigned int flags);

sockfd is the socket descriptor to read from, buf is the buffer to read the
information into, len is the maximum length of the buffer. recv() returns the
number of bytes actually read into the buffer, or -1 on error (with errno set,
accordingly.) recv() returning a value of 0 indicates that the remote site has
closed the connection.

The close() system call has the following format:-

close(sockfd);

This will prevent any more reads and writes to the socket. Anyone
attempting to read or write the socket on the remote end will receive an
error.

Page 12 of
61
THREADS

Technically, a thread is defined as an independent stream of instructions

that can be scheduled to run as such by the operating system. A thread
can be conceptually defined as a "procedure" that runs independently
from its main program may best describe a thread. The main program
(a.out) contains a number of procedures. All of these procedures are able
to be scheduled to run simultaneously and/or independently by the
operating system. That would describe a "multi-threaded" program.

Before understanding a thread, one first needs to understand a UNIX

process. A process is created by the operating system, and requires a fair
amount of "overhead". Processes contain information about program
resources and program execution state, including:-

o Process ID, process group ID, user ID, and group ID

o Environment
o Working directory.
o Program instructions
o Registers
o Stack
o Heap
o File descriptors
o Signal actions
o Shared libraries
o Inter-process communication tools (such as message queues,
pipes, semaphores, or shared memory).

Threads use and exist within these process resources, yet are able to be
scheduled by the operating system and run as independent entities
largely because they duplicate only the bare essential resources that
enable them to exist as executable code. This independent flow of control
is accomplished because a thread maintains its own:

o Stack pointer
o Registers
o Scheduling properties (such as policy or priority)
o Set of pending and blocked signals
o Thread specific data.

So, in summary, in the UNIX environment a thread:

o Exists within a process and uses the process resources

o Has its own independent flow of control as long as its parent
process exists and the OS supports it

Page 13 of
61
 o Duplicates only the essential resources it needs to be
independently schedulable
o May share the process resources with other threads that act
equally independently (and dependently)
o Dies if the parent process dies - or something similar
o Is "lightweight" because most of the overhead has already been
accomplished through the creation of its process.

Because threads within the same process share resources:

o Changes made by one thread to shared system resources (such

as closing a file) will be seen by all other threads.
o Two pointers having the same value point to the same data.
o Reading and writing to the same memory locations is possible,
and therefore requires explicit synchronization by the
programmer.

PTHREADS
In order to take full advantage of the capabilities provided by threads, a
standardized programming interface was required. For UNIX systems, this
interface has been specified by the IEEE POSIX 1003.1c standard (1995).
Implementations which adhere to this standard are referred to as POSIX
threads, or Pthreads. Most hardware vendors now offer Pthreads in addition
to their proprietary API's.

Pthreads are defined as a set of C language programming types and

procedure calls, implemented with a pthread.h header/include file and a
thread library - though the this library may be part of another library, such
as libc.

ADVANTAGES OF PTHREADS

• The primary motivation for using Pthreads is to realize potential

program performance gains.
• When compared to the cost of creating and managing a process, a
thread can be created with much less operating system overhead.
Managing threads requires fewer system resources than managing
processes.
• All threads within a process share the same address space. Inter-
thread communication is more efficient and in many cases, easier to
use than inter-process communication.
• Threaded applications offer potential performance gains and practical
advantages over non-threaded applications in several other ways:
o Overlapping CPU work with I/O: For example, a program may
have sections where it is performing a long I/O operation. While
one thread is waiting for an I/O system call to complete, CPU
intensive work can be performed by other threads.

Page 14 of
61
 o Priority/real-time scheduling: tasks which are more important
can be scheduled to supersede or interrupt lower priority tasks.
o Asynchronous event handling: tasks which service events of
indeterminate frequency and duration can be interleaved. For
example, a web server can both transfer data from previous
requests and manage the arrival of new requests.
• Tasks that may be suitable for threading include tasks that:
o Block for potentially long waits
o Use many CPU cycles
o Must respond to asynchronous events
o Are of lesser or greater importance than other tasks
o Are able to be performed in parallel with other tasks
• One must be careful if ones application uses libraries or other objects
that don't explicitly guarantee thread-safeness. When in doubt,
assume that they are not thread-safe until proven otherwise.

Thread-safeness: in a nutshell, refers an application's ability to

execute multiple threads simultaneously without clobbering shared
data or creating race conditions. For example, suppose that you use a
library routine that accesses/modifies a global structure or location in
memory. If two threads both call this routine it is possible that they
may try to modify this global structure/memory location at the same
time. If the routine does not employ some sort of synchronization
constructs to prevent data corruption, then it is not thread-safe. The
implication to users of external library routines is that if you aren't
100% certain the routine is thread-safe, then you take your chances
with problems that could arise.

• Several common models for threaded programs exist:

o Manager/worker: a single thread, the manager assigns work
to other threads, the workers. Typically, the manager handles
all input and parcels out work to the other tasks. At least two
forms of the manager/worker model are common: static worker
pool and dynamic worker pool.
o Pipeline: a task is broken into a series of suboperations, each
of which is handled in series, but concurrently, by a different
thread. An automobile assembly line best describes this model.
o Peer: similar to the manager/worker model, but after the main
thread creates other threads, it participates in the work.
• The Pthreads API is defined in the ANSI/IEEE POSIX 1003.1 -
1995 standard.

• The subroutines which comprise the Pthreads API can be informally

grouped into three major classes:
o Thread management: The first class of functions work directly
on threads - creating, detaching, joining, etc. They include

Page 15 of
61
 functions to set/query thread attributes (joinable, scheduling
etc.)
o Mutexes: The second class of functions deal with
synchronization, called a "mutex", which is an abbreviation for
"mutual exclusion". Mutex functions provide for creating,
destroying, locking and unlocking mutexes. They are also
supplemented by mutex attribute functions that set or modify
attributes associated with mutexes.
o Condition variables: The third class of functions address
communications between threads that share a mutex. They are
based upon programmer specified conditions. This class includes
functions to create, destroy, wait and signal based upon
specified variable values. Functions to set/query condition
variable attributes are also included.
• Naming conventions: All identifiers in the threads library begin with
pthread_

Routine Prefix Functional Group

Threads themselves and miscellaneous

pthread_
subroutines

pthread_attr_ Thread attributes objects

pthread_mutex_ Mutexes

pthread_mutexattr_ Mutex attributes objects.

pthread_cond_ Condition variables

pthread_condattr_ Condition attributes objects

pthread_key_ Thread-specific data keys

• The Pthreads API contains over 60 subroutines.

• The pthread.h header file must be included in each source file using
the Pthreads library. For some implementations, such as IBM's AIX, it
may need to be the first include file.
• The current POSIX standard is defined only for the C language. Fortran
programmers can use wrappers around C function calls.

Creating and Terminating Threads

The following system calls are commonly used:-
pthread_create (thread,attr,start_routine,arg)
pthread_exit (status)
pthread_attr_init (attr)
pthread_attr_destroy (attr)

Page 16 of
61
Creating Threads

• Initially, your main() program comprises a single, default thread. All

other threads must be explicitly created by the programmer.
• pthread_create creates a new thread and makes it executable.
Typically, threads are first created from within main() inside a single
process. Once created, threads are peers, and may create other
threads.
• pthread_create arguments:
o thread: An opaque, unique identifier for the new thread
returned by the subroutine.
o attr: An opaque attribute object that may be used to set thread
attributes. You can specify a thread attributes object, or NULL
for the default values.
o start_routine: the C routine that the thread will execute once it
is created.
o arg: A single argument that may be passed to start_routine. It
must be passed by reference as a pointer cast of type void.
NULL may be used if no argument is to be passed.
• The maximum number of threads that may be created by a process is
implementation dependent.

Thread Attributes

• By default, a thread is created with certain attributes. Some of these

attributes can be changed by the programmer via the thread attribute
object.
• pthread_attr_init and pthread_attr_destroy are used to
initialize/destroy the thread attribute object.
• Other routines are then used to query/set specific attributes in the
thread attribute object.
• Some of these attributes will be discussed later.

Terminating Threads

• There are several ways in which a Pthread may be terminated:

o The thread returns from its starting routine (the main routine
for the initial thread).
o The thread makes a call to the pthread_exit subroutine (covered
below).
o The thread is canceled by another thread via the pthread_cancel
routine.
o The entire process is terminated due to a call to either the exec
or exit subroutines.
• pthread_exit is used to explicitly exit a thread. Typically, the
pthread_exit() routine is called after a thread has completed its work
and is no longer required to exist.

Page 17 of
61
 • If main() finishes before the threads it has created, and exits with
pthread_exit(), the other threads will continue to execute. Otherwise,
they will be automatically terminated when main() finishes.
• The programmer may optionally specify a termination status, which is
stored as a void pointer for any thread that may join the calling
thread.
• Cleanup: the pthread_exit() routine does not close files; any files
opened inside the thread will remain open after the thread is
terminated.
• Discussion: In subroutines that execute to completion normally, one
can often dispense with calling pthread_exit() - unless, of course, one
wants to pass a return code back. However, in main(), there is a
definite problem if main() completes before the threads it spawned. If
one does not call pthread_exit() explicitly, when main() completes, the
process (and all threads) will be terminated. By calling pthread_exit()
in main(), the process and all of its threads will be kept alive even
though all of the code in main() has been executed.

Joining and Detaching Threads

The following system calls are employed:-

pthread_join (threadid,status)
pthread_detach (threadid,status)
pthread_attr_setdetachstate (attr,detachstate)
pthread_attr_getdetachstate (attr,detachstate)

• The pthread_join() subroutine blocks the calling thread until the

specified threadid thread terminates.
• The programmer is able to obtain the target thread's termination
return status if it was specified in the target thread's call to
pthread_exit().

When a thread is created, one of its attributes defines whether it is joinable

or detached. Only threads that are created as joinable can be joined. If a
thread is created as detached, it can never be joined.
The pthread_detach() routine can be used to explicitly detach a thread even though
it was created as joinable.

Page 18 of
61
TROLLTECH QT GUI DESIGNER

Qt software was chosen for developing the graphical user interface for
MUFSYS. Qt is a comprehensive C++ application development framework. It
includes a class library and tools for cross-platform development.
Qt is a comprehensive development framework that includes an extensive
array of features, capabilities and tools that enable development of high-
performance, cross-platform rich-client and server-side applications.
The Qt Class Library is a growing library of over 400 C++ classes, which
encapsulates all infrastructure needed for end-to-end application
development. The elegant Qt API includes a mature object model, a rich set
of collection classes, and functionality for GUI programming, layout, database
programming, networking, XML, internationalization, OpenGL integration etc.
Qt Designer is a powerful GUI layout and forms builder, enabling rapid
development of high-performance user interfaces with native look and feel
across all supported platforms.
Qt Linguist is a set of tools designed to smooth the internationalization
workflow. Using Qt Linguist, development teams can outsource the
translation of applications to non-technical translators, increasing accuracy
and greatly speeding the localization process.
Qt Assistant is a fully customizable, redistributable help file/documentation
browser that can be shipped with Qt-based applications. With Qt Assistant,
development teams significantly speed the documentation process.
Qt is the leading framework for native cross-platform application
development. The Qt API and tools are consistent across all supported
platforms, enabling developers to learn one API and perform truly platform-
independent application development and deployment. Using Qt,
development teams can create native applications for all major operating
systems - from all major development platforms.
Qt is available for the following platforms:
Qt/Windows (Microsoft Windows XP, 2000, NT 4, Me/98)
Qt/Mac (Mac OS X)
Qt/X11 (Linux, Solaris, HP-UX, IRIX, AIX, etc.)

Qt encapsulates the different platform-specific APIs of Unix, Windows, and

Mac, and the APIs for file handling, networking (Operations, Protocols),
process handling, threading, database access, and more.
Qt requires no "virtual machines", emulation layers or bulky runtime
environments. It writes directly to low-level graphics functions, just like
native apps do - allowing Qt applications to run at native speed.
Qt is a visual form designer that uses the the .ui file formats for the forms.
Each .ui file contains an XML description of a single dialog form. A second
utility - the user interface compiler uic - is used during the build process of
an application to generate C++ code from those XML descriptions.
Qt makes for some very efficient GUI development without confining the user
to a perticular tool. Qt also provides project management features like:-
• Grouping of forms that belong together. Grouping forms means that Qt
Designer maintains a list of the .ui files that belong to the same

Page 19 of
61
 project. This makes it easy to switch between forms with a single
mouse click.

• Sharing of images between different forms. If we use a project we can

add images to the project's image collection, and these images can be
shared and used by any of the forms we include in the project. The
images are stored as PNGs (portable network graphics) in a
subdirectory, images/, inside the project's directory. Whenever we
modify the image collection, Qt Designer creates a source file which
contains both the image data in binary format and a function to
instantiate the images. The images are accessible by all forms in the
project and the data is shared.

Sharing of information between different forms. Qt 3.0 introduces a brand

new database module, the Qt SQL module. Qt Designer is fully integrated
with the SQL module and can show live data from the databases that you
connect to. Qt Designer needs to store information on projects, for example,
the list of forms, the image collection and information about available
databases and how to access them. We use project file format to create
multiplatform makefiles (qmake) project .pro files. These files already
contain the list of forms, .ui files, used in the project for uic.

Qt Designer reads and writes .ui files, e.g. form.ui. The user interface
compiler, uic, creates both a header file, e.g. form.h, and an implementation
file, e.g. form.cpp, from the .ui file. The application code in main.cpp
#includes form.h. Typically main.cpp is used to instantiate the QApplication
object and start off the event loop.
The following diagram shows schematic interaction between various
components of Qt project components:-

Page 20 of
61
MICROSOFT VISUAL C++

Microsoft Visual C++ is a comprehensive and sofisticated development

environment based on the C++ language. It provides a high level of
programming power and convenience, while offering a diverse set of tools
designed to suit almost every programming style. Newer versions of the
software like ver 6.0 add significantly to the already impressive array of
features. Some features include easier application coding, building, and
debugging; greater support for ActiveX and Internet technologies; additional
database development options; and new application architectures and user-
interface elements.

Microsoft VC++ was used to design the client side executable file for
Windows-based clients. In order to be able to use POSIX threads in the code,
we are required to link the pthread library into the VC++ environment.

Page 21 of
61
BASIC ARCHITECTURE

Page 22 of
61
DATAFLOW
DATAFLOW DIAGRAMS

Page 23 of
61
 CONTEXT DIAGRAM

Administrator

Username
Password
File transfer/
File retrieval retrieval
/transfer

MUFSYS Server User

Client user
Login info Service response
Service desired
File name/path

Page 24 of
61
 LEVEL 1 DFD

Administrator

Usernames and
passwords

Data Store

GUI
MODULE
Command
handling
Authentication
module

Server Client

File transfer
module File
Service retrieval/
Response Transfer

File retrieval/ Login info

Transfer Service desired
File name/path

Page 25 of
61
FLOWCHARTS

Page 26 of
61
 CLIENT
AUTHENTICATION

Start

Client enters
username and
password

Username and No Access

password denied
correct message
displayed

Yes

Available file lists

are displayed

Stop

Page 27 of
61
 COMMAND HANDLING FOR CLIENT

Start

Command received
from client

Are these help No Authentication

commands ? process is called

Yes

Thread created for

the client

Command received
from client

More clients?

Yes

No

Stop

Page 28 of
61
 FILE RETRIEVAL BY CLIENT

Start

Client enters
source and
destination file
names

Is the client Authentication process

authenticated? is called
No

Yes

Server receives request and

checks file permissioins

Server calculates the file size

and divides the file into packets

Server sends the packets to the

client

Stop

Page 29 of
61
 FILE SEND BY CLIENT

Start

Client receives
filename

Client accesses file

Client calculates file

size(s)

Packet size calculated

Packets are sent as a byte

stream

Stop

Page 30 of
61
SEQUENCE DIAGRAMS

Page 31 of
61
 USER AUTHENTICATION

Client-side user Server Login checking

module

1.Username and
password
2. User info
passed

4.success or 3. result of
access denied Checking

Page 32 of
61
 GETTING A FILE

Client-side user interface sever

(GUI/CLI)

1. command: get 2. command id & client IP

3. request for names

4. Prompt for info

6. calculate
file size and
5. source and destination
packets
filenames

7. Start time

8. File packets

9. End time

Page 33 of
61
 PUTTING A FILE

Client-side user Interface Sever

(GUI/CLI)

1. command: put 2. command id & client IP

3. request for names

4. Prompt for info

6.
calc.file
5. source and destination
size
filenames

7. Start time

8. File packets

9. End time

Page 34 of
61
 GENERAL SERVICES

Cient-side user Interface sever

(GUI/CLI)

1. command 2. command id & client IP

3. thread created and

joined for the
command

4. command: help 5. command id

6. help details
9. close conn
7. command: bye 8. command id

Page 35 of
61
SCREENSHOTS

Page 36 of
61
 SCREEN SHOTS
FOR THE COMMAND LINE INTERFACE

Page 37 of
61
 PROMPT SCREEN

The following is the first screen that the client will see
when he/she logs in using the command line interface. It
consists of a client prompt from where the user can use
various commands to access the full power of MUFSYS
software.

Page 38 of
61
 SERVER SCREEN

The following is the screen for the server. Server can keep
track of the clients who access the system and what all
services they use. A lot of useful information such as the
IP address of the connecting client, the connection date ,
day, etc. are displayed. The server can easily monitor
clients on the system and can either fulfill the clients
request or can even terminate the client’s connection.

Page 39 of
61
 OPEN COMMAND

The client then enters the open command to start using

the file transfer capabilities of MUFSYS. In order to further
proceed the client is required to enter the username and
the password provided by the system administrator. If the
username and the password are correct, then only the
client is allowed access to the system. As shown in the
following screen.

Page 40 of
61
 MONITORING ON SERVER

An accepted connection is reflected on the server. It also

shows the IP address of the connected client.

Page 41 of
61
 CONNECTION DENIED SCREEN

In case the entered username and/or password is/are

incorrect, then the client is not allowed access to MUFSYS.

Page 42 of
61
 SCREEN FOR SERVER’S FILE LIST

The client can access the list of files available on the

server as well as a list of files available on the client. This
feature is displayed in the following two screens:-

Page 43 of
61
 LOCAL FILE LIST SCREEN

The following screen shows that the client can also view
the files present locally:-

Page 44 of
61
 HELP SCREEN

There are certain features for which the client does not have
to be an authenticated user. This means that any user can
avail of certain features without having a password protected
account. These features include commands such as help which
provides a basic introduction about the available features.

Page 45 of
61
 FILE RETRIEVAL SCREEN

The get command allows the client-side user to retrieve files

from the server. The get command requires the user to enter
the source file name as well as the destination filename.

Page 46 of
61
 FILE TRANSFER SCREEN

The client-side user can also put files on the server by using
the put command. This command also requires the user to
enter the source and the destination file names. The command
also displays the time the file transfer started as well as the
time when the file transfer completed.

Page 47 of
61
 SESSION TERMINATION SCREEN

Finally the client can terminate the session using the bye
command.

Page 48 of
61
SCREEN SHOTS FOR THE GRAPHICAL USER
INTERFACE (GUI)

Page 49 of
61
 SPLASH SCREEN

The following is the splash screen which pops up when

the client-side user logs into the system using the graphical
user interface.

Page 50 of
61
 LOGIN WINDOW

The following is the screen for user authentication. The help

and the exit buttons are activated even before
authentication so that any user can access these features.
The status window fulfils varied functions such as displaying
the correct status of the connection as well as file lists, etc.

Page 51 of
61
 OPTION MENU

The following screen shows an active connection after user

authentication. The select option field provides the list of the
commands that are available to provide the various services.

Select Option

Page 52 of
61
The following screens show some other commands available.
Some of the commands are list, get, send, help etc.

Get File

Page 53 of
61
The following screen shows the list of file available on the
client as well as the file sizes.

List Of Files

Page 54 of
61
 FILE RETRIEVAL MODULE

The file retrieval module shows the list of various files

available for download on the server. The user can double
click on the file name to bring it into the File field. The
Destination File field is used fro entering the name with
which the file will be stored on the client after retrieval.

Page 55 of
61
Page 56 of
61
 FILE TRANSMISSION MODULE

The file transmission is accessed through the following

screen. The user enters the source and the destination file
names.

Page 57 of
61
 HELP SCREEN

The following screen shows the help screen after the user
clicks on the help button. Such features make MUFSYS all
the more user friendly.

Page 58 of
61
 BIBLIOGRAPHY

The following books and manuals were referred whilel

developing MUFSYS:-

Linux Socket Programming by Sean Watson

Visual C++ by Sams publications
C++ GUI Programming with Qt3 by Jasmin Blanchette and
Mark Summerfield
Network Socket Programming by Beej
Qt 3.3 Whitepaper from Trolltech Corp.

The following websites were also referred:-

www.microsoft.com/msdn
www.trolltech.com
www.qtcenter.org

Page 59 of
61
 CONCLUSION

MUFSYS has been successfully completed and tested on both

Linux and Windows platforms. It has been tested with files
various formats and sizes.

Both the client and the server have been tested for sending
as well as receiving files.

Client and server can be implemented on both Linux and

Windows and this feature makes MUFSYS platform-
independent on Linux and Windows.

Multiple clients have been handled by the server.

Page 60 of
61
 FUTURE SCOPE

Further protection can be provided by encrypting the file

holding the username and passwords on the server.

A GUI has been provided for Linux-based clients, only

command line interface exists for Windows-based clients. A
GUI can be provided for Windows clients. Although Qt comes
in-built with Linux Fedora Core, it has to be separately
shipped for Windows.

This application can be used as a basis for providing

dynamic load adjustment. The server can be enhanced with
further functionalities under which the server will be able to
redirect the request to another client which already has the
required file, thereby reducing the load on the server.

Error checking can be provided which helps to retrieve the

file properly even if some of the packets get corrupted on
the network.

Page 61 of
61