Amateur Radio Satellite File Transfer Protocol (ARSFTP)

Amateur Radio Satellite File Transfer

Protocol (ARSFTP)

Author:

Andrew Morrison

Advisor:

Dr. John Bellardo

SENIOR PROJECT

California Polytechnic State University

San Luis Obispo

ELECTRICAL ENGINEERING DEPARTMENT

June 2012

Abstract

During the course of a CubeSat’s mission, a large amount of information is collected. It

is necessary for this data to be transferred to ground stations over links characterized

by low data rates, high packet corruption and drop rate, and high latency. Current

ﬁle transfer protocols cannot handle these characteristics well, and delay the transfer of

the ﬁle longer than acceptable. A new ﬁle transfer protocol, Amateur Radio Satellite

File Transfer Protocol (ARSFTP), is designed speciﬁcally to transfer ﬁles across links

mentioned previously and seeks to transfer data faster and more eﬃciently than current

ﬁle transfer implementations.

ARSFTP was tested using a Linux utility to simulate network environments and show

their eﬀects on data transfer time. Using this, it was possible to determine whether or

not ARSFTP would be suitable for satellite deployment.

Acknowledgements

Firstly, I would like to thank my advisor, Dr. John Bellardo, for oﬀering his continual

support and guidance for the duration of the project, as well as amazing amounts of

patience.

I would also like to thank my fellow lab mates in PolySat for their good spirits, company,

and help along the way.

Contents

Abstract i

Acknowledgements ii

List of Figures v

List of Tables vi

1 Introduction 1

1.1 CubeSats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 File Transfer Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Requirements and Speciﬁcations 3

2.1 Speciﬁcations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1.1 Speciﬁcation Considerations . . . . . . . . . . . . . . . . . . . . . . 3

2.1.2 Resulting Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5

3 Design and Implementation 6

3.1 System Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.2 GET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.3 PUT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.4 RM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.5 LS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.6 QUEUE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.7 REPORT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4 Data and Analysis 15

4.1 Transfer Times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.1.1 Window Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.1.2 File Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.1.3 Drop Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

5 Conclusions 20

5.1 Possible Design Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

5.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

iii

Contents iv

A ABET Senior Project Analysis 23

Bibliography 26

List of Figures

3.1 Level 1 Block Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.2 Client GET Flowchart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.3 Server GET Flowchart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

4.1 Window Size Eﬀects on Transfer Time . . . . . . . . . . . . . . . . . . . . 16

4.2 File Size Eﬀects on Transfer Time . . . . . . . . . . . . . . . . . . . . . . 17

4.3 Drop Rate Eﬀects on Transfer Time (50KB) . . . . . . . . . . . . . . . . . 18

4.4 Drop Rate Eﬀects on Transfer Time (250KB) . . . . . . . . . . . . . . . . 19

List of Tables

2.1 Requirements and Speciﬁcations . . . . . . . . . . . . . . . . . . . . . . . 5

3.1 Level 1 Decomposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

A.1 Estimated Costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Chapter 1

Introduction

1.1 CubeSats

CubeSats are nanosatellites, measuring 10cmx10cmx10cm (for a “1-U” CubeSat) and

weighing at most 1.33kg. They are widely used in universities, but have more recently

been adopted by government organizations and commercial entities. Their use as a

platform for payloads is due to their low cost compared to larger satellites with similar

capabilites. Many CubeSats communicate data across links with various characteristics

detrimental to successful communication. This includes, but is not limited to, low data

rates (typically sub-9600 bits per second), high packet corruption and drop rate (depen-

dent on distance between transmitter and receiver), and high latency (also dependent on

distance). In order to eﬀectively communicate between a ground station and satellite,

a more delay-tolerant transfer protocol is necessary. This protocol should transfer large

ﬁles faster than existing ﬁle transfer protocols under conditions described. ARSFTP is

developed for use on CubeSats running a Linux-based operating system with a UDP/IP

stack. Previously, CubeSats were developed on systems that were not capable of run-

ning Linux with a UDP/IP stack, but recently advancements in technology have allowed

for more storage space for ﬂight units, resulting in the allowance for more complicated

systems such as Linux.

Chapter 1. Introduction 2

1.2 File Transfer Protocols

A ﬁle transfer system allows for the basic transferring of ﬁles over a network. Proto-

cols such as ARSFTP are built on a server-client model, where a client establishes a

connection with a server, which then completes the client’s request (most often GET or

PUT). There are a multitude of existing protocols for transferring data, but most are

not designed for poor connections and bad links. Many implementations (such as the

default FTP program) are built on TCP, however TCP’s congestion control algorithm is

not adequate for the link problems; as packets are not acknowledged in adequate time,

