Richard Andrew Mealing COMP391 Project Report …mealingr/documents/Efficient Data...

Richard Andrew Mealing COMP391 Project Report

200433830 Efficient Data Communication and Synchronization

Richard Andrew Mealing

200433830

Dr Dariusz Kowalski

Efficient Data Communication and

Synchronization



Abstract

A large part of digital data communication relies on transferring information across computer

networks in the form of file transfers. The three most important considerations for file

transfers are making them as efficient, reliable and user friendly as possible. Setting up

explicit file transfers over a direct connection can be very complicated for non specialists

because most programs provide a swarm of details. This gives users greater control over their

transfers but increases the chance of errors occurring. Indirect file transfers, such as those

found over instant messaging systems, can be easy to set up but, they fail to utilize the full

potential of users‟ connections which slows down transfers. This project simplifies setting up

direct file transfers by making them as autonomous as possible and only asking for user input

where absolutely necessary.

A rapid cyclic development approach has been followed where the program has been

constantly reviewed by users providing feedback which has been acted upon. The result is a

program which is very small (about 276 times smaller than Windows Live Messenger), very

fast (bringing the utilization of the user‟s bandwidth up to 100% in the upload and/or

download capacity), highly reliable (transfers can be resumed and error checking is included)

and easy to use (information users need to exchange is provided and can be copied and pasted

and required user input is kept to a bare minimum).

The program can synchronize folders which can help identify and replace corrupt or out of

date files. The implications are a program which will make life a little bit easier for users by

saving time and potentially money and its accessibility will improve the communities‟

information communication skills and knowledge.



Contents

1. Introduction

2. Background

2.1. Pre-Design Research

2.1.1. User Datagram Protocol (UDP)

2.1.2. Transmission Control Protocol (TCP)

2.1.3. Jumbograms

2.1.4. 7zip Compression Ratio

2.2. Project Requirements from Research

3. Specification

3.1. Introduction

3.2. Problem

3.3. Project Description

3.3.1. Target Audience

3.3.2. Aim

3.3.3. Proposed Solution

3.4. Statement of Deliverables

3.4.1. Software

3.4.2. Documentation

3.4.3. Experiments

3.4.4. Evaluation

3.4.5. Functionality

3.5. Conduct of the Project Plan

3.5.1. Preparation

3.5.2. Design Stage

3.5.3. Implementation Stage

3.5.4. Risk Assessment

3.6. Gantt Chart

4. Design

4.1. Noun Extraction

4.2. Verb Extraction

4.3. Interface Design (final design)

4.4. Evaluation Design

4.5. Class Diagrams

4.5.1. TransferGUI

4.5.2. Connect

4.5.3. Send

4.5.4. Receive

4.5.5. UpdateReceive

4.5.6. UpdateSend

4.5.7. Pause

4.5.8. Buffer

4.5.9. GetIP

4.5.10. Relationships



4.6. Use Case Diagrams 4.6.1. User Functions

4.6.2. Network Operation

4.7. State Diagrams 4.7.1. User Functions

4.7.2. Network Connections (Sending)

4.7.3. Network Connections (Receiving)

4.8. Dependency Diagrams

4.8.1. TransferGUI

4.8.2. Connect

4.8.3. Receive

4.8.4. Send

4.8.5. UpdateSend


4.8.7. Pause

4.8.8. GetIP

4.8.9. Buffer

4.9. System Sequence Diagram (SSD)

4.10. Method Pseudocode 4.10.1. TransferGUI

4.10.2. Connect

4.10.3. Receive

4.10.4. Send


4.10.6. UpdateSend

4.10.7. Buffer

4.10.8. Pause

4.10.9. GetIP

5. Testing

5.1. Problems, Causes, Solutions Table

6. Realisation

7. Evaluation

7.1. Comparison Table

7.2. Objectives Table

8. Learning Points

9. Relationship to the British Computer Society Code of Practice

10. Relationship to the British Computer Society Code of Conduct

11. Bibliography

12. Appendix

12.1. Interface Design (full details)

12.1.1. First Design and User Feedback

12.1.2. Second Design and User Feedback

12.1.3. Third Design and User Feedback

12.1.4. Fourth Design and User Feedback



12.1.5. Other User Feedback

12.2. Class Responsibilities

12.2.1. TransferGUI

12.2.2. Connect

12.2.3. Receive and Send

12.2.4. UpdateReceive and UpdateSend

12.2.5. Pause

12.2.6. Buffer

12.2.7. GetIP

12.3. Method Pseudocode (full details)

12.3.1. TransferGUI

12.3.2. Connect

12.3.3. Receive

12.3.4. Send


12.3.6. UpdateSend

12.3.7. Buffer

12.3.8. Pause

12.3.9. GetIP

12.4. User Guide

12.4.1. Requirements

12.4.2. Installation

12.4.3. Running

12.4.4. Use

12.5. Screenshots

12.5.1. Early Design

12.5.2. Middle Design

12.5.3. Late Design

12.5.4. Establishing a Connection

12.5.5. Offering a File

12.5.6. Single Instance Transfer

12.5.7. Multiple Instance Transfer

12.5.8. Compressing a File

12.5.9. Final Build

12.5.10. Downloading at Maximum Capacity

12.6. Javadoc API html (included on the CD)

12.7. Java Code (included on the CD)



1. Introduction

Despite the number of file transfer programs available Windows Live Messenger‟s built in

file transfer feature is by far the most popular in order to send and receive files between

people who know each other. This is shown by Alexa the web information company which as

of the 26th

of September 2008 records that 20.32% of global Internet users have visited

http://www.live.com which is the home of Windows Live Messenger (see also [18]

). Although

its simplicity and ease of use is commendable there are two major problems associated with

it. The first is the speed, in that files are transferred indirectly through Microsoft‟s servers

which significantly reduce the transfer rate. The second is the inability to resume transfers

such that in the event the transfer is stopped for whatever reason, any data already received is

discarded and the transfer must be restarted if the file is resent.

The main reasons I believe Windows Live Messenger‟s built in file transfer feature is the

most popular considering the number of file transfer programs available are as follows.

Firstly it is free of charge, secondly it is easy to use, thirdly it is convenient in that Windows

Live Messenger allows you to converse at the same time and finally because I believe it is the

most well known (it comes preinstalled with most Microsoft Windows operating systems

which according to http://www.microsoft.com/presspass/ofnote/9-16mrktshare.mspx hold

“90 percent market share”). It will be the only known program for Microsoft Windows users

who either do not have Internet access or who are unaware of how to search for and install

other file transfer programs.

Taking the presumption that the above is true it seemed logical to use Windows Live

Messenger‟s file transfer feature as something to try to work towards and surpass. The

solution accomplishes this for the following reasons. Firstly the connection it uses to transfer

files is direct and thus the speed is optimal and unrestricted. Secondly resume is supported in

such a way that accounts for both intentional and unintentional halts to the transfer. Thirdly

the GUI is as simplified as possible such that it only requires the necessary information.

Moreover additional features include the ability to send folders as well as single files, the

ability to compress and decompress files autonomously, portability over various operating

systems due to it being programmed in the Java programming language and finally the ability

to detect corrupt files and resend them.

The purpose of this report is to provide a means for disseminating my results and experiences

to the reader by providing a structure to my thoughts. It is intended to be truthful and written

from an objective point of view. This report is likely to have multiple reader groups including

experts, executives, business professionals and non-specialists. In order for all potential

readers to follow my line of thought it will be necessary to provide background information

on the key concepts. The report is intended to be concise, focused and clear enabling all

readers to make sense of my approach, apply my solution elsewhere and to verify my results

and contribution.

The report will explain specific domain related information as part of the background to give

all readers at least a basic understanding necessary to follow through. The problem will then

http://www.live.com/

http://www.microsoft.com/presspass/ofnote/9-16mrktshare.mspx



be formally stated, interpreted, analysed and approached with designs. Eventually a complete

design will be implemented and its realisation will be documented. The final stages of the

report will provide an evaluation to the final implementation, a description of what I have

learnt and a discussion of any professional issues. At the end of the report will be a

bibliography and appendices.

2. Background

2.1 Pre-Design Research

One of the earliest decisions to make was whether to use a datagram socket (UDP based) or a

normal socket (TCP based). User datagram protocol (UDP) is optimised to send short packets

of information (datagrams). This information is unreliable in that the packets representing it

may arrive disorganised and duplicated or the packets may not arrive at all. Speed is the

advantage of this approach as there is no time spent checking if packets arrived and, for a file

transfer program, high speed transfers are desirable (see also [10]

). These advantages and

disadvantages (as well as some extras) are summarised in table 2.1.1.

Transmission control protocol (TCP) already provides reliability in data streams by

delivering packets in order, discarding duplicate packets, controlling the flow (ensuring the

receiver‟s buffer is not overflowed), retransmitting lost packets, controlling the congestion

(preventing network overload) and checking errors (through checksums) (see also [9]

). These

advantages and disadvantages (as well as some extras) are summarised in table 2.1.2.

2.1.1



With the recent implementation of version 6 of the Internet Protocol (IPv6) the successor to

IP version 4 (IPv4), jumbograms which are IPv6 packets containing payloads longer than

65535 bytes [8]

seemed like an attractive prospect. Jumbograms are defined formally in RFC

2675 http://tools.ietf.org/html/rfc2675. Unfortunately the abstract of this document states “It

also describes the changes needed to TCP and UDP to make use of jumbograms” clearly

showing that with the current state of TCP and UDP jumbograms are not viable. These

advantages and disadvantages (as well as some extras) are summarised in table 2.1.3.

Another decision to make focussed on file compression specifically which format to use to

compress the files. The ZIP file format was one option the main advantage of it is

compatibility in that it is already natively supported by Java and later versions of Windows [6]

. The alternative was the 7-Zip file format. Table 2.1.4 summarises the superior

compression of 7zip.

2.1.2

2.1.3

http://tools.ietf.org/html/rfc2675



This table was taken directly from the 7zip website [5]

, they say that the “FILE SETS:

[included] Mozilla Firefox 1.0.7 for Windows and Google Earth 3.0.0616 for Windows after

full installation.” They reached the conclusion that “Compression ratio results are very

dependent upon the data used for the tests. Usually, 7-Zip compresses to 7z format 30-70%

better than to zip format. And 7-Zip compresses to zip format 2-10% better than most of

other zip compatible programs.”

2.2 Project Requirements from Research

My program must be able to send files of any size and therefore ensuring the data stream

integrity is essential. The only way to prevent the various problems posed by UDP transfers

would be to add my own checks to the packets, in other words, reinventing the wheel. These

problems are solved with TCP and although jumbograms are an attractive prospect they are

not yet viable as a solution. Other protocols are and will be available that may provide even

more advantages over TCP with no cost, but the decision was made to use normal TCP

sockets because the TCP protocol is currently the most widely supported.

The 7-Zip file format was chosen instead of WinZip due to improved compression ratios and

a premade Java implementation which is available at the 7zip website [5]

. It was necessary to

implement the compression and decompression autonomously. Of course the users get to

choose if they want to compress the files but they would be mostly unaware of the

compressed files after transit in that as soon as the compressed files are transferred the

contents are decompressed and the compressed files are deleted. This removes any possible

confusion if the users are unfamiliar with the 7-Zip file format, it is probable that most would

not even have a tool capable of decompressing the compressed files and therefore it should be

the program‟s responsibility.

During the development I have tried to use the standard Java API as much as possible to

ensure compatibility and readability are maintained. Compatibility is essential for portability

which in turn is necessary for the program to be simple and user friendly. Not only should the

user expect the program to work on their own system but they should also expect it to work

on their friend‟s or colleague‟s system, this will help to improve the popularity of the

2.1.4



