high speed image transfer protocol team … · ability to pause and resume ˜le transfers at the...

1
Future Upgrades Ability to request and process remote file and directory listings. A GUI that resembles file transfer applications, showing both the local and remote file structure. Ability to pause and resume file transfers at the user's request. Filter recipients to prevent file transfers. HIGH SPEED IMAGE TRANSFER PROTOCOL Background Research Distributed Ground Stations recieve imagery from a variety of sources and must distribute it across the Distributed Common Ground System.The Existing methods for file transfer and replication are too slow to meet current demands. Goodrich wants a new protocol with better performance Requirements Testing Results Design Server Design Client Design across network links between Distributed Ground Stations. A new prototype of a mangement tool that utilizes this protocol is also desired by Goodrich. Developing a solution was the project focus. FTP 0ms FTP 100ms FTP 200ms FTP 300ms Tsunami 0ms Tsunami 100ms Tsunami 200ms Tsunami 300ms UDT 0ms UDT 100ms UDT 200ms UDT 300ms UFTP 0ms UFTP 100ms UFTP 200 ms UFTP 300 ms 0 100 200 300 400 500 600 0 0.1 1 5 10 TEAM SKYNET Aamir Allaqaband, Gustavo Catalano, Matthew Broadstone, Thomas J. Owens, Professor Michael Lutz (Faculty Coach) Server Design implemented in C++ Utilizes multiple reciever threads Design configurable by an INI file Unlimited incoming connections Uni-directional-only recieves data Client is implemented using Java Uses Barchart-UDT JNI wrapper Client is configurable by an XML file Multiple sender threads in a pool Client utilizes preallocated buffers 3 Dell Optiplex GX620 desktops 1 Keyboard and 1 Mouse FreeBSD 8.1 LCD Monitor KVM Switch RDyne Labs 10/100/1000 Ethernet Initial Review Individual Research Presentation to Group Testing UDT Tsunami UDP UFTP BitTorrent The file transfer protocol must be able to reliably transfer files between nodes, without errors. The performance must, under some network conditions, outperform the existing solutions currently deployed. System has no specific hardware or operating system. Process 0 10 20 30 40 50 60 Accepted Delivered Rejected Finished Started Unstarted Iterations were one week long, with the software in a usable state at the end of each iteration. Velocity for each iteration was tracked and used to plan workloads for the next iterations. Steady integration ensured that working builds at all times and products were available as needed. Weekly meetings were held to update Goodrich on our status and plan our next iteration. Senior Project 2010-2011 Although FTP performed well on clean networks, its performance degraded significantly whenever the network experienced latency and packet loss. UDP takes longer to achieve max throughput, but is able to maintain a greater throughput through extreme packet losses and latencies.

Upload: vuongthu

Post on 09-May-2018

218 views

Category:

Documents


4 download

TRANSCRIPT

Page 1: HIGH SPEED IMAGE TRANSFER PROTOCOL TEAM … · Ability to pause and resume ˜le transfers at the user's request. ... Aamir Allaqaband, Gustavo Catalano, Matthew Broadstone, Thomas

Future Upgrades

Ability to request and process remote �le and directory listings. A GUI that resembles �le transfer applications, showing both the local

and remote �le structure. Ability to pause and resume �le transfers at the user's request. Filter recipients to prevent �le transfers.

HIGH SPEED IMAGE TRANSFER PROTOCOL

Background

Research

Distributed Ground Stations recieve

imagery from a variety of sources and must

distribute it across the Distributed Common

Ground System.The Existing methods for

�le transfer and replication are too slow

to meet current demands. Goodrich wants

a new protocol with better performanceRequirements

Testing

Results

Design

Server Design Client Design

across network links between Distributed

Ground Stations. A new prototype of a

mangement tool that utilizes this protocol

is also desired by Goodrich. Developing

a solution was the project focus.

FTP 0msFTP 100ms

FTP 200msFTP 300ms

Tsunami 0msTsunami 100ms

Tsunami 200msTsunami 300ms

UDT 0msUDT 100ms

UDT 200msUDT 300ms

UFTP 0msUFTP 100ms

UFTP 200 msUFTP 300 ms

0

100

200

300

400

500

600

00.1

15

10

TEAM SKYNETAamir Allaqaband, Gustavo Catalano, Matthew Broadstone, Thomas J. Owens, Professor Michael Lutz (Faculty Coach)

• Server Design implemented in C++

• Utilizes multiple reciever threads

• Design configurable by an INI file

• Unlimited incoming connections

• Uni-directional-only recieves data

• Client is implemented using Java

• Uses Barchart-UDT JNI wrapper

• Client is configurable by an XML file

• Multiple sender threads in a pool

• Client utilizes preallocated buffers

3 Dell Optiplex GX620 desktops

1 Keyboard and 1 Mouse

FreeBSD 8.1

LCD Monitor

KVM Switch

RDyne Labs 10/100/1000 Ethernet

InitialReview

IndividualResearch

Presentationto Group

Testing

UDT

Tsunami UDP

UFTP

BitTorrent

The �le transfer protocol must be able to reliably

transfer �les between nodes, without errors. The

performance must, under some network conditions,

outperform the existing solutions currently deployed.

System has no speci�c hardware or operating system.

Process

0

10

20

30

40

50

60

Accepted

Delivered

Rejected

Finished

Started

Unstarted

Iterations were one week long, with the software in a

usable state at the end of each iteration. Velocity for

each iteration was tracked and used to plan workloads

for the next iterations. Steady integration ensured that

working builds at all times and products were available

as needed. Weekly meetings were held to update Goodrich on our status and plan our next iteration.

Senior Project 2010-2011

Although FTP performed well on clean

networks, its performance degraded

signi�cantly whenever the network

experienced latency and packet loss.

UDP takes longer to achieve max

throughput, but is able to maintain

a greater throughput through extreme

packet losses and latencies.