TCP waits an exponentially increasing amount of time before re-transmitting the packet.

There do exist ﬁle transfer protocols built on UDP, but these still make assumptions on

link connections and/or have more overhead than space communications can handle.

Two main methods of transferring data within the protocol are ﬁxed length/format

downlinks and block resolution downlinks. The former is useful when only certain in-

formation needs to be transmitted; the data is not dynamic and is always stored in the

same number of bytes. In this form of communication, overhead is greatly reduced and

throughput is increased. The latter is more useful for dynamic amounts and diﬀerent

types of data; i.e., ﬁles on a system. The amount of control over which block to send

at certain points in time, as well as the size of the blocks, allows the client to request

speciﬁc missing blocks of a ﬁle. This introduces much more overhead than ﬁxed-length

transmission, but is better for larger transfers.

Chapter 2

Requirements and Speciﬁcations

2.1 Speciﬁcations

2.1.1 Speciﬁcation Considerations

These speciﬁcations touch upon important FTP implementation requirements, as deﬁned

in the RFC speciﬁcation [6], as well as important engineering/programming practices.

They are presented with a fully functional ﬁle transfer program accounting for amateur

radio link characteristics in mind.

Firstly, it is important to approach the design of a program with good programming

practices. To minimize impact on the system, the program should utilize dynamic mem-

ory allocation. This allows the program to use the least amount of memory necessary.

Otherwise, the program may request more memory than it needs. While this may not

noticably impact performance, it still allows the program to grow and shrink only as

necessary, thereby being more eﬃcient. As with any dynamic program designed to be

running for long periods of time, ARSFTP must be implemented such that no memory

leaks are present. The longer a program runs, the more memory leaks aﬀect its perfor-

mance; as more memory is allocated without freeing any to the operating system, the

program begins to consume more resources than allowed (or than the operating system

can allocate), and it crashes. Constantly consuming too much resources and crashing are

not acceptable, as both cause excess strain on the hardware. As a result, the program

should be tested with memory leakage analyzers such as Valgrind in order to ensure

minimal impact on the operating system and ﬂight hardware.

Chapter 2. Req. and Spec. 4

In addition to the absence of memory leaks, the program should be designed such that

it should not wait at any one section of code. This is especially important for the server

side of the application, where it is possible that multiple requests are being made. If

the server stops accepting requests in order to wait for a packet (one that may never

arrive), no other clients may make necessary requests. This situation is detrimental to

handling mission-critical data, and so considerations should be made to ensure that the

program does not halt for any reason. Similarly, the code should be modular. Because

it is possible that any code may be re-used in another application, abstracted code

allows for portability of the system while minimizing need to re-write code. Additionally,

modularity allows for easier bug ﬁxes – any issues may be isolated and ﬁxed with minimal

impact on the rest of the system.

At its core, a ﬁle transfer protocol should provide enough functionality to transfer a

ﬁle onto a server as well as retrieve a ﬁle from a server. Especially with space com-

munication, the transfer should complete quickly enough so enough transactions may

be completed in an alloted time. The amateur radio links used in communication with

CubeSats impose constraints on data rate as well as how quickly a packet may be de-

termined to time out. The latter concern leads to problems in current ﬁle transfer

protocols, which contain assumptions on the rount-trip time (RTT) of packets that are

too low for space communication. Because of this, ARSFTP should allow for these much

longer RTT without wrongfully assuming dropped packets, since doing so would waste

available transfer time and lower overall link utilization through needless retransmission.

Similarly, ARSFTP should complete transfers in noticably less time than FTP after the

introduction of packet loss. This time varies by the length of ﬁle, chosen size of indi-

vidual packets, and data rate of line, but the time diﬀerence should increase as ﬁle size

increases.

Since it is likely over the course of a mission to require more from a FTP server than a

simple transfer of ﬁles, more capabilities need to be introduced. For instance, it is useful

to ﬁnd a current listing of the contents of speciﬁc directories in order to locate speciﬁc

ﬁles. To accomodate to this want, directory listing functionality should be implemented.

This should be done eﬃciently so that the directory listing does not consume all of the

available bandwidth. Additionaly, if an unwanted ﬁle were to be accidentally placed

on a server, or a ﬁle existed that was too large and needed to be removed, it would be

useful to remotely issue one command to remove the ﬁle and, as such, ﬁle removal should

be implemented. Lastly, it is important to group ﬁles into categories and download a

Chapter 2. Req. and Spec. 5

speciﬁed category, or to prioritize ﬁles within categories. This leads to the need to

implement the functionality to retrieve statistics of ﬁles within such groups, as well as

downlink these ﬁles in order of priority.

These considerations are summarized in Table 2.1.