program. Readability is essential for development in that if either I or another programmer

were to come back at a later date and examine the code we should be able to make sense of it

and be able to trace back any sources used. If I used a lot of non-standard Java classes the

code may be difficult to follow if the sources of those non-standard classes were not available

later on.

Please note that these requirements have only followed from my research and are not a

complete set of requirements, all the requirements will be explicitly stated in section 3.4.

3. Specification

3.1 Introduction

This section is intended to clarify the expectations on what the project should accomplish, to

define a project plan, to describe the functionality of the program, the external interfaces

including how the program will interact with users and their systems, the expected

performance of the functions of the program, the attributes of the program including its

portability, correctness, maintainability and security and any design constraints imposed on

the implementation.

3.2 Problem

Direct file transfers are too difficult to setup for non specialists and indirect file transfers

cannot be used instead because they have lower efficiencies. Popular programs with the

ability to transfer files have major flaws. For example Windows Live Messenger which

transfers files indirectly, cannot resume transfers, does not support compression, cannot send

folders and has lower transfer rates. Another example would be FileZilla which can transfer

files directly, but is difficult to setup with the client and server programs being separate along

with an overwhelming number of features, the vast majority of which, non specialists would

not understand. The problem is worth addressing because the results have the potential to

improve transfer rates, transfer reliability and transfer efficiency specifically for, but not

limited to, non specialists in computing.

3.3 Project Description

3.3.1 The project’s target audience is mainly my supervisor but also anyone interested in

transferring files, mainly over the Internet, and therefore it must be simple enough to be used

by people who are not very computer literate and efficient enough, fast enough and reliable

enough to compete with other file transfer programs already available.

3.3.2 The aim of this project is to produce a piece of software with the ability to directly

transfer files over a network as autonomously as possible ensuring speed, efficiency,

reliability and usability are at high standards. This could either be a local area network (LAN)

such as a home or business network or, a wide area network (WAN) such as the Internet. The

solution is unlike peer-to-peer networks such as BitTorrent because it is intended for private

use between two people who presumably know each other.



3.3.3 The proposed solution is a Java program which when executed provides the user with

a GUI (Graphical User Interface). The deliverables given in 3.4 explain how the aim will be

achieved.

3.4 Statement of Deliverables

3.4.1 Software

(Essential) The program must use direct connections between users in order to

potentially maximise transfer rates.

(Essential) The program must be able to transfer any type of file which means each

file must be interpreted using its underlying bit pattern.

(Essential) The program must maintain the directory structure of folders which are

transferred this means metadata must be exchanged before transfers.

(Essential) The program must be able to resume transfers if they are stopped for

which the recognition of partially completed files is essential.

(Essential) The program must be able to determine if files are different which will

require some sort of checking system such as hash checking.

The program must have a simple user friendly interface that is easy to navigate and

understand by:

o (Conditional) Taking up less than a third of their screen space provided they

are using a resolution no smaller than 1024x768 in pixels.

o (Conditional) Ensuring new users who can read and understand English can

learn how to use the program within 10 minutes.

(Optional) The program should be able to compress and decompress files

autonomously.

(Essential) The program must be portable so that it is compatible with the major

operating systems.

3.4.2 Documentation

(Conditional) API (Application Programming Interface) documents for the programs

source code are highly desirable.

(Conditional) A user guide is highly desirable.

3.4.3 Experiments

(Essential) The program must be tested over a WAN to ensure users‟ can potentially

maximise upload and download rates.

(Essential) The program must be tested over a LAN to ensure transfers can be

conducted over an internal network.

(Essential) Copies of files must be purposefully corrupted in order to see if the

program can replace them with incorrupt copies.



(Essential) All GUI components must be tested not just on their own but also in all

possible combinations with each other to ensure compatibility.

3.4.4 Evaluation

(Essential) For evaluation the final program must be compared in size, speed, ability

to resume, ability to transfer folders, ability to compress and operating system support

to Windows Live Messenger and Filezilla.

3.4.5 Functionality

The GUI will allow the user to do the following functions which are ranked by importance

with the lower numbers being more important:

1. (Essential) To select a directory to download files to, given the user has write

permissions to write to that directory.

2. (Essential) To open at most one port on their system.

3. (Essential) To select a file to send provided the user has read permissions to read

from that file.

4. (Essential) To enter a host IPv4 address and port (identifying who the sender wants to

send the file or folder to) as long as a port has been opened.

5. (Essential) To send a file or folder provided a port has been opened by the program,

the host IPv4 address and port have been entered and a file or folder has already been

selected.

6. (Essential) To close only the port they have opened provided one has been opened.

7. (Essential) To allow both the sender and the receiver to stop a transfer once the file or

folder has begun to be transferred.

8. (Conditional) To allow both the sender and the receiver to pause a transfer once the

file or folder has begun to be transferred.

9. (Conditional) To allow both the sender and the receiver to resume transfers they have

previously paused. However the sender will not be able to resume transfers paused by

the receiver and vice versa.

10. (Conditional) To allow both the sender and the receiver to skip the current file in a

multiple file transfer once it has begun.

11. (Optional) To choose whether or not to use compression.

12. (Optional) To copy the users returned IPv4 address (whether it is their internal or

external IPv4 address) along with their specified port number (whether the port is

open or not).

13. (Optional) To open the directory to download files to provided one has been selected.

14. (Optional) To open the selected file to send provided one has been selected.

If any of the required information is not input into the program then it should output an error

message indicating this to the user if they try to send a file or folder. Moreover to prevent the

user from opening more than one port at a time the open port control should be disabled after

it has been used until the port is closed, likewise only after the open port control has been

used should the close port control become enabled and when it has been used it should be



disabled. The sender should not be able to use the send control more than once at a time and

when they do use it they should not be able to alter the inputted host IPv4 address or port. If

the user wants to perform multiple transfers they should use multiple ports and program

instances. Neither the receiver nor the sender should be able to close ports during a transfer.

Finally the sender should not be able to select another file during a transfer and the receiver

should not be able to change the download directory during a transfer.

It is important both the sender and the receiver have the same controls over the transfer so

that neither one will be favoured over the other in the interests of both fairness and

cooperation. Furthermore it will be important to make sure that synchronization is maintained

no matter if the receiver, the sender or both are using their controls. These controls should

only be enabled when files are being transferred and if the user presses their skip or stop

buttons then their controls should be disabled until either the next file is being sent or a new

transfer is started.

3.5 Conduct of the Project Plan

3.5.1 Preparation

The background research already absorbed before the design stage began included the

comparison between normal (TCP) sockets and datagram (UDP) sockets, the inapplicable

IPv6 packets (jumbograms) and the comparison between 7zip and WinZip compression.

During the early stages of the design stage I needed to read about the various Java Swing

components which were instrumental in building the GUI. Moreover information on how to

package Java classes into executable JAR files was needed for knowing how to distribute the

program to various operating systems (see also [15]

). I also needed to find out how to perform

hash checks, specifically MD5 and SHA and to make a comparison to decide which to use.

There was no data that needed to be acquired for this project, only background research and

user feedback were required.

3.5.2 Design Stage

The design methods that will be used follow from the agile software development approach,

the spiral model and object oriented design methodology allowing for a rapid cyclic

development. This will involve interlacing the design and implementation using user

feedback to produce a series of prototypes which will be refined through a series of iterations.

The design documentation will include requirements analysis, interface designs, class

diagrams, use case diagrams, state diagrams, dependency diagrams, class responsibility

descriptions, API documentation and method Pseudocode.

3.5.3 Implementation Stage

The program will interact with the user entirely through the GUI mainly using written text

and numbers to convey information such as the names of files or the transfer speed but also

using colour and graphics such as coloured icons where appropriate. The program will



interact with the system wholly through the Java Virtual Machine making use of the user’s

hardware including the VDU and graphics to display the GUI. A keyboard and mouse can

and are expected to be the input hardware. The program will also at least attempt to make use

of the user‟s wide area network or local area network depending on which is available

specifically using the TCP/IP protocol. Moreover when receiving a file the program will

interact with the user‟s hard disk or, other storage device, including external mass storage

devices but, excluding discs requiring the information to be burnt onto them, in order to save

the file. Similarly to any other piece of software the program will be stored in the RAM (or

equivalent) when being executed and will use the processor to carry out its instructions.

The software the program will use includes only the 7zip Java package version 4.6 beta from

http://www.7-zip.org/sdk.html in order to compress and decompress files.

Most of the programs functions should be carried out in a matter of seconds with a few

exceptions. Obviously the speed of sending or receiving a file or folder will depend on the

network connection speed and this cannot be known. Also compressing a file or folder will

depend on the size of the file or folder, the type of a file or the types of the files in a folder,

the processor speed and the amount of RAM available.

Once a feature is implemented it will be tested on the major operating systems and in

conjunction with other features, any errors will be recorded along with proposed solutions.

Considering the features to be included the types of tests that are expected include a speed

test to see how fast transfer rates (in upload/download capacity) across both a wide and local

area network reach. Across a WAN transfer speeds should potentially maximise in either

upload or download capacity depending on if the program is sending or receiving a file/folder

respectively. Also the program is expected to be tested to see if it can transfer directories

whilst maintaining their structures and to see if it can detect corrupt or incomplete files and

correct them. The most difficult tests expected are to see if users can pause, skip and stop

transfers without their programs loosing synchronisation or crashing.

3.5.4 Risk Assessment

The major challenges in carrying out this project are ensuring synchronization and program

stability is maintained between users transferring files and the program is as autonomous,

requiring the least amount of information, as possible.

The new skills required for this project will be acquired through experience and include

dealing with Java Swing components and sockets, performing hash checks, packaging Java

classes into executable JAR files, using the Netbeans IDE (see also [11]

) effectively, using

profilers to monitor program resources and interpreting and acting on user feedback.

http://www.7-zip.org/sdk.html



3.6 Gantt Chart [1]



4. Design

4.1 Noun Extraction

GUI (graphical user interface)

Directory

File

External or internal IPv4 address

Port

Compression

Controls

Synchronization

4.2 Verb Extraction

to select

to open

to close

to download

to [upload]

to copy (their own external or internal IPv4 address)

to choose (whether or not to use compression)

to pause

to resume

to stop

to skip



4.3 Interface Design

Final design

This image portrays the interface final design for my program that is, the GUI (graphical user

interface) that the user will interact with. For earlier designs and user feedback please refer to

12.1 in the appendices.

4.4 Evaluation Design

Criteria demonstrating a successful system:

1. Files the program claims to have transferred successfully must have the same MD5

hash check as the original files.

2. Folders the program claims to have transferred successfully must have the same

directory structures as the original folders.

3. The program must be smaller in size compared to Windows Live Messenger and

FileZilla.

4. Transfers over the Internet should be able to occur at maximum bandwidth in both the

upload and download capacities for users.

5. The program must be self contained in that there must be only one file to execute to

run it.



6. New users who can read and understand English and have at least a basic level at

using computers must be able to understand how to use the program within 10

minutes.

How to assess these criteria:

1. The third party MD5 hash checking utility called “MD5.exe” from

http://www.whitsoftdev.com/md5/ will be used to generate hashes for transferred and

original files to be compared.

2. The structures of transferred folders and original folders will be compared manually

using the operating system.

3. The sizes of Windows Live Messenger and FileZilla will be easily obtainable by

downloading the latest versions from their websites and these will be compared with

the final size of the program which can be determined using the operating system.

4. The time taken to transfer files of known sizes across the Internet by uploading and

downloading can be recorded from which transfer rates can be obtained and used to

check the full bandwidth of users‟ connections is being used.

5. Check users need only execute one file on their operating system to run the program.

6. A sample of random new users will be asked to try and use the program (after being

given 10 minutes to read the user guide) to firstly receive a specific file from me and

