HIGH SPEED IMAGE TRANSFER PROTOCOL TEAM SKYNET · Ability to pause and resume ˜le transfers at the...
Transcript of HIGH SPEED IMAGE TRANSFER PROTOCOL TEAM SKYNET · Ability to pause and resume ˜le transfers at the...
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.