2.1.2 Resulting Requirements

Table 2.1: ARSFTP Requirements and Speciﬁcations

Marketing

Requirements

Engineering

Speciﬁcations

Justiﬁcation

1, 2 1. No memory leaks Running out of memory causes the

system to crash.

1, 6 2. Program should not hang

on any one section of code

Maximizes throughput when multiple

packets arrive close together.

3, 5 3. Code should be modular Easier to debug; portable to other ap-

plications.

1, 2, 3 4. Dynamic memory usage Minimize footprint of system; low

overhead of program.

4, 6 5. Correctly lists, deletes, or

retrieves ﬁles from a satellite

Necessary to retrieve data and moni-

tor ﬁles on the remote satellite.

4, 6 6. Correctly transfers ﬁles to

a satellite

Necessary to store information

needed in data collection.

4, 6 7. Correctly implements pri-

ority queueing behavior when

requested

Necessary for retrieving important in-

formation and grouping ﬁles in a

meaningful manner.

1, 2, 4, 6 8. Should transfer a ﬁle faster

than FTP under higher packet

loss conditions

Important to retrieve data under

satellite visibility window and to have

the highest link utilization possible.

2, 4 9. System should not erro-

neously assume dropped pack-

ets due to increased RTT

Since increased orbit distance results

in increased RTT, the system should

support longer RTT on packets in or-

der to not assume a dropped packet

when it is not the case; results in a

higher link utilization.

Marketing Requirements

1. Eﬃcient

2. Stable

3. Flexible

4. Ability to store, retrieve, delete, queue ﬁles

5. Low maintenance

6. High throughput

Chapter 3

Design and Implementation

3.1 System Overview

The ﬁrst consideration for ARSFTP is the basic implementation of the protocol; which

transport layer protocol to use, and whether to use ﬁxed format downlinks for block reso-

lution downlinks as a method of transferring data. Since, as discussed previously, TCP is

not acceptable for the link characteristics, UDP was the next choice as a well-established

datagram protocol. No other protocols were considered due to UDP’s lightweight data-

gram transfer. Since UDP has no reliable data transfer, but it is still important to

receive the entire ﬁle, acknowledgement (ACK) packets were implemented to ensure re-

liable delivery (however, unlike TCP, no backoﬀ is implemented). Due to the possible

variable length of packets being sent for diﬀerent commands, block resolution downlink

was chosen and implemented as a window protocol. This allows for a faster transmission

with the choice of a correct block and window size for a given link. Finally, ARSFTP

is designed on a server-client model, with the server on a CubeSat and client program

used on a ground station. This basic level 1 block diagram interaction is presented in

Figure 3.1. Individual components are explained in Table 3.1.

The Requirements and Speciﬁcations section leads to speciﬁc commands that should be

implemented: transferring a ﬁle from and to a server (PUT and GET, respectively);

removing a ﬁle on a server (RM); listing the contents of a directory (LS); adding a

ﬁle to a priority queue (QUEUE); reporting one or multiple priority queue contents

(REPORT). The details of the design decisions of each component are presented in the

following sections.

Chapter 3. Design and Implementation 7

Figure 3.1: ARSFTP Level 1 Block/Flow Diagram.

Table 3.1: ARSFTP Level 1 Block Diagram Decomposition

Item Functionality

Keyboard Input User input from keyboard to client. Describes which func-

tion should execute as well as deﬁning additional parame-

ters.

(Optional) Input Files User designates which ﬁles, if any, should transmit to the

server.

Client Program running on a local machine (generally a ground

station). Communicates with the server to execute func-

tionality the user wants.

Command Part of message from client to server describing which task

the server should execute.

Queue Report Priority queue listing information (described more thor-

oughly under QUEUE and REPORT).

Directory Listing Information regarding a speciﬁc directory the user deﬁned

(described more thoroughly under LS).

Files Files that are either sent to the server or received from the

server.

Server Program running on a remote machine (in this case a Cube-

Sat) that response to commands sent from client.

3.2 GET

3.2.1 Client

The client begins by sending its initial request to the server containing the GET com-

mand and destination ﬁle name it wishes to receive. The client then enters a loop waiting

for data or until it times out by not receiving data for a conﬁgurable amount of time.

After timing out, it re-sends its request containing the vector of ACKs. After sending

a conﬁgurable number of requests, the client assumes communication has been dropped

and removes the the local ﬁle. If the client loses connection with the server mid-transfer,

Chapter 3. Design and Implementation 8

a state ﬁle is kept so that the transfer may resume and missing blocks of the ﬁle may

be transferred. This allows a ﬁle that may be too large to downlink in a single pass to

transfer over multiple passes, allowing complete transfer of large ﬁles such as picture or