then secondly to send that same file back to me.

The people involved in the evaluation will be me and users of the program some of which

must be new users to meet some criteria.

The testing that will be carried out will have the purpose of both ensuring the criteria

demonstrating the program is successful are met and that the program also functions as

expected. Fortunately for the most part these two branches can be covered with the same tests

because essentially the program needs to work for it to be successful. Although the internal

structure (the underlying source code) of the program will be somewhat complex, considering

the minimum amount of information users can input it will be possible to perform white box

testing from the internal perspective of the system.

My expected conclusion from the evaluation is that the program functions properly

outperforming Windows Live Messenger‟s transfer rates and is found to be much simpler

than FileZilla.

4.5 Class Diagrams

Class diagrams are static structure diagrams that are meant to help explain the system

properties. The size of the project prevents all aspects of the class diagrams being displayed

together therefore the first set of diagrams will show the attributes of the classes. The

TransferGUI class as implied by the name mainly controls the visual side of the program.

During a transfer it will work alongside the UpdateReceive and UpdateSend classes both of

which handle GUI updates relating to the transfer attributes (speed, time remaining, percent

done) for the receiver and sender respectively. The Send and Receive classes do the majority

of the work involved in actually transferring files calling most of their methods from the

Connect class which is a sort of repository for methods transfer related. The Buffer class is

http://www.whitsoftdev.com/md5/



used exclusively by the sender and is meant to set up and refresh buffers used to store the file

data in order to prevent the entire file being stored in memory. The Pause class is also used

exclusively by the Sender and has the sole purpose of waiting for input from the receiver

during a transfer so that the receiver is able to use their controls. Finally the GetIP class is

used by the TransferGUI class and does exactly what it suggests by determining the user‟s

internal or external IPv4 address. The LzmaAlone class which is the main class of the 7Zip

package is also used by both the Receive and Send classes in order to decompress and

compress files respectively.



4.5.1



4.5.2



4.5.3

4.5.4

4.5.5



The second diagram will show the class relationships but their attributes will be contracted

because they are already expanded in sections 4.5.1 to 4.5.9.

4.5.6

4.5.7

4.5.8

4.5.9

4.5.10



4.6 Use Case Diagrams

4.6.1 Use case diagram for user functions

In this diagram the dashed lines between functions represent dependencies where the origin

of the line is the function that requires information and the arrowhead points to a function

where that information is taken from. Dashed lines between the User and functions with the

word “permission” written in the middle represent that the User can use these functions

provided they have met the permission criterion. Solid lines represent functions the user can

use unconditionally when the program is running.



4.6.2 Use case diagram for network operation

In this diagram the dashed lines between functions represent dependencies where the origin

of the line is the function that requires information and the arrowhead points to a function

where that information is taken from. Specifically in order for User 2 to receive a file he/she

must have already accepted the file/folder and in order to accept the file/folder he/she must

have already accepted the connection and for a connection to be established User 1 must have

tried to send a file/folder to User 1. This diagram also shows User 1 can compress a

file/folder before sending it in which case User 2 may have to decompress the file/folder after

receiving it. Although this diagram shows User 1 as the sender he/she could also be receiving

a file from User 2 in which case the diagram would be repeated and reversed.

4.7 State Diagrams

4.7.1 State diagram for user functions

This diagram shows the various states the system moves through when the program functions

are used. Note that the pause, skip and stop functions are excluded from this diagram for

simplicity.



4.7.2 State diagram for network connections (sending)

This diagram shows in more detail the state transitions involved when a file is sent. Note that

if the program was exited that would also stop the transfer.



4.7.3 State diagram for network connections (receiving)

This diagram shows in more detail the state transitions involved when a file is received. Note

that if the program was exited that would also stop the transfer.



4.8 Dependency Diagrams

Dependency diagrams are visual representations of dependency graphs and are meant to

outline the complex correspondence between the various functional elements.

4.8.1

4.8.2

TransferGUI dependency diagram. Here TransferGUI

implements ActionListener, creates instances of the

Connect and GetIP class and uses the various

datatypes shown. GetIP depends on TransferGUI

creating it but TransferGUI also uses the GetIP class

during its initialization and so the dependency is

bidirectional.

Connect has no dependencies with my other classes

although it does depend on several datatypes.



4.8.3

4.8.4

Receive implements Runnable and

depends on methods from both

Connect and TransferGUI.

Similarily to Connect it also

depends on several datatypes.

Send implements Runnable and

depends on methods from both

Connect and TransferGUI.

Similarily to Connect it also

depends on several datatypes.



4.8.5

4.8.6

UpdateSend extends TimerTask

and depends on methods from

only Connect. Also it depends on

only a few datatypes.

UpdateReceive extends TimerTask

and depends on methods from

only Connect. Also it depends on

only a few datatypes.



4.8.7

4.8.8

4.8.9

Pause implements Runnable and depends on methods

from Connect.

GetIP depends only on TransferGUI

as well as the String datatype.

Buffer extends TimerTask

and depends on the

FileInputStream datatype.



4.9 System Sequence Diagram (SSD)

Part 1



Part 2



This diagram shows an overview of what will happen between classes (external actors) when

first receiving a file and then sending a file. Although a vast number of methods have been

omitted, a high level of abstraction is necessary in order to express the most important

messages invoked by these actors.

4.10 Method Pseudocode

The following section will attempt to describe the entire logic of the methods in all of the

classes in a natural language representation called Pseudocode. Compact mathematical

notation may be used instead of natural language if it is more convenient and helps omit

unnecessary details. There is no universal standard for Pseudocode as it is intended to be read

by people rather than computers but consistency will be maintained in the style used and

explanations provided where necessary. The aim is to allow the implementation to become

simply a translating task into source code. The vocabulary will be that of the problem domain

rather than the implementation domain so that someone who knows the requirements can

easily see how the solution is to be realised. In the following methods private means the

method can only be accessed by the class it is in, protected means only the class it is in or

subclasses or the package it is in can access it and public means it can be accessed anywhere.

See the appendix for full details and method descriptions; the most vital methods are here.

4.10.1 TranserGUI

public void ActionPerformed(ActionEvent e)

{

Here an ActionEvent is some input received by the GUI represented as e.

IF the resumeSend button is pressed THEN

o IF the transfer is active THEN indicate it should be paused

o ELSE indicate it should be resumed

IF the skipSend button is pressed THEN

o Indicate the current file should be skipped

o Disable the transfer controls (pause, skip, stop)

IF the stopSend button is pressed THEN

o Indicate the transfer should be stopped

o Disable the transfer controls

IF the resumeReceive button is pressed THEN

o IF the transfer is active THEN

Send a message to the sender telling them to pause it

Indicate it should be paused

o ELSE

Send a message to the sender telling them to resume it

Indicate it should be resumed

IF the skipReceive button is pressed THEN

o Send a message to the sender telling them to skip the current file



o Indicate the sender‟s Pause thread will not need to be stopped by the receiver


IF the stopReceive button is pressed THEN

o Send a message to the sender telling them to stop the transfer

o Indicate the sender‟s Pause thread will not need to be stopped by the receiver


IF the saveTo button is pressed THEN

o Open a window allowing the user to choose where to save downloaded files to

o IF the selected directory can be written to THEN

Display the absolute path of the directory in the GUI

Pass this information to the Connect class

o ELSE display an error message indicating this

IF the openFolder button is pressed THEN

o IF a folder is selected THEN use the operating system to open the folder

which points to the directory to download files to

IF the copyIP button is pressed THEN copy the IP determined by the GetIP class to

the clipboard

IF the socket button is pressed THEN

o IF the port is closed THEN

Open the port

Indicate it is open

Prevent the user from changing the port number they opened

Allow the user to enter a host IP

Allow the user to enter a host port

Enable the send button

Start a new Receive thread

o ELSE

Close the port

Indicate it is closed

Allow the user to change the port number they closed

Prevent the user from entering a host IP

Prevent the user from entering a host port

Disable the send button

IF the browseFile button is pressed THEN

o Open a window allowing the user to choose a file

o IF the selected file can be read from THEN

Store the selection

Display the absolute path of the file in the GUI

IF the openFile button is pressed THEN

o IF a file has been selected THEN open it

IF the send button is pressed THEN

o IF a host IP AND port have been entered AND a file has been selected THEN

Disable the open/close port button



Disable the compress checkbox

Disable the send button

Start a new Send thread

o ELSE display an error message describing what information is missing

IF the compress checkbox is ticked THEN indicate compression should be used

otherwise indicate it should not be used

IF the help button is pressed THEN display the user guide in a text box in a new

window with the same icon as the main window

IF the about button is pressed THEN display the about information along with a large

beaver icon in a new window with the same icon as the main window

IF the hide button is pressed THEN

o IF a system tray is supported THEN minimize the program to an icon in the

system tray which is able to bring up a popup menu if right clicked and

display download/upload speeds if hovered over

}

4.10.2 Connect

protected void receiveFile()

{

IF the receiver‟s socket is connected and the transfer is not stopped THEN

o IF a 0 is received from the senderHashCheck method THEN

Indicate in the GUI the hash check failed

Rename the file

Create a new file with the original name

o ELSE

Indicate the hash check succeeded

o Start the UpdateReceive task

o Enable the transfer controls

o WHILE the total number of received bytes is less than the size of the file

being sent and the transfer has not been stopped THEN

Read bytes from the receiver‟s socket‟s input stream into a buffer

IF a single byte is read or a -1 is read indicating the end of the stream

THEN stop the transfer

ELSE write the bytes to the output file

o FINALLY

Disable the transfer controls

Stop the UpdateReceive task

Reset the pause button and associated fields

Update the GUI one last time

IF the whole file wasn‟t received AND at least 10 bytes were received

THEN truncate the file by 10 bytes because control information may

have been written



IF the stream writing to the file is not closed THEN close it

IF the receiver must stop the sender‟s Pause thread THEN send a

signal to it to stop it

ELSE reset the variable to indicate the sender‟s Pause thread should be

stopped by the receiver

}

protected void sendFile(File f)

{

IF the sender‟s socket is connected and the transfer is not stopped THEN

o Calculate the number of pieces of fixed length that are in the file and the size

of the remainder

o Start the Pause thread

o Start the UpdateSend task

o Start the Buffer task

o Enable the transfer controls

o WHILE there are pieces to send and the transfer has not been stopped THEN

WHILE the transfer is paused by the sender OR the receiver AND it

has not been stopped AND the socket has not been closed THEN wait

Write bytes from the current buffer obtained from the Buffer task to

the sender‟s socket‟s output stream

When all the bytes from the current buffer have been written request

the next buffer from the Buffer task

o IF all the pieces have been sent AND the transfer is not stopped THEN

Write the remainder


Cancel the Buffer task

Cancel the UpdateSend task

Update the GUI one last time

Wait for the Pause thread to die

o ELSE

Write a 0 to stop the receiver waiting for data


Cancel the Buffer task

Cancel the UpdateSend task

Wait for the Pause thread to die

IF the file was skipped THEN send a 1 to the receiver to indicate this

ELSE send a 0

o FINALLY

IF the file input stream (fis) is initialised THEN close it

Stop the Buffer task

Stop the UpdateSend task

Reset the GUI

}



4.10.3 Receive

public void run()

