Objective:  The purpose of this exercise is to collect data to evaluate the suitability of the TeamTrak point protocol and message protocol for file transfer applications.   As we discussed in class and have seen firsthand in the last exercise, mobile ad hoc networks are inherently unreliable using the existing architecture and protocols.   We would like to know whether a "reliable" network application can be built on top of TeamTrak and, if not, what would need to be modified or redesigned to do so.   File transfer is a good test application because it's conceptually simple but quite challenging to get right in this environment since every packet needs to arrive at its destination and packets need to be reassembled in order.   Of course, UDP transmissions give us no guarantees of either. In this exercise, we will attempt to transfer a file to all connected nodes using a very simple prototype file transfer mechanism.

Task:  Form a small ad hoc network in different configurations and run the experiment already built in to the specially modified version of TeamTrak available here.   We will use this version of the application for this exercise only.   Also, make sure you have downloaded a copy of the campus map (the file ttplaces.txt).

1. Can a reasonably reliable file transfer work over a highly dynamic and unreliable network?   For a small file consisting of only a small number of packets, what is the observed rate of packet loss?   On average, how many retries are needed and how many transfers time out altogether?
2. How does the topology of the network affect packet loss rates?   What effects do choke points have on the number of retries and the number of failures?
3. Are end-to-end packet acknowledgements appropriate for this environment?

Test Procedure:   The class will split into two groups. One group will go outside east of DeBartolo and form a single file chain of TeamTrak nodes (similar to the bucket brigade we did on the last exercise, but there's no need to try to stretch it as far as possible).   The other group will go to the far end of the quad west of DeBartolo (that should be sufficiently apart not to interfere).   Each group will do the following:

1. All participants will clear their history files and routing tables prior to test execution.
2. Obtain a GPS fix (that will help me recreate the topology when I go through the logs).
3. One person (either at the end of the chain if in the first group, or a designated participant if in the second) will run the exercise by selecting the File menu then Run Experiment.   The debug screen will show the current destination and status of each transfer.
4. Once that completes, everyone in the group will run the experiment at the same time.

What happens during the experiment is each node will attempt to transfer the file ttplaces.txt to every node in the routing table with the exception of stale entries.   The protocol is similar to that of Trivial FTP, in which one packet at a time is transmitted and the next is not sent until the previous one is acknowledged.   In this particular implementation, packets can be retransmitted after a timeout period, and the transfer fails after a designated number of unsuccessful retries for any one packet.   Once all packets have been sent to all nodes and either acknowledged or timed out, the experiment concludes.

Please Note:   In this exercise we will be mainly collecting data for later analysis and discussion.   We will probably not see anything significant or even determine if the test was a success or failure right away, as the real story is captured in the logs.   I will present the results of this experiment some time after spring break.

What To Turn In:   To receive credit for this exercise, place the file ttlog.txt in the course dropbox no later than the start of class on Friday, 9 March.