video. The basic GET procedure for the client is summarized in Figure 3.2.

Figure 3.2: Client GET Flowchart.

3.2.2 Server

The server utilizes functions from the PolySat library in order to allocate time to diﬀerent

clients; the client address is registered with the server and the server passively waits in an

event loop for any client to send it data that it will process before sending more data back

to the client. The event loop was chosen over other forms of parallel programming due to

UDP being a connectionless protocol, as well as the lowest amount of overhead in event-

driven programming as opposed to threads (which would spawn too many processes to

manage). This process of registering a client with the server and the basic event loop is

consistent across all functions.

After registering with a client, the server veriﬁes that the ﬁle exists – if it does not, it

responds with a failure. If it can, it sends metadata of the ﬁle back to the client, and

Chapter 3. Design and Implementation 9

then waits until the client responds before sending windows of the ﬁle. As the client

ACKs vectors that it receives, the server tracks which blocks have been received and

slides the window if enough blocks have been ACKed. Otherwise, the server will send

the missing blocks until the client receives all of the blocks in a vector. A simpliﬁed

version of this ﬂow is shown in Figure 3.3, and is also used in PUT, LS, and REPORT,

as described in their respective sections.

Figure 3.3: Server GET Flowchart.

3.3 PUT

3.3.1 Client

To initiate the PUT request, the client sends the PUT request containing the remote ﬁle

name to be created. If this is acknowledged with a successful packet, the client initiates

transmission of the ﬁle. ARSFTP is written in a modular way such that functions are

able to be used in multiple subsystems. This is especially the case with GET and PUT.

The client side of PUT functions similarly to the server side of GET; the client sends

windows of missing blocks and waits for enough continual blocks to be ACKed, and

resends windows as necessary. It utilizes the same timeout mechanism from GET to

Chapter 3. Design and Implementation 10

determine if it needs to resend a window. This ﬂow is similar to Figure 3.3, but includes

a timeout mechanism for re-sending the window as mentioned above.

3.3.2 Server

Similar to the client, the server utilizes code that the client uses for GET, but still only

passively receives portions of the ﬁle so it does not hang waiting for more blocks. At the

beginning of the transaction, if it cannot create the ﬁle (e.g., because it does not have

permission to) it sends a failure packet so the client does not waste link time sending

blocks. The server does not re-send ACKs if no more data is received, but instead waits

for the client to ”time out” and re-send the window. The ﬂow is similar to Figure 3.2,

but does not include the timeout mechanism of the client, because doing so would cause

a block in the program, which does not comply to the system requirements.

3.4 RM

3.4.1 Client

RM is the simplest function of ARSFTP for both the server and client. The client only

sends a RM request packet with the name of the remote ﬁle name to delete. Whether

or not this is a successful removal does not change what the client does, since it is

doubtful if the removal was successful that a re-transmission would solve the problem.

No authentication is added to the RM request; the reason and consequences of this are

discussed in the following section.

3.4.2 Server

Once the server receives an RM request, it attemps to remove the ﬁle denoted by the ﬁle

name ﬁeld. This is in no way a secure transaction, and as a result is not the best decision

for mission critical ﬁles. However, adding authentication introduces high amounts of

overhead, which might not be the best in a limited transmission time situation. In the

future, some form of authentication should be added so that the server does not accept

RM requests from anybody, who might mailciously attempt to remove important ﬁles

from the CubeSat.

Chapter 3. Design and Implementation 11

3.5 LS

3.5.1 Client

The client begins the LS request by requesting a remote directory to ﬁnd the contents

of. To reduce overhead and to reduce the number of requests made by the client,

recursive and hidden ﬂags are implemented to view subdirectories as well as hidden ﬁles,

if necessary. A major concern of transmitting this data is amount of data transferred due

to the amount of ﬁles or subdirectories located on the server. To accomplish lowering

the amount of data transferred (to reduce the amount of time necessary to receive

this information), the directory listing results are compressed into a ﬁle, which is then

transferred to the client. To compress and decompress the data, the zlib compression

library is used due to its eﬃciency in compression as well as documentation for its use.

The compressed ﬁle is received by the client in the same way that GET receives a ﬁle

(see above). Once received, it is decompressed by an additional program that outputs

the decompressed data to stdout. The decompression procedure is available on zlib’s

website. The idea behind this scheme was to allow a script to use the output to locate

ﬁles a ground station wishes to download, or to download an entire directory.

3.5.2 Server

The server receives the client’s LS request, and if it cannot access the directory, it

responds with an error packet. Otherwise, it creates a directory listing ﬁle, compressing

each ﬁle entry into the ﬁle as necessary. The method of creating a compressed ﬁle and