{

Wait for a connection

IF the server socket is open and the receiver accepts the connection THEN

o Reset the progress bars

o Indicate to the receiver the program is waiting for file information

o Disable buttons which can't be used during the transfer

o Get and display the sender's IPv4 address

o Get the size of the file being sent

o Get the name of the file being sent

o IF the receiver accepts the file THEN

Indicate to the receiver the program is exchanging file information

Get the names and paths of the file(s) being sent

Get the hashes of the file(s) being sent

Setup the file(s) that need to be received

Send a list of the file(s) that do not need to be sent

Send the sizes of the file(s) that the receiver already has that should be

sent

Send the hashes of the file(s) that the receiver already has that should

be sent

IF the sender indicates the file(s) is(/are) compressed THEN

Indicate the file(s) is(/are) compressed

Get the size of the compressed file(s) being sent

Get the hashes of the compressed file(s) being sent

Setup the compressed file(s) that need to be received

Send a list of the compressed file(s) that do not need to be sent

Send the sizes of the compressed file(s) that the receiver

already has that should be sent

Send the hashes of the compressed file(s) that the receiver

already has that should be sent

ELSE indicate the file(s) are not compressed

FOR all the file(s) that need to be received

Indicate in the GUI and internally which file is being received

and its size

IF the receiver's file cannot be written to THEN skip it

ELSE do not skip it

IF the file should not be skipped THEN

o Set the maximum size of the dpb to the file's size

o Indicate to the sender the file should be sent

o Receive the file



ELSE indicate to the sender the file should not be sent

IF the file(s) were compressed THEN

Indicate in the GUI they are being decompressed

Pass them to the decompressFiles method in this class to decompress

them and to delete the compressed files

Reset the progress bars

o ELSE reset the progress bars

o Call the refresh method in this class

o ELSE IF the receiver rejected the connection THEN reopen the server socket

}

4.10.4 Send

public void run()

{

IF a connection is successful in that the receiver accepted the connection and the

socket is now connected THEN

o Reset the progress bars

o Indicate to the sender the program is preparing file information

o IF the file is a folder AND readable THEN

Add it to a file vector called filesVector

Add its name to a String vector called namesPaths

Add its path to namesPaths

Add its hash to a String vector called sendHashes

Repeat this for its contents by using the prepareFileInformation

method in this class

o IF the file is a file AND readable THEN

Add it to a file vector called filesVector

Add its name to a String vector called namesPaths

Add its path to namesPaths

Add its hash to a String vector called sendHashes

Increment totalSize with its size

o Send the size of the file or folder

o Send the file‟s or folder‟s name

o IF the receiver sends a 1 indicating they have accepted the file or folder THEN

Indicate to the sender the program is exchanging file information

Send namesPaths

Send sendHashes

Get the removeIndicies vector which indicates which files to send

Get the receiveFileSizes vector which stores the sizes of the files being

sent that the receiver already has

Get the receiveHashes vector which stores the hashes of the files the

receiver already has



Remove any files that should not be sent using the removeFiles method

in this class

IF the user requested that the file or folder be compressed THEN

Send the receiver a 1 indicating the file or folder will be

compressed

Indicate in the GUI that the files are being compressed

Compress the file or folder using the compressFiles method in

this class

Send totalSize

Send sendHashes

Get the removeIndicies vector again

Get the receiveFileSizes vector again

Get the receiveHashes vector again

Use the removeFiles method again with this information

ELSE send the receiver a 0 indicating the file or folder will be

uncompressed

FOR all the files that need to be sent

Indicate to the sender which file is being sent

Send its size to the receiver

Get an integer from the receiver

IF the integer is equal to 1 THEN

o Set the maximum size of the upload progress bar to the

file's size

o Hash check the file to decide if it should be resumed or

resent

o Resend or resume the file

o Indicate the next file should be received

ELSE IF the inetger received is not equal to 2 THEN stop the

transfer

IF the user requested the file or folder to be compressed THEN

FOR the number of files in filesVector

o IF any have a name ending with ".J7z" THEN delete

them

o ELSE reset the progress bars to normal

o Call the refresh method in this class

ELSE report a connection could not be established

}

4.10.5 UpdateReceive

public void run()

{

IF 0 bytes are received for a large period of time THEN close the connection



IF 0 bytes are received for a small period of time THEN indicate in the GUI that the

speed is 0 and the estimated time is infinity

Update the download speed and download time labels

Update the download progress bars

}

4.10.6 UpdateSend

public void run()

{

IF 0 bytes are sent for a large period of time THEN close the connection

IF 0 bytes are sent for a small period of time THEN indicate in the GUI that the speed

is 0 and the estimated time is infinity

Update the upload speed and upload time labels

Update the upload progress bars

}

4.10.7 Buffer

public void run()

{

WHILE buffers need to be refreshed

o Clear the first buffer that needs to be refreshed

o Read into the buffer that has been cleared

o Remove the buffer that has been refreshed from the list of buffers that need to

be refreshed

}

protected byte[] requestNextBuffer()

{

WHILE all the buffers are waiting to be refreshed

o Wait for a small amount of time for one to become available

IF a buffer outside the index of the buffers available is next THEN set the pointer to

the first buffer

ELSE set the pointer to the current buffer

Increment to the next buffer

Return the previous buffer

}

protected void resetBuffer()

{

IF the first buffer is the next one to be used THEN set the index to point to the last

buffer



ELSE set the index to point to the previous buffer

Add the index pointing to the buffer that needs to be refreshed to the list of buffers to

be refreshed

}

4.10.8 Pause

public void run()

{

WHILE the receiver is making requests that have not told this thread to stop AND the

transfer has not been stopped

o IF the receiver is making requests that have not told this thread to stop and the

transfer has not been stopped THEN wait for the receiver's input

o IF the receiver inputs a 7 and the transfer has not been stopped THEN pause

the transfer

o IF the receiver inputs a 6 and the transfer has not been stopped THEN resume

the transfer

o IF the receiver inputs a 5 and the transfer has not been stopped THEN

Skip the current file in the transfer

Stop this thread after setting the current file to be skipped

o IF the receiver inputs a 4 and the transfer has not been stopped THEN

Stop the transfer

Stop this thread after setting the transfer to be stopped

}

4.10.9 GetIP

private String determineIP(Vector<String> URLS)

{

DO

o Attempt to open an URL from URLS

o Attempt to setup an input stream to the URL

o Read the first line of the URL as an array of characters

o FOR all the characters in that line

IF a character is a dot or a number append it to a String called

myFinalIP

o IF this succeeded THEN do not loop

o ELSE IF there are more URLs available THEN loop

WHILE if it should loop

IF the user's external IPv4 address has not been found THEN

o Attempt to get their internal IPv4 address instead

o Notify them about what has happened

RETURN myFinalIP



}

5. Testing

The following table displays the problems encountered during testing. Testing was carried

out on stable versions of the program, each of which usually incorporated an extra feature or

part of the functionality. The tests were carried out on both LANs and WANs but the latter

usually took longer to arrange as this involved user participation which required mutually

convenient times. User participation was usually arranged via instant messaging where IPv4

addresses and feedback were exchanged. Testing over a LAN was made possible by using the

loopback (localhost) IPv4 address “127.0.0.1” which allowed file transfers from and to the

same computer. However WAN testing was also necessary because there is almost no latency

involved with a LAN and no packet loss. Both white box (internal perspective) and black box

(external perspective) testing was carried out in order to test all possible paths and that the

specification had been fully implemented especially regarding functionality.

Problems Causes Solutions

Could not use

the close port

button.

The server socket

was not initialized

in some cases.

The server socket

was listening for

connections.

Check before trying to close the server socket that it

has been initialized.

Set a timeout when listening for connections so it can

check if it should still listen for connections or not

after a set time period of listening.

Time taken for

the GUI to

appear could

be very long.

Network activities

were being

performed (trying

to determine the

user‟s external

IPv4 address)

before the GUI

was being drawn.

Rearranged the code so that the GUI is drawn first.

The speed and

time could take

a long time to

be updated.

Only one timer

was associated to

all the GUI update

tasks and to refresh

the buffer (in the

case of the sender)

meaning there was

too much code to

execute in the

given time leaving

some tasks

unfinished after

each execution.

Created new Timers so that each TimerTask had its

own Timer allowing them to be run in parallel which

ensures all the code in each task is executed.

Hash checking

multiple files

Hash checking for

each file was

Changed the code so that all the files are hash

checked as a batch before the program begins

5.1



could take an

extremely long

time.

performed before

that particular file

was to be sent.

transferring. This is more efficient because it allows

the computer to focus on one repetitive task rather

than a repetition of a sequence of tasks. CPU usage

during hash checking shows this as it is increased

making it faster.

The same part

of the file

being sent

would be

written

multiple times

to the file

being received.

The wrong buffer

was being used, it

was not being

refreshed or

changed.

Fixed the code in the Buffer class so the buffer is

updated properly.

The program

would

sometimes

lock up after

trying to skip a

file or stop the

transfer.

Network

congestion could

cause the

information telling

the program to

skip a file or stop

the transfer to not

get delivered as

expected.

Checks have been put in place to ensure if the

program remains in a locked state for a certain period

of time where no data is being transferred then the

connection on either end should be terminated with

the sockets being closed. This would reset the

connection between the sender and the receiver

allowing a new one to be established.

6. Realisation

The design was implemented in Java using the Netbeans IDE for support following the

method Pseudocode listed in 4.10 and 12.3.

One change made during the implementation was to exchange most of the file information

before the transfer began as opposed to during the transfer; the information exchanged

included names, sizes, relative locations, hashes, etc. Advantages of this approach were that it

sped up the hash checking procedure because all the files were done at the same time and it

could be determined which files did not need to be transferred thus preventing time being

wasted transferring any more information about them.

Another change implemented in the GUI was to merge the open/close port buttons into one

button so that when you pressed one it would change into the other button and the same

principle was also applied to the pause/resume buttons. Moreover there were a multitude of

component layout changes made in the GUI during its development and these are best

portrayed in the screenshots which are shown in the appendix. The purpose of the component

layout changes was primarily to improve the aesthetics and simplicity the program but also to

try and make it conform to expectations such as having buttons which are not too big and to

reduce the size on screen to a minimum to make the program seem as least invasive as

possible. One of the major changes in the GUI was to include progress bars where the

original idea was to have a text area which would show the progress through text. Obviously



the advantage of progress bars is that they are easier to interpret than reading a line of text but

are more difficult to implement.

One more alteration made in the GUI was adding methods which altered how information

regarding the time remaining and sizes were displayed. Originally the time remaining was

calculated to be in minutes but this was changed to display hours, minutes and seconds much

like a digital watch. The advantages of this are that it is a more natural display and can take

up a lot less space for very large transfers. Sizes were originally only displayed in kilobytes

but this was changed to display sizes in the most appropriate form of either bytes (B),

kilobytes (kB), megabytes (MB) or gigabytes (GB). I could of also included terabytes (TB)

but I decided not to as it is nearly impossible anyone would be sending a file or folder that

large, most people currently do not even have hard drives able to store such a capacity. Sizes

would automatically be adjusted to the largest scale they are able to form one or more whole

units of and would be rounded up to two decimal places. A further smaller change to the GUI

involved adding colour to JLabels which are Strings of text using html (hyper text markup

language) and adding icons to buttons and windows. The advantage of these changes were

that they helped the components express their meanings more effectively.

Early in the program development there were no plans to implement a Buffer class or in fact

to use buffers at all, the fact that loading the entire file into memory beforehand would

consume an immense amount of memory did not come into play because early transfers

involved relatively small files. The fact I had overlooked this feature showed my newness to

programming in this area and how much I have adapted since then to bring the development

to the working stage it is at now. It was the introduction of the Buffer class which brought

about another major change in the program structure because after it was introduced

alongside the UpdateReceive and UpdateSend classes the performance degraded to the point

where the speed was unacceptably slow. It was at this point it became necessary to use

TimerTasks instead of threads.

Throughout the implementation there would often be points where the efficiency could be

improved by reducing the impact on the memory or processor usage. An example of an

alteration that would reduce the memory usage would be where a field was replaced by a

local variable allowing the memory used by it to be reclaimed once its method had finished.

A major change involved turning the Buffer, UpdateSend and UpdateReceive threads into

TimerTasks instead which greatly improved performance under areas such as transfer speed

reducing the impact on the processor. A small change concerning failed hash checked files

was to rename instead of deleting them because they may coincidentally have the same name

or be modified but not corrupt.

A potential use of the program only became apparent after the abilities to send folders and

hash check files were implemented. This potential use is the synchronisation of folders across

a network. For example imagine two users have a game installed but one of the files in a

user‟s game directory is corrupt and the user does not know which file it is. The other user

could use the program to try and send their uncorrupted copy of the game directory to the



same place that the other user‟s corrupt game directory resides. This would cause the

program to hash check and compare all the files between both users‟ game directories and

eventually the hash check would fail for the corrupt file. This would cause the program to

rename the corrupt file so that the sender can send their copy. This would fix the receiver‟s

game but in the process other files might be renamed and replaced as well because some files

may include game settings or user profile information which would make them unique.

However the original files could easily be recovered because similarly to the corrupt file they

would be renamed rather than deleted.

Although a requirement had already been set specifying the program should output an error

message if something were to go wrong, the means by which it would do this changed during

the implementation. Originally there was going to be a text box within the GUI where all the

messages including error messages would be output. However it was decided not to use the

text box as it would not be user friendly. Another other option was to use text files to log the

errors which would be saved to the user‟s hard drive. However a third option arose which

was considered to be the most user friendly and was chosen instead. This option similarly to

most professional applications was to use a new window to display the error message instead.

The main advantage involved in this approach would be the fact that the error message would

be displayed clearly which would make it easier for the user to read hopefully improving

their chances of understanding it.

A toolbar was added to the top right of the program with three buttons; “Hide”, “Help” and

“About”. The “Hide” button minimizes the program to the system tray if the operating system

supports a system tray. The “Help” button displays the user guide that is in the appendix. The

“About” button displays the developer‟s (my) name and a copyright notice next to a larger

beaver icon in a new window. Originally the “X” button which, is standard in most operating

system windows, had its function altered so that it minimized the program to the system tray.

However I thought it would be counter intuitive to alter the functions of the standard window

buttons and so decided to restore their original functionality and add new buttons with the

special functionality instead. Some general but potentially useful information was added to

the top left and top middle of the program which was the user‟s operating system name and

Java Runtime version respectively.

7. Evaluation

This table shows a comparison between my program and the two others I‟ve used in

comparison. The main differences are the sizes and compatibility in that my program is

extremely small compared to the other two and can run on most popular operating systems.

Name Size

(KB)

Speed

unlimited?

Can

resume

downloads?

Can

transfer

folders?

Client

and

server

in

Most

popular

operating

systems

Compression

Supported?

7.1



one? supported?

RMFT 181 Yes Yes Yes Yes Yes Yes

Windows

Live

Messenger

Up to

50000

No No No Yes No No

FileZilla About

22600

(client +

server

program)

Yes Yes Yes No No Yes

Objectives Achieved? If so how?

The program must use

direct connections between

users in order to potentially

maximise transfer rates.

Yes. ServerSockets and Sockets are used which make use of

the TCP/IP protocol to establish direct connections between

users which potentially maximise transfer rates.

The program must be able

to transfer any type of file

which means each file must

be interpreted using its

underlying bit pattern.

Yes. Files are sent and received as a stream of bytes and since

all files can be interpreted in this manner, any type of file can

be sent.

The program must maintain

the directory structure of

folders which are

transferred this means

metadata must be

exchanged before transfers.

Yes. All the information about files (metadata) is exchanged

before the actual file is transferred including names, sizes and

hash checks.


to resume transfers if they

are stopped for which the

recognition of partially

completed files is essential.

Yes. If a file exists that is smaller or the same size and of the

same name as the file being sent then it is hash checked against

the file being sent (up to an equal size), if it succeeds and is

smaller, the rest of the file is sent by resuming the transfer.


to determine if files are

different which will require

some sort of checking

system such as hash

checking.

Yes. MD5 hash checking is used to determine if files or parts

of files are the same.

Files the program claims to

have sent successfully must

have the same hash as the

original files.

Yes. MD5 hash checks of files sent successfully using the

program can be seen to be the same using “MD5.exe”. Any

other hash checking utility will also show them to be

equivalent.

The program must have a

simple user friendly

interface that is easy to

navigate and understand.

Yes. User feedback has been positive regarding the simplicity

and ease of use of the program. Users given the program for

the first time figured out how to fully use it in under 10

minutes.

7.2




to compress and

decompress files

autonomously.

Yes. The 7zip Java package has been successfully

implemented into the program. It compresses files before they

are sent and decompresses them after they have been received.

Compressed files are deleted after they have been sent in the

sender „s case or decompressed in the case of the receiver.

The program must be

portable so that it is

compatible with the major

operating systems.

Yes. The program has been made using the Java programming

language and can be operated on any operating system which

can run the Java virtual machine which includes all the major

operating systems such as Microsoft Windows, Linux and

Macintosh.

Table 7.2 shows the objectives have been achieved as portrayed in both test runs and user

feedback. These accomplishments include the following: any type of file can be transferred,

directories are accepted as valid transferrable objects and are able to maintain their structure,

transfers can be paused, resumed and stopped and in instances where more than one file is

being transferred individual files can be skipped, portability is maintained by programming

for operating system neutrality using Java, files can be compressed and decompressed

autonomously. Judging the user interface/GUI is almost completely subjective except for

characteristics such as the accuracy of the information it displays (e.g. is the text used spelt

correctly?). Therefore the best approach and the one that was adopted was to take user

feedback into account, it was under the influence and the advice of this feedback that several

GUI redesigns were conducted.

Users who were not computer literate struggled to understand the concept of opening and

closing ports and using an IPv4 address to identify the receiver. However this information is

necessary and could not be omitted, moreover even if the user did not understand the

concepts that would not prohibit them from using them. In fact the program made clear that a

file could only be sent if a port was open, an IPv4 address was entered and a file was selected

and since the program also clearly tries to display to the user their own IPv4 address it should

not be difficult for a computer illiterate person to realise this is what they must pass on to the

sender. One potential weakness of the GUI is that it stands against certain conventions such

as a program is usually expected to have the standard “File, Tools, About” menu bar

displayed at the top thus possibly acting against users‟ preconceptions. On the other hand

users usually quickly catch on to the style of the simplicity implemented in the GUI and it

does not take long for users to become accustomed to the layout of the components.

Despite the successes of the program there is always room for improvement and if I had more

development time there are a variety of ideas I believe would make worthy contributions.

Firstly I would seek a larger audience in order to collect more user feedback with the main

aim of improving the GUI including aspects such as layout, sizes, colours, etc. However I

would also allow users to specify features they believe are desirable in their feedback but

would ask that the suggestions be little to no more complex than existing features so they are

not vastly outside the scope of my abilities. This approach would hopefully help identify any

necessary components I may have overlooked eventually leading to an improvement in the

program and its popularity if they were implemented correctly. Secondly I would try to add in



another layer of security not so much for the rare if not impossible circumstance where two

users engaging in a transfer do not trust each other but for the area of computer virus

detection and prevention of infection. Thirdly I would try to make the code more efficient and

more open for innovations so for example the transfer speed could possibly be improved.

Fourthly I would try to create and include with each distribution simple help documentation

explaining concepts which may need to be understood such as the process of port forwarding

from behind a firewall or router. Fifthly I would try to develop the 7zip package myself or

find some development that has already taken place which I could use on it to support

features including displaying compression speed and percent complete. Sixthly I would add

multilingual support for users who cannot read English. Seventhly I could add support for the

automatic conversion of certain file types such as video with the aim of reducing the size or

perhaps to allow users to only transfer selected segments. In this case all conversions would

have to render the target file smaller or of equal size because quality can never increase when

converting from one file type to another, only the size can increase. Eighthly I could add

support for the ftp (File Transfer Protocol) so that the program could communicate with other

file transfer programs such as FileZilla. Tenthly I could implement a command line interface

for users who are unable to use the GUI. Finally I could add support for the program to be

integrated with popular programs like Windows Live Messenger.

8. Learning Points

Differences between TCP and UDP sockets and transfers.

The use of alternatives to the Thread class in the Java API (see also [7]

) like the

TimerTask class.

The use of alternative types of streams in the Java API such as the RandomAccessFile

output stream or the ObjectInputStream.

Handling new Swing components including JProgressBars and JCheckBoxes.

Improved use of Swing components such as including icons in JFrames.

Using the Netbeans IDE specifically how to create UML diagrams and structures and

debugging methods such as using line breaks or/and attaching profilers.

Methods for dealing with unpredictable user input.

Packaging classes into executable JAR files.

Differences between executable JAR files and Windows binary EXE files.

Details of hash checking methods including MD5 and SHA, the differences between

them and how to use them.

How to integrate HTML and Swing components.

The interpretation of user feedback and how to act on it.

Details of the 7Zip file compression such as its advantages over conventional

compression methods such as ZIP file compression and using the 7Zip Java

implementation to compress and decompress files.

Thread interaction over a network including how to maximise the efficiency between

them and also ensuring synchronization is maintained.



How to improve aesthetic qualities to allow components to fit a certain style to

improve its appeal to users.

9. Relationship to the British Computer Society Code of Practice

[3]

The 1st responsibility states the following:

“Information Systems Practitioners shall seek to upgrade their professional knowledge and

skill and shall maintain awareness of technological developments, procedures and standards

which are relevant to their field, and shall encourage their subordinates to do likewise.” [3]

I have been required to significantly research various areas explored throughout this project

most of which are outlined in the learning points. Moreover I have been using the most up to

date technologies such as the latest version of the Netbeans IDE for the development or the

latest Java classes like the Desktop API within the implementation of the project. I always

insist that any user of my program (including testers) upgrade their Java to the latest version

to avoid any compatibility issues. Due to Java being free to download there are no problems

posed by this request especially since the project is a file transfer program and requires

downloading/uploading.

The 2nd responsibility states the following:

“The Practitioner has a duty of professional care to abide by those BCS sector-specific

Codes of Practice which have any bearing on the practitioner‟s current role.” [3]

The BCS sector-specific Codes of Practice in this case I can assume are The University of

Liverpool Computer Science Department‟s own code of conduct which has been followed.

The 3rd responsibility states the following:

“Should the Practitioner discover any difficulty in applying a Code of Practice, he or she shall

immediately bring it to the attention of the BCS Registrar.” [3]

No difficulties have been found in applying The University of Liverpool Computer Science

Department‟s own code of conduct.

Additionally I have kept in close touch with and contributed to current developments in the

project areas by for example joining the Java group on Facebook to receive regular updates or

maintaining a high level of reusability within my code. Also I have recognised the scope and

applicability of methods and have resisted pressure to use inappropriate methods at various

times. For example when considering how to read a file into the application I decided to use

buffers instead of transferring the entire file into memory even though it was a much more

complicated method.

In relation to the aims and objectives of The University of Liverpool programme undertaken

my loyalty was divided between first and foremost potential users of my program and

secondly fellow information system practitioners. Part of the primary aim was to setup direct



connections between users. This involved opening ports which can leave users vulnerable and

thus it was my responsibility to provide some level of protection. The protection was twofold,

firstly only one port would be allowed to be opened at any one time, a measure to decrease

the likelihood of attack and secondly to make sure users have the option to reject incoming

connections or files to prevent attacks.

Almost all of the methods coded for the program are reusable either in part or in whole with

some being directly reusable while others would need slight modifications. This allows

fellow information system practitioners to improve their professional knowledge and skill by