adding entries to be compressed is available on zlib’s website. The location of the created

directory listing is in /tmp, so that the additional ﬁles do not clutter the directory the

server is running in and are easily pruned from the system. If the recursive ﬂag is set, LS

will recursively enter each directory, adding the statistics for each of those ﬁles; likewise,

if the hidden ﬂag is set, LS includes all ”hidden” ﬁles it ﬁnds. After the compressed

ﬁle is completely ﬁnished, it sends the ﬁle’s metadata to the client and the rest of the

transaction uses the GET functions to transfer the ﬁle. The re-use of code allows for any

further optimizations in transferring ﬁles to also be applied to LS, thereby increasing

eﬃciency and conforming to the requirements.

Chapter 3. Design and Implementation 12

3.6 QUEUE

3.6.1 Client

The QUEUE command is diﬀerent from other commands in that the client is not located

on a ground station; it is instead located on the CubeSat and used by other processes to

add ﬁles to the appropriate priority queue. QUEUE uses IPC (and on a diﬀerent port

than other ARSFTP connections) to request that a ﬁle be added to to a speciﬁed queue

and priority. Each queue corresponds to a diﬀerent system and diﬀerent processes use

diﬀerent queues to add their data. For example, sensor data may add its information to

one queue, while satellite health may add its ﬁle to a diﬀerent queue. After some time,

the health system decides that it has information that is critical information (some part

of the satellite crashed, for instance) that needs to be downlinked ﬁrst, so it inserts the

data at highest priority. This may be a problem if the application constantly attempts to

add ﬁles at highest priority, but it is the application developer’s responsibility to ensure

this does not aﬀect its intended operation. There is an optional remove argument that

allows an application to remove a ﬁle speciﬁed by name and group.

3.6.2 Server

When a process wishes to add a ﬁle to the priority queues, the server receives the

QUEUE request and attempts to insert it into the corresponding queue. If the ﬁle exists

in the queue currently, it is removed from the queue and replaced at the desired priority.

The insertion of the ﬁle into the queue is done in a common ﬁrst in ﬁrst out priority

queue fashion, where ﬁles of highest priority at the beginning of the queue, with equal

priority ﬁles being placed in chronological order (older insertions ﬁrst). If the queues

become too full (i.e., the number of ﬁles in a queue surpasses a conﬁgurable maximum

per queue or the sum of the sizes of the ﬁles surpasses a conﬁgurable maximum), ﬁles are

dropped in order of lowest priority. The server does not send conﬁrmation that the ﬁle

was successfully added to the queue, since the only reason the ﬁle does not successfully

enter the queue is the case that it is too full and the ﬁle is too low of a priority, or the

ﬁle statistics are unobtainable.

Since this queue data is vital for the ground station to retrieve groups of data, the

queue data must be persistent. If the software or ARSFTP program must reboot, it

is important that there be some method to recover the current items in the queue and

Chapter 3. Design and Implementation 13

maintain the ability to report to the ground station ﬁles that were previously in the

queue. The three main methods of persistence ﬁles that were considered were: SQL

database, compressed ﬁle, and plain text ﬁle. The ﬁrst method, using an SQL database,

was discarded in interest of time and SQL’s heavy I/O, which may be a much larger