being able to understand, given that they have the corresponding documentation, and apply

my methods in their work.

10. Relationship to the British Computer Society Code of Conduct [4]

The 1st part of the public interest section states:

“You shall carry out work or study with due care and diligence in accordance with the

relevant authority‟s requirements, and the interests of system users. If your professional

judgement is overruled, you shall indicate the likely risks and consequences.” [4]

Throughout this project I have ensured I have followed The University of Liverpool

Computer Science Department‟s own code of conduct and my judgement has not been

overruled any point and so that part does not apply to me.

The 2nd and 3rd parts of the public interest section do not apply to me because there is no

health, safety and/or environmental issues and neither are there any third parties who will be

affected by this project who are not directly aware of its existence.

The 4th part of the public interest section states:

“You shall ensure that within your professional field/s you have knowledge and

understanding of relevant legislation, regulations and standards, and that you comply with

such requirements.” [4]

I have full knowledge of The University of Liverpool Computer Science Department‟s own

code of conduct and of relevant legislation such as The Data Protection Act of 1998 or The

Computer Misuse Act of 1990.

The 5th and 6th parts of the public interest section are almost entirely irrelevant as I do not

have clients/customers or colleagues in this project. However I do have testers and users and

they have not been discriminated against in any way or bribed and they will testify to this.

The 7th, 8th and 9th parts under the duty to relevant authority section are also largely

irrelevant because there is no way a dispute could occur between me and my relevant



authority and even if there was due to the trust and openness between us this would be likely

to resolve. Also I have no confidential information except my code nor do I have any

information that can be misrepresented or withheld to my benefit.

The 10th part under the duty to the profession section states:

“You shall uphold the reputation and good standing of the BCS in particular, and the

profession in general, and shall seek to improve professional standards through participation

in their development, use and enforcement.” [4]

I have followed this by trying to promote public understanding of information systems for

example within the documentation for my program I have explained concepts such as ports

and IPv4 addresses. I have also tried to support fellow members in their professional

development by offering advice. The 11th part is mostly irrelevant as I am working alone

other than occasionally seeking advice from professionals with whom I try to maintain

relationship integrity. The 12th

part is irrelevant as I am not in a position to make public

statements. The 13th

part is irrelevant as I have no criminal offences and am not a company

director. The 14th

part under professional competence and integrity has been covered

previously, as for the 15th

part under the same section I have not made any claims of

competence that I do not possess and this is proven by the fact that the project‟s goals were

completed successfully. I have observed the relevant BCS Codes of Practice above which

covers the 16th

part and I accept professional responsibility for my work which covers the

17th

and final part.

11. Bibliography

1. COMP391/2: Calendar http://www.csc.liv.ac.uk/~comp39x/2008-

09/calendar_391.html

2. COMP391/2: Project report: Content and Structure

http://www.csc.liv.ac.uk/~comp39x/2008-09/report_391.html (used throughout)

3. The British Computer Society Code of Practice

http://www.csc.liv.ac.uk/~comp39x/2008-09/BCS_CoP.pdf

4. The British Computer Society Code of Conduct

http://www.csc.liv.ac.uk/~comp39x/2008-09/BCS_CoC.pdf

5. 7zip Java Package source files http://www.7-zip.org/download.html

6. WinZip http://www.winzip.com/index.htm

7. Java API http://java.sun.com/j2se/1.5.0/docs/api/

8. IPv6 packets containing a payload (useful data) longer than 65,535 octets

(jumbograms) ftp://ftp.isi.edu/in-notes/rfc2675.txt

9. RFC 793 DARPA Request For Comments for TCP (Transmission Control

Protocol) http://www.faqs.org/rfcs/rfc793.html

10. RFC 768 DARPA Request For Comments for UDP (User Datagram Protocol)

http://www.faqs.org/rfcs/rfc768.html

11. Netbeans IDE http://www.netbeans.org/ (used throughout)

12. Java forums http://forums.sun.com/index.jspa (used throughout)

13. Java Runtime Environment http://www.java.com/en/ (used throughout)

http://www.csc.liv.ac.uk/~comp39x/2008-09/calendar_391.html

http://www.csc.liv.ac.uk/~comp39x/2008-09/calendar_391.html

http://www.csc.liv.ac.uk/~comp39x/2008-09/report_391.html

http://www.csc.liv.ac.uk/~comp39x/2008-09/BCS_CoP.pdf

http://www.csc.liv.ac.uk/~comp39x/2008-09/BCS_CoC.pdf

http://www.7-zip.org/download.html

http://www.winzip.com/index.htm

http://java.sun.com/j2se/1.5.0/docs/api/

ftp://ftp.isi.edu/in-notes/rfc2675.txt



http://www.netbeans.org/

http://forums.sun.com/index.jspa

http://www.java.com/en/



14. Java Software Development Kit (SDK)

http://java.sun.com/javase/downloads/index.jsp (contained necessary tools for

compiling, documenting, packaging)

15. Packaging programs in JAR files

http://java.sun.com/docs/books/tutorial/deployment/jar/

16. Using HTML (Hyper Text Markup Language) in Java Swing components

https://java.sun.com/docs/books/tutorial/uiswing/components/html.html (used

throughout writing the source code)

17. Using UML (Unified Modelling Language) in Netbeans

http://www.netbeans.org/features/uml/index.html (used throughout, see design)

18. Alexa The Web Information Company

http://www.alexa.com/data/details/traffic_details/get.live.com/messenger

19. IconArchive for most of the icons used within the program

http://www.iconarchive.com/ (used to get most of the icons used in the program)

20. IEEE 830-1998 Recommended Practice for Software Requirements Specifications

http://changecontrol.googlecode.com/files/IEEE%20830-

1998%20Recommended%20Practice%20for%20Software%20Requirements%20S

pecifications.pdf (used throughout)

12. Appendix

12.1 Interface Design (full details)

User feedback: 12.1.1 First design

The text box is not user friendly; it

makes the program look complicated.

It is inconvenient to have to tell the

program when a file is about to be sent

to it using the “Wait For File” button.

http://java.sun.com/javase/downloads/index.jsp

http://java.sun.com/docs/books/tutorial/deployment/jar/

https://java.sun.com/docs/books/tutorial/uiswing/components/html.html

http://www.netbeans.org/features/uml/index.html

http://www.alexa.com/data/details/traffic_details/get.live.com/messenger

http://www.iconarchive.com/

http://changecontrol.googlecode.com/files/IEEE%20830-1998%20Recommended%20Practice%20for%20Software%20Requirements%20Specifications.pdf





User feedback: 12.1.2 Second design

Buttons are large and do not look similar

to the buttons users are used to.

The grouping of functions is not well

thought out as users often have to re-

examine the entire application to find out

what they must do next.

The host port and I.P boxes are very

large but the user‟s I.P box is very small.

The progress bars look “lob-sided” due

to their different sizes.

The save directory and send directory

boxes span the entire width of the

application unnecessarily.

User feedback: 12.1.3 Third design

Current file name, time remaining and

transfer speed are quite important when

sending files. This information should be

displayed.

The status of hash checks should be

given so users know why files might be

replaced.

There is no choice for compression.

There are no controls to stop, skip and

pause/resume transfers.

The panels at the bottom look out of place since there are three in a row followed by

two in a row.



User feedback: 12.1.4 Fourth design

There is no button to minimize the

program to the system tray.

There is no help button explaining how

to use the program and there is no about

button which is common to most

professional applications.

Users‟ Java Runtime versions (see also [13]

) and their operating systems are not

displayed and would be helpful to know

if they needed technical support.

12.1.5 Other user feedback:

The application doesn‟t mix well with visually native applications.

Progress bars are also different from native progress bars.

Lack of branding or a logo makes the application appear somewhat less user friendly

and unprofessional.

Prefer buttons to have an icon that I can remember, saves time re-reading buttons to

quickly navigate the application

To make the application look more user friendly and also highlight the important (and

likely to change) elements, colour could be used.

The title of fields and the text in them should perhaps have different colours.

Many windows pop up during the file transfer process, slightly confusing and

annoying.

Note that this user feedback cannot be shown to be accomplished in these general layout

designs but, it can be seen from the screenshots that all of this user feedback has been

satisfied.

12.2 Class Responsibilities

12.2.1 TransferGUI

The TransferGUI class will be responsible for setting up the visual elements of the program

and handling all the user input. Moreover it will be responsible for program safety by

ensuring the components are disabled/enabled at the right times for example it will ensure the

port cannot be closed during transfers. It will also hold useful methods for other classes that



wish to interact with the user interface such as a method which can generate error messages

or one which can truncate text in the middle.

12.2.2 Connect

The Connect class will have no responsibilities by itself because it will not be run however it

will be the most used class. It will work by acting as a repository for other classes because it

will contain a wide range of methods most of which are for sending/receiving information

over a network including the two key methods “Send” and “Receive” which together transfer

files. Others which will be included are convenience methods such as “convertToHex” which

will allow a byte array to be converted into a hexadecimal String. There will be methods

which help optimise the GUI such as the method “timeFormat” which will convert a given

time in seconds to one showing the hours, minutes and seconds. Finally there will be a few

methods used to refresh the program such as the “refreshReceiver” and “refreshSender”

methods which will reset all the fields back to their original values.

12.2.3 Receive and Send

The Receive and Send classes will be responsible for calling all the methods necessary to

cooperate with each other in a manner which results in a file being transferred successfully.

The Connect class will be responsible for the synchronisation within methods but the Receive

and Send classes will be responsible for the synchronisation in the use of the methods. The

order the methods are called must follow a strict sequence otherwise one users program might

be expecting a specific piece of information but end up receiving something completely

different which can result in corruption. For example if one program was expecting to receive

the name of the file but the other program had managed to skip to sending the raw bytes

within the file the result would be a long name composed of random characters interpreted

from the byte stream. A good analogy might be to consider the Connect class as the workers

and the Receive and Send classes as the managers who would direct the worker‟s duties and

try to maintain a smooth operation. However there will also be some important methods

contained in the Send and Receive classes which will help organise their internal arrays.

12.2.4 UpdateReceive and UpdateSend

The Send and Receive classes have responsibilities that are relatively easy to visualise using

the analogy outlined previously if we assume the TransferGUI is the factory where the

workers and managers are operating then these classes would be maintenance crew perhaps

cleaning the windows to ensure everything can be seen clearly and up to date. What these

classes will actually do is update parameters relating to transfers including time remaining

and speed. Although they have only a few responsibilities they are extremely important to the

user because without them there would be no visual feedback during transfers.

12.2.5 Pause

The Pause class will have a relatively small responsibility of simply listening out for and

acting on information sent to the sender from the receiver during a transfer. This information

will be regarding some sort of control the receiver wants to use over the transfer in progress



including pausing/resuming it, skipping files (when multiple files are being sent) and

stopping it. In the analogy this class would be a correspondent between the two managers but

only during the transfer.

12.2.6Buffer

The Buffer class will be like a conveyor belt in the factory moving goods from one manager

(the sender) to the other (the receiver) it will have properties such as how many items can be

put on the conveyor belt at once and whether or not multiple conveyor belts are running. The

actual responsibility of this class will be to ensure the program doesn‟t use too much memory

by limiting how much of the file the sender can load at a time for transmission. However it

will also be responsible for ensuring there is never any holding up in that there will always be

data ready to be transferred.

12.2.7 GetIP

The GetIP class will have a variety of responsibilities but none of them are necessary for the

program to function effectively. Its main responsibility will be the task of obtaining the user‟s

external IPv4 address, failing this it will try to obtain the user‟s internal IPv4 address. Once

an IPv4 address has been obtained the class can then be asked to report it so that it can be

used. The class is also responsible for allowing the user to copy whichever IPv4 address it