performance impact on the CubeSat than is necessary for the queue persistence (since

it is not likely that there will be enough ﬁles in the queues to warrant a database.

The second method, zlib compressed ﬁle, is promising until zlib’s memory utilization is

examined – if not closed properly, zlib allocates too much memory to the one process. In

a process (such as ARSFTP) that runs for extended periods of time, this is a potential

massive memory leak, which is not acceptable according to the requirements. When

the zlib compression stream is closed, it adds its end-of-stream delimeter, which is not

acceptable when the persistent ﬁle needs to be open and ﬁles need to be constantly

added.

To keep the queue data consistent, the plain text ﬁle method was chosen. When a new

ﬁle is added to any queue, its information (ﬁle name, group, priority, ﬂags) is added to

the queue ﬁle. This ﬁle does not need to be kept in any priority or group order, since

the initialization uses the functions used to insert a ﬁle into any queue; those functions

handle insertion of ﬁles in any order. The highest cost of using this persistence system

is in removing a ﬁle; to stay constantly persistent (with the least user interaction), it

was decided that the persistence ﬁle would be updated completely after each removal.

To accomplish this updating, the ﬁle is completely truncated and replaced with the

current queue data. Even though this is not the most eﬃcient method of updating the

ﬁle (for instance, it is ineﬃcient if the ﬁle to remove is the last of the ﬁle), it is simpler

and requires less I/O than using a temporary ﬁle to copy partial contents to eﬀectively

remove the ﬁle from the queue.

3.7 REPORT

3.7.1 Client

Reporting contents of a certain queue is important for ground station operations to

receive groups of ﬁles related to a current mission or system health information. The

client may request the contents of some (up to a conﬁgurable maximum) or all queues.

In addition, for each queue it wishes to downlink, the client may request a maximum

Chapter 3. Design and Implementation 14

size (in bytes) of ﬁles to have in the report. If no maximum ﬁle size is speciﬁed (i.e.,

”0” is the input for the maximum size argument), then the server assumes maximum

integer size (UINT32 MAX). If there is no argument for which queues to downlink, the

server assumes all queues and maximum integer size for each queue. To initiate the

REPORT request, the client stores the number of groups that exist in the request and,

if speciﬁc groups are requested, the request packet is of variable length containing each

group number and maximum ﬁle size for each queue. The report format is stored in

the same format as LS, with the same compression library. The results are stored in

numerical group order and ﬁles within groups in order of priority. This allows to the LS

and REPORT mechanisms to be easily maintained and ﬁxed as necessary. REPORT

uses the same program ﬂow as GET to receive the report ﬁle, and the same program

as LS to decompress and read the queue data. The goal of report is to use a script to

request speciﬁc queues and then use REPORT’s output to request each ﬁle in the queue

using GET.

3.7.2 Server

The server receives the queue request and creates a report ﬁle to store compressed

queue data. REPORT uses the same compression tools and functions as LS to create

the data ﬁle in /tmp. To determine which ﬁles to add to the data ﬁle, REPORT uses

the limits sent by the client to loop through the queues and add speciﬁed groups up to

the maximum total ﬁle size. If no limits are included in the request packet, REPORT

assumes all queues and UINT32 MAX as the maximum total ﬁle size, and compresses all

of them. After the compressed ﬁle is created, REPORT utilizes the GET functionality

to transmit data to the client.

Chapter 4

Data and Analysis

4.1 Transfer Times

The portion of ARSFTP with the most impact is GET functionality – other functions

make use of its transferring functions to send their respective data. This section is

concerned with the impacts of link variables on ARSFTP. tc was used to simulate link

characteristics; drop rate, link delay, and bandwidth. Unfortunately, the bandwidth

setting did not correctly limit the traﬃc to a constant 9600 baud (a typical rate for

satellite data communication). Instead, it allowed for a large burst of traﬃc before

restricting sending of any data at all, in order to ”simulate” 9600 baud. Because of this,

current FTP implementations were able to burst 2MB of traﬃc before being limited,

and are therefore not included as a comparison in this analysis.

Since other functions are dependent on GET, and any other computations and functions

server-side are minimal (¡ 1 second for even large amounts of ﬁles for LS), transfer

performance is the only characteristic analyzed.

4.1.1 Window Size

One of the major factors in transfer time is the window size. This determines the number

of blocks that are sent at a time. Too large of a window increases overhead above the

amount acceptable for satellite transfer. Too low of a window slows the transfer due

to increased waiting time on ACKs. Figure 4.1 depicts the eﬀects of window size on

transfer performance. This test is with 100ms latency, 10% drop rate, and a 100KB ﬁle.

Chapter 4. Data and Analysis 16

Figure 4.1: Eﬀects of window size on transfer time. (100KB ﬁle)

The impact of the window size is clearly seen when the window is very small (around 8

blocks). The transfer time is much greater than the other sizes due to increased process-

ing necessary. At 128 blocks per window, the transfer time due to larger window sizes

becomes negligible, and a window size of around 128 may be best in this environment

due to lower amounts of data on the line at once, as well as better for handling packet

drops.

4.1.2 File Size

This test was to determine if an increased ﬁle size impacted transfer time above the

expected linear increase. The expected trend is a linear transfer time increase with

respect to ﬁle size. This test is conducted with 100ms latency, 10% drop rate, and

window size of 256 blocks.

As expected, transfer time increases linearly with ﬁle size. With other factors remaining

constant, ﬁle size does not impact transfer time more than expected. In a normal 15-

20 minute transfer window, according to this test, a 250KB ﬁle may be transferred.

Chapter 4. Data and Analysis 17

Figure 4.2: Eﬀects of ﬁle size on transfer time.

This may be diﬀerent in practice, however, since the tc utility did not limit bandwidth

correctly, as mentioned in the introduction to this section.

4.1.3 Drop Rate

Drop rate should have a substantial impact on transfer time – at such a low data rate,

packet drops require re-transmission of data, therefore using more link time. At higher

drop rates, more re-transmissions are required, and the eﬀect of window size is more

substantial. This test shows the eﬀects of drop rate on two diﬀerent ﬁle sizes (50KB and

250KB), with 100ms latency, and window size of 256 blocks.

Chapter 4. Data and Analysis 18

Figure 4.3: Eﬀects of drop rate on transfer time. (50KB File)

With a 50KB ﬁle, transfer time increases with drop rate. The time increased by about

The data for the 250KB ﬁle is strange – there seems to be no correlation between drop

rate and transfer time. This may be due to the tc utility not implementing drops and

bandwidth in a certain order, therefore allowing packets to drop while not limiting that

bandwidth, and having a random eﬀect on the total transfer time, which is shown more

clearly when a larger ﬁle size is transferred.

Chapter 4. Data and Analysis 19

Figure 4.4: Eﬀects of drop rate on transfer time. (250KB File)

Chapter 5

Conclusions

5.1 Possible Design Changes

In any system design, there are trade-oﬀs necessary to allow for diﬀerent functionality,

ease of use, or eﬃciency. These decisions can greatly eﬀect the program ﬂow later in the

design, which might not result in the most eﬀective program.

If I were to begin the senior project anew, I would ﬁrstly make an eﬀort to fully un-

derstand the existing code before developing anything new. Not doing so resulted in

wasted time and code that did not conform to speciﬁcations (namely, in modularity). It

would also have allowed me to clean up any errors that previously existed without also

debugging my code.

As discussed in Chapter 3, the persistence of the priority queues was subject to a lot

of thought, but the result could have been better. For instance, the type of storage

ﬁle could be compressed so that it takes less space. Since space was deemed to not be

much of an issue, this was not a primary concern. The ﬁle itself should be updated at a

diﬀerent rate than it currently is, however. Since the ﬁle is updated every time a ﬁle is

removed from a queue (which also happens if a ﬁle’s priority is updated), the ﬁle causes

unnecessary churn on the storage device. This could be ﬁxed with an update ﬂag in

removal packets or timed updates.

Another major change I would have made was to allow all parameters to easily be

changed external to the program. Currently, most parameters (block and window size,

for instance) are only conﬁgurable through #deﬁne statements. It is possible that this

Chapter 5. Conclusions 21

may be changed eventually so that a user may easily change these parameters from a

ground station, but it currently is not.

5.2 Future Work

The Design Change section leads to some future work that could be implemented. Most

notably, future work may include parameter change without needing to re-boot the

server program. This faster change in parameters allows for more time to transfer data

and less time conﬁguring the server. Similarly, in the future it would beneﬁt users if

there were a more user-friendly interface to send requests. Since many users of the

program may not have strong backgrounds in computers, a more friendly interface than

command line arguments would be helpful.

More future work includes optimization of the priority queue past what exists currently;

mostly in the persistence of disk. This increases the eﬃciency of the queueing system

and consumes less resources on the CubeSat.

Another interesting improvement is adjusting transmission parameters automatically

to maximize eﬃciency. This would only be used on suﬃciently large ﬁles where this

matters, but the optimization could potentially increase amount of data transferred

greatly. The server would analyze how many blocks were dropped and adjust the window

size accordingly to not overload the link.

5.3 Conclusion

ARSFTP is able to handle latency and drop rate well. Unfortunately, the bandwidth

is not able to be tested, and that is a large component of whether or not ARSFTP is

better than current FTP implementations. Due to the bandwidth limiter not behaving

correctly, FTP is able to burst enough traﬃc to get relatively large ﬁles (anything less

than 2MB) before the traﬃc is throttled. Also, the bandwidth throttling had odd eﬀects

on transfers when packets are dropped (as shown with the 250KB ﬁle). If there is a ﬁle

that is too large to be transferred over one pass, ARSFTP makes it possible to resumee

ﬁle transfer on a future pass, allowing very large (e.g., picture) ﬁles to be transferred,

a necessary optimization for satellite transfer. Once a program to simulate satellite

Chapter 5. Conclusions 22

communication is ﬁxed and ready to use, ARSFTP may be tested more thoroughly to

determine its usefuleness in CubeSat ﬁle transfer.

Appendix A

ABET Senior Project Analysis

Project Title: Amateur Radio Satellite File Transfer Protocol

Students Name: Andrew Morrison

Students Signature:

Advisors Name: Dr. John Bellardo

Advisors Initials: Date:

1. Summary of Functional Requirements

The project provides an implementation of a ﬁle transfer system for cube satellites.

The program behaves as a normal implementation would; i.e., transferring, listing, and

receiving ﬁles.

2. Primary Constraints

The largest constraint in any software project is time. With increased complexity of

the project comes much more increased development time, both in planning and ﬁnding

errors in code. Also, since others develop programs on the same hardware, hardware

availability becomes another limiting factor that is, time becomes even more limited

due to sharing testing equipment and hardware. Another constraint includes the ability

to send and receive packets through the system at certain points during the day. At the

edges of visibility, packet drop rate increases greatly, and the ability to conduct testing

or data transfer decreases.

3. Economic

Appendix A. ABET Analysis 24

The economic impacts lie solely in the human capital invested during software devel-

opment. Afterwards, there will be more human capital involved with incorporating the

software into the other systems. There are no physical parts to purchase, but human

capital should cost $4800 (see table A.1). Since the project is for scientiﬁc pursuits, there

should be no proﬁts. The project should take no longer than 8 months to complete, and

may be maintained from the ground after satellite launch.

4. If manufactured on a commercial basis:

Commercial production of this senior project will not occur. Would production occur,

the main diﬃculty would be in incorporating the system into other satellites, and chang-

ing the code so that the ﬁle transfer system continues to operate smoothly on another

satellite.

5. Environmental

Since the project entirely resides in software, there are no direct environmental impacts;

there are no parts to acquire that would impact earths resources, and there are no

ecosystems that face destruction as a result of the software. However, the satellites

purpose may be one to help the environment (through data or other means), and in that

way this system will beneﬁt the environment.

6. Manufacturability

A lack of physical parts limits this products manufacturability. In terms of mass pro-

duction, copying ﬁles is not diﬃcult. The only possible issue would be distribution to

a customer (distribution via CDs or other means), and in the setup of the ﬁle transfer

system on a customers product.

7. Sustainability

Issues exist regarding maintaining and updating the system when communication to the

satellite is only possible during certain periods of a day. If the communication system is

updating and visibility is lost, there may not be a way to communicate with the satel-

lite thereafter. The project itself does not promote sustainable resource use, but other

portions of the overall satellite may be eﬃciently engineered in order to maximize sus-

tainability. Increasing throughput and packet success rate improves the system greatly.

Another possible improvement is including more commands that the system supports

as needed.

Appendix A. ABET Analysis 25

8. Ethical

Since the software exists on satellites and may transfer ﬁles for use within government,

it is important to consider security of the system. The system must be safe to prevent

data interception, as in doing so somebody may see information that is important to

the success of a mission. Without proper use, ﬁles may transmit that could compromise

the mission and/or the satellite. Since this is an important consideration, security of

the system should be strong.

9. Health and Safety

The main concern with the design and manufacturing of this device is carpal tunnel

while writing software. It will be important to take frequent breaks so as not to develop

the condition.

10. Social and Political

Since the project is related to space and for a private company, there are various proce-

dures that must be followed in order to conform to sets of rules necessary for operations

in space. The project impacts PolySat, as well as other agencies and companies associ-

ated with the mission. The stakeholders beneﬁt from being able to transfer necessary

ﬁles to and from the satellite system in order to analyze data. Failure or success di-

rectly reﬂects PolySat and customers, and the projects success impacts the availability

of future missions to be developed by PolySat.

11. Development

Multiple developmental tools were used in the development of this project. The network

analysis tool “tc” is useful in emulating network conditions, namely latency, packet

drop, and data rate. Valgrind was introduced to locate memory leaks and potential

segmentation faults. The articles researched and used can be found in the bibliography.

Table A.1: Estimated Costs

Item Cost Justiﬁcation

Labor $4800 ((4

hours

week

× 10weeks) + (10

hours

week

× 20weeks)) ×

$20

hour

Bibliography

[1] AXSEM, “Ax5042 data sheet and programming manual,” Axsem. [Online].

Available: http://www.axsem.com/

[2] B. Elbert, Introduction to Satellite Communication. Boston, MA: Artech House,

1999.

[3] C. Y. et al., “Evaluation of tcp and internet traﬃc via low earth orbit satellites,”

IEEE, 2001. [Online]. Available: http://www.ieee.org

[4] W. C. et al., “Design of a secure ftp system,” IEEE, 2010. [Online]. Available:

http://www.ieee.org

[5] C. L. Greg E., “Amateur radio satellite ﬁle transfer protocol,” California Polytechnic

State University, San Luis Obispo, Tech. Rep., 2011.

[6] B. Lathi and Z. Ding, Modern Digital and Analog Communication Systems. New

York, NY: Oxford University Press, 2009.

[7] J. Postel and J. Reynolds, “File transfer protocol (rfc 959),” 1985. [Online].

Available: http://www.ietf.org/rfc/

[8] R. Stevens, TCP/IP Illustrated, Volume 1: The Protocols. Addison-Wesley, 1994.

[9] Wikipedia, “Ftp (wikipedia).” [Online]. Available: http://en.wikipedia.org/wiki/

FTP