can return to the clipboard alongside the user‟s chosen port. In the analogy this class would

be most like an informant for the managers because the IPv4 address would make the

program more accessible as that is the piece of information a potential sender requires.

12.3 Method Pseudocode (full details)

12.3.1 TranserGUI

private TransferGUI()

{

Make the GUI by calling the buildGUI method in this class

Initialize the GetIP class

Display the user's internal or external IPv4 address using the GetIP class

Show the absolute path of the current save directory (the program's location by

default)

Initialize the Connect class

Warn the user if they are using an older Java Runtime Version (less than 1.6)

}

private void buildGUI()

{

Set the look and feel to that of the operating system

Create and layout the components

Set the icon of the GUI



Set the GUI to a fixed optimal size

Add basic functionality to the GUI

Show the GUI

}

protected void errorMessage(String text, String title)

{

Make a new window using the title and text passed in

Set the icon of the window to be the same as the GUI (main window)

Display the window

}

protected void truncateStringMiddle(String line, JComponent component, int lineWidth, int

extraWidth)

{

Here line is one line of text passed in, component is a JComponent and is just an object which

contains the line, lineWidth is the width of the line and extraWidth is some extra amount of

width.

Initialize a String called finalString

IF (component width < (lineWidth + extraWidth)) THEN

o WHILE (component width > finalString width) add characters from the front

and back of line so that finalString will have the start and end of line but be

missing some of the middle

ELSE finalString = line

RETURN finalString

}

protected void receiverBusy()

{

Disable the open/close port and download directory browse buttons

}

protected void setHostIP(String IP)

{

Set the host‟s IP to the IP text passed in

}

protected boolean incomingFile(String text, String title)

{

Make a new window using the title and text passed in

Set the window to have two options, accept or decline

Set the icon of the window to be the same as the main window



IF the window is closed OR the decline option is pressed THEN

o Indicate the file has been rejected

o Send a message to the sender to signify this

IF the accept option is pressed THEN

o Indicate the file has been accepted

o Send a message to the sender to signify this

RETURN true if the file was accepted

}

protected void senderReady()

{

Enable the send, compress and open/close port buttons

}

protected void receiverReady()

{

Refresh the port by closing it and opening it again

Reset variables to indicate the next transfer will not be paused or stopped

Start a new Receive thread to listen for connections

Enable the download directory browse and open/close port buttons

}

public void Main(String[] args)

{

A String[] is an array of Strings (i.e. a collection of more than one String) represented by the

variable args.

Initialize the TransferGUI class (which calls the TransferGUI() method)

}

12.3.2 Connect

protected void Connect()

{

Initialize fields used in this class

}

protected void setPath(File p)

{

Here File is just a type of object which represents a file or folder in the file system.

Set the path of the file to send to p which is the folder passed in.

}



protected void openPort(String p)

{

Here Socket is a type of object which represents an endpoint for communication between two

machines.

Parse p (taken directly from the GUI) as an integer

Create a new server socket on the port indicated by that integer

}

protected void listenWait()

{

Set the server socket to timeout after a set time when listening for connections

WHILE the server socket is initialized AND the user wants to listen for incoming

connections THEN accept incoming connections

IF the user does not want to listen for incoming connections THEN

o IF the server socket is initialized THEN close it

}

protected boolean connect(String hostIP, String hostPort)

{

Convert hostIP (the host‟s IP address) from a String into a proper IPv4 address object

Parse hostPort (the host‟s port) as an integer

Create a new socket based on this information which is connected to the host‟s IPv4

address and port

RETURN true if the connection was established successfully

}

protected boolean testClose()

{

IF the server socket is initialized THEN test if it is closed

RETURN true if the server socket is closed

}

protected int getReady(Socket in)

{

IF in is connected THEN

o Read a single byte of data from its input stream

o Interpret this as an integer

RETURN this integer

}

protected void sendReady(Socket out, int i)



{

IF out is connected THEN write the integer i to its output stream

}

protected int receiveInteger(Socket s)

{

IF s is connected THEN

o Initialize an array of bytes

o sendReady(s,1) (to indicate the socket at this end is ready to receive an

integer)

o Read bytes from the input stream of s into the byte array

o Interpret the bytes read as an integer

o Return this integer

}

protected void sendInteger(Socket s, int i)

{


o getReady(s) (to ensure the socket at this end waits until the socket at the other

end is ready)

o Decompose i into an array of bytes

o Write the byte array representing i to the output stream of s

}

protected String receiveChars()

{


o Initialize an array of bytes

o sendReady(s,1) (to indicate the socket at this end is ready to receive an

integer)

o Read bytes from the input stream of s into the byte array

o Interpret the bytes read as characters

o FOR each character add it to a String

RETURN the String

}

protected void sendChars(Socket s, String st)

{


o getReady(s) (to ensure the socket at this end waits until the socket at the other

end is ready)

o Decompose st into an array of bytes

o Write the byte array representing st to the output stream of s



}

protected Object receiveObject(Socket s)

{

IF s is connected THEN read an object from the input stream of s

RETURN the object

}

protected void sendObject(Object o, Socket s)

{

IF s is connected THEN write o to the output stream of s

}

private String convertToHex(byte[] data)

{

Here StringBuffer is an Object that has various methods for constructing Strings.

Initialize a new StringBuffer buf

FOR each byte in data

Shift four 0s to the left of the byte's bit pattern discarding bits moved to the right then

perform a bitwise AND operation with the bit pattern 00001111 essentially taking the

first half of the bit pattern

DO

o IF the integer the new bit pattern represents is between 0 and 9 inclusive

THEN append the integer to s

o ELSE append the hexadecimal latter the integer represents to s

o Take the second half of the byte‟s bit pattern

WHILE both halves have not been processed

RETURN s

}

protected String hashCheck(File f)

{

IF f is a file (not a folder)

o WHILE all the file has not been read

Read the bytes into a buffer

Update the hash with the bytes from the buffer

RETURN convertToHex(hash) (the calculated hash bytes converted to a hexadecimal

String)

}

protected void senderHashCheck(File f, int i, String s)

{



Here i is the size of the file to calculate the hash from and s is a hexadecimal hash to test

against which is generated from the receiver‟s file.

IF the length of the file is greater than i THEN

o WHILE the file has not been read for i number of bytes

Read the bytes into a buffer

Update the hash with the bytes from the buffer

o IF convertToHex(hash) (the calculated hash bytes converted to a hexadecimal

String) matches s THEN

Send a message to the sender indicating the hash check succeeded

Indicate in the GUI the hash check succeeded

o ELSE

Send a message to the sender indicating the hash check failed

Indicate in the GUI the hash check failed

ELSE

o Send a message to the sender indicating the hash check failed

o Indicate in the GUI the hash check failed

}

protected Socket getSenderSocket()

{

RETURN the sender‟s socket

}

protected Socket getReceiverSocket()

{

RETURN the receiver‟s socket

}

protected void receiverTime()

{

Calculate how long it has taken the receiver to perform a task started at the receiver‟s

start time

}

protected void resetReceiveTimer()

{

Set the receiver start time to the current system time

}

protected void resetBr()

{

Set the number of bytes received (br) to the total number of bytes received (tr)



}

protected void senderTime()

{

Calculate how long it has taken the sender to perform a task started at the sender‟s

start time

}

protected void resetSendTimer()

{

Set the sender start time to the current system time

}

protected void resetBs()

{

Set the number of bytes sent (bs) to the total number of bytes sent (ts)

}

protected int getTr()

{

RETURN the total number of bytes of the current file received by the receiver

}

protected int getTs()

{

RETURN the total number of bytes of the current file sent by the sender

}

protected int getBr()

{

RETURN the number of bytes of the current file being downloaded already received

by the receiver before the transfer began

}

protected int getBs()

{

RETURN the number of bytes of the current file being uploaded already sent by the

sender before the transfer began

}

protected double getRet()

{

RETURN the end time for a timed period for the receiver

}



protected double getSet()

{

RETURN the end time for a timed period for the sender

}

protected int getRc()

{

RETURN the total number of bytes of all the files received by the receiver

}

protected int getSc()

{

RETURN the total number of bytes of all the files sent by the sender

}

protected String timeFormat(long t)

{

Here we are using the assumption that t is a time in seconds.

Calculate the number of hours, minutes and seconds in t

IF (hours < 10) THEN put a 0 before the number of hours (such as 00)

ELSE keep it the same

IF (minutes < 10) THEN put a 0 before the number of minutes (such as 09)


IF (seconds < 10) THEN put a 0 before the number of seconds (such as 05)


RETURN a String formed from the hours minutes and seconds

}

protected void setupFiles(Vector<String> np, Vector<String> sh, Vector<Integer> rfs,

Vector<File> nfv, Vector<Integer> ri, Vector<String> rh)

{

Here a Vector<Type> is a dynamic array holding of objects of Type that can grow or shrink

to accommodate more or less elements.

np stores names and paths of the files to be sent

sh stores hexadecimal hashes of the files to be sent

rfs stores the sizes of the receiver‟s files

nfv stores references to the receiver‟s files

ri stores integers indicating which files the sender should send

rh stores hexadecimal hashes of the receiver‟s files



FOR every file

o IF a root directory has not been set THEN set the file to be downloaded to

where the user has selected

o ELSE set the file to be downloaded to the root directory plus any additional

directories the file is in

o IF the file‟s hexadecimal hash is empty (indicating it is a directory)

IF the root directory is not set

Set the root directory

Set the root directory path

Indicate the root folder has been set

Create the directory

o ELSE create the file

o IF it is a file

Calculate its hash

IF its hash matches the corresponding sender's file's hash THEN add a

0 to ri indicating it should be removed

ELSE

Add the file to nfv

Add its hash to rh

Add its size to rfs

Add a 1 to ri (indicating it should be kept)

o ELSE add a 0 to ri indicating it should be removed

}

protected String speedFormat(int i, int j, double k)

{

Here i is the number of bytes transferred in a time k and j is the number of bytes to disregard.

Calculate the transfer speed in B/s

IF the transfer speed is 1kB/s or more format the speed to be in kB/s

IF the transfer speed is 1MB/s or more format the speed to be in MB/s

RETURN the formatted speed

}

protected labelFormat(int i, int j)

{

Here i is the number of bytes transferred with the current file and j is the total number of

bytes transferred with all the files.

Set both numbers as doubles so that the following conversions are more precise

IF i is 1 kB or more format it to be in kB

IF i is 1 MB or more format it to be in MB

IF i is 1 GB or more format it to be in GB



IF j is 1 kB or more format it to be in kB

IF j is 1 MB or more format it to be in MB

IF j is 1 GB or more format it to be in GB

Round both numbers to 2 decimal places

RETURN the formatted labels

}

protected void truncateFile()

{

IF file is initialised AND exists AND is bigger than 10 bytes AND less than fileSize

THEN

o Truncate it by 10 bytes

o IF the stream writing to file is not closed THEN close it

}

protected void setFile(File f)

{

Set the file to send to the specified file f

}

protected File getFile()

{

RETURN the current file to send

}

protected void refreshReceiver()

{

Reset the receiver‟s fields and GUI ready for the next transfer

Close the connection to the sender

}

protected void refreshSender()

{

Reset the sender‟s fields and GUI ready for the next transfer

Close the connection to the receiver

}

protected void closePort()

{

IF the server socket is not closed THEN

o Do not listen for connections

o IF the server socket is initialized THEN close it

}



12.3.3 Receive

protected Receive(Connect c, TransferGUI t, JFrame f, JProgressBar d, JProgressBar dt,

JLabel df, JButton rr)

{

Initialize all the fields to the references passed in

}

private String truncateDownloadText(String s, String t)

{

Truncate the middle of s taking into account the length of t by using the

truncateStringMiddle method in TransferGUI

}

private void fixFileVectors(Vector<File> nfv, Vector<Integer> rfs, Vector<String> rh,

Vector<String> sh, Vector<Integer> ri)

{

nfv stores references to the receiver‟s files

rfs stores the sizes of the receiver‟s files

rh stores hexadecimal hashes of the receiver‟s files

sh stores hexadecimal hashes of the files to be sent

ri stores integers indicating which files the sender should send

FOR all the files originally in nfv

o IF the file is not compressed (does not end with “.J7z”) THEN

IF it is not already made THEN

Create the compressed, empty version of the file (a new file

ending with “.J7z”)

Hash check the file

IF its hash does not match the corresponding sender's file's hash

THEN

o Store its hash in rh

o Store its reference in nfv

o Store its size in rfs

o Store a 1 in ri (indicating it should be kept)

ELSE store a 0 in ri (indicating it should be removed)

o ELSE (the file ends with “.J7z”)

Hash check the file

IF its hash does not match the corresponding sender's file's hash THEN

Store its hash in rh

Store its reference in nfv

Store its size in rfs



Store a 1 in ri (indicating it should be kept)

ELSE store a 0 in ri (indicating it should be removed)

FOR the original number of files in nfv remove a file from the beginning of nfv

}

private void decompressFiles(Vector<File> fv, Vector<Integer> sfs)

{

fv stores references to the files to decompress

sfs stores the sizes of the sender's files

FOR all the files

o IF all of the file was received THEN

IF a file of the same name as the decompressed file already exists

AND it is not empty THEN rename it and decompress the file

o Delete the compressed file after it is decompressed

}

private void refresh()

{

Reset resources used in the Connect class

Reset the GUI

Reclaim unused resources

}

12.3.4 Send

protected Send(Connect c, TransferGUI t, JFrame fr, File f, String hip, String hp,

JProgressBar u, JProgressBar ut, JLabel uf, JButton rs, boolean b)

{

Initialize all of the fields to the references passed in

}

private String truncateUploadText(String s, String t)

{

Truncate the middle of s taking into account the length of t by using the

truncateStringMiddle method in TransferGUI

}

private void prepareFileInformation(File[] files, Vector<File> fv, Vector<String> np,

Vector<String> sh)

{

FOR all the files in files (the file array passed in)

o Add a reference to the file to fv



o Add the name of the file to np

o Add the path of the file to np

o Add the hash of the file to sh

o IF the file is a file (not a folder) THEN increment totalSize with the file‟s size

o IF the file is a folder then use this method on its contents

}

private void removeFiles(Vector<File> fv, Vector<Integer> ri)

{

FOR all the files in fv

o IF the number in the remove indicies vector corresponding to this file is 0

THEN remove it from fv

o ELSE keep the file

}

private void compressFiles(Vector<File> fv, Vector<String> sh)

{

FOR the original number of files in fv

o IF the file is not compressed (does not end with “.J7z”) THEN

IF it is not already made THEN

Create the compressed, empty version of the file (a new file

ending with “.J7z”)

Attempt to compress the original file and put the contents into

this new file

Add the compressed file to fv

Add the compressed file‟s hash to sh

Increment the total size in bytes by the new file's size

o ELSE (the file ends with “.J7z”)

Add the file to fv

Add the file‟s hash to sh

Increment the total size in bytes by the file's size

FOR the original number of files in fv remove a file from the beginning of fv

}

private void refresh()

{

Reset the resources used in the Connect class

Reset the GUI

Reclaim unused resources

}

12.3.5 UpdateReceive



protected UpdateReceive(Connect c, int i, JLabel ds, JLabel dtl, JProgressBar d, JProgressBar

dt)

{

Initializes all the fields to the references passed in

}

12.3.6 UpdateSend

protected UpdateSend(Connect c, int i, JLabel us, JLabel utl, JProgressBar u, JProgressBar

ut)

{

Initializes all the fields to the references passed in

}

12.3.7 Buffer

protected Buffer(FileInputStream is)

{

Initialize all the fields

FOR all the buffers set them to the predefined size

Start to read into the buffers

}

12.3.8 Pause

protected Pause(Connect c)

{

Initialize the only field to the reference passed in

}

12.3.9 GetIP

protected GetIP(TransferGUI t)

{

Initialize the only field to the reference passed in

}

private Vector<String> readURLS()

{

Attempt to setup an input stream linked to the text file containing the URLs

WHILE lines exist that have not been read in the text file THEN

o Read them

o Add them to a vector called URLS



RETURN URLS

}

protected void writeToClipboard(String writeMe)

{

Get the clipboard

Copy the String writeMe to the clipboard

}

protected String getIP()

{

RETURN the user's external or internal IPv4 address obtained from the other methods

in this class

}

12.4 User Guide

12.4.1 Requirements:

Minimum

VDU (visual display unit)

Input Device

Java Runtime Environment version 6 or later

Network Connection (LAN or WAN)

Recommended:

VDU (visual display unit)

Mouse

Keyboard

Java Runtime Environment version 6 or later

Network Connection (LAN or WAN)

Note that the Java Runtime Environment is free software provided by Sun Microsystems and

can be downloaded without charge from their website at:

http://www.java.com/en/download/index.jsp

12.4.2 Installation:

Copy the RMFT folder from the containing medium to your hard drive, the exact

destination does not matter as long as all the files within the folder are kept together.

However it is suggested to be somewhere you can find the folder easily such as “C:\”

or “C:\Program Files” on the Microsoft Windows.

12.4.3 Running:

http://www.java.com/en/download/index.jsp



To run the program, open “Transfer.jar” (located in the RMFT folder) which by

default should be opened with the Java Runtime Environment. The usual method to

accomplish this is to double left click the file using the mouse or press enter on it

using the keyboard after it has been selected.

Alternatively an advanced method to run the file if for example, the Java Runtime

Environment is not the default program to open .jar files with, is using a command

prompt with the command “java -jar Transfer.jar”.

12.4.4 Use:

Sending a file or folder:

1. Press the “Browse” button underneath “File To Send:” and in the new window

locate and select the file or folder you want to send and press “Open”. This

will tell the program which file or folder you want to send.

2. (OPTIONAL) Choose to compress the file by ticking the checkbox next to

“Compress”.

3. Press the “Open” button underneath “Your IP & Port:” this will tell the

program to open the default port (16567) which will be used for incoming

connections. Note that this port can be changed to a different port number if

the user wishes.

4. Enter the host IPv4 address and port into the left and right text boxes

respectively which are underneath “Host IP & Port:”. If the receiver is using

the default port (16567) then the port does not need to be entered but if they

have changed the port then it must be altered to match. The receiver should

somehow communicate their IPv4 address with you and it should be in the

same format as your IPv4 address displayed in the text box directly underneath

“Your IP & Port:”.

5. Ensure the receiver has opened their port, that no software is blocking the

program and press the “Send” button. If the receiver accepts your connection

and the file or folder you are trying to send you should see the transfer begin.

Receiving a file or folder:

1. (OPTIONAL) Press the “Browse” button underneath “Save Directory:” and in

the new window locate and select the folder you want to save downloads to

and press “Open”. This will tell the program where to save downloads.

2. Press the “Open” button underneath “Your IP & Port:” this will tell the

program to open the default port (16567) which will be used for incoming

connections. Note that this port can be changed to a different port number if

the user wishes.

3. Inform the sender of your IPv4 address and port so they know where to send

the file or folder to, for ease of use the “Copy” button underneath “Your IP &

Port:” can be pressed to copy your IPv4 address and port to the clipboard

ready to be pasted to the sender.

4. Ensure that no software is blocking the program and if you accept the

incoming connection and the incoming file or folder then you should see the

transfer begin.

12.5 Screenshots



This screenshot shows one of the earliest designs of the program GUI, as you can see it is

quite big and the layout is bulky. Also at this stage some of the features are missing such as

pausing/resuming and cancelling. Moreover the features which are shown were at a semi-

working stage for example the close port button did not work.

12.5.1



This screenshot shows one of the middle designs during the implementation, the layout is

almost the same as the current build and it is clearly a lot cleaner than the original but is still

missing some of the features such as time remaining, compression and colour.

This screenshot shows one of the later builds. Almost all of the features have been

incorporated at this point including time remaining, compression, colour, icons and skipping.

Moreover all the features appear to be fully functional and the program is able to perform

more efficiently and effectively compared to earlier versions.

12.5.2

12.5.3



This screenshot shows the beginning of the transfer process and in this instance the program

is both sending and receiving the file “data2.cab” which is actually located on a CD in a disk

drive. In order to send to itself the program is using the computer‟s own internal IPv4 address

as the “Host IP” which is “127.0.0.1” and it listening on and sending to port “16567”. As you

can see the first stage after the send button has been pressed is a dialogue allowing the

receiver to accept or decline a connection from the sender.

12.5.4



This screenshot shows the second stage in the transfer process at this point the receiver has

already accepted the sender‟s connection and is now being asked if they want to accept the

file the sender is trying to send them. It also shows the GUI informing the sender and the

receiver of information being exchanged.

12.5.5



This screenshot shows the third stage in the transfer process at this point the receiver has

accepted the file the sender is trying to send them and information regarding that file has

finished being exchanged allowing the data to be sent. As you can see the speeds, progress

bars and times do not match this is because each part of the GUI is updated separately and so

some parts may be more up to date than others. Moreover the speed is in the region of

“MB/s” which under normal circumstances of transferring files over the Internet would not

be obtainable without a fast connection. You can also see the hash check succeeded as you

would expect because the receiver had not received any of the file previously meaning the

hash check of 0 bytes saved matches the hash check of 0 bytes of the file. Upon completion

the file would be transferred.

12.5.6



This screenshot shows two instances of the program transferring a video file called

“BigVid.avi” between them. Notice that both programs use different ports because you

cannot have more than one instance of the program trying to control the same port on the

same computer. Thus the sender is listening for connections (to receive files) on port “16567”

and the receiver is listening for connections (to receive files) on port “16568”, the sender is

sending to the host port “16568” which is why the connection is established. This means the

sender could still receive an incoming file on its “16567” port and likewise the receiver could

12.5.7



still send a file to any port at any IPv4 address except its own even while this transfer is

taking place. Also note that I have used a different internal IPv4 address “192.168.2.5” in this

case. The difference between this IPv4 address and “127.0.0.1” is that the one used here is

assigned by my network router whereas the other is the standard IPv4 address used for a

loopback network connection.

This screenshot shows a file being compressed, unfortunately the third party compression

package did not include compression progress as a feature so an indeterminate progress bar

had to be used instead. The sender is compressing the file and creating the compressed

version in the same directory as the file itself. This compressed file has the custom extension

“.J7z” however this is just a chosen convention (standing for Java 7zip) it actually has no

bearing on the ability for the program to decompress the file. Once the file is compressed the

sender will send the compressed version to the receiver where it will be saved on their

desktop. When the transfer is complete the receiver‟s program will decompress the file and

delete the compressed version.

12.5.8



This screenshot shows the latest and possibly final build. More features have been

incorporated here including a hide (minimize to taskbar) button, a help button (which

displays the user guide), an about button (with some brief information) and some general

information about the user‟s system.

12.5.9



This screenshot shows the program downloading at maximum capacity for my 1.5MB

connection. Here the speed is limited by my connection as my maximum download speed is

lower than the other user‟s maximum upload speed (who is on a university network with

typically high upload capacities).

12.5.10

Richard Andrew Mealing COMP391 Project Report …mealingr/documents/Efficient Data...

Documents

Transcript of Richard Andrew Mealing COMP391 Project Report …mealingr/documents/Efficient Data...