Assignment Overview

You'll write code to measure client-server throughput, latency, and error rate using both UDP and TCP. There are a number of goals for this activity:

• To gain some programming experience using raw sockets for communication, on both the client and server sides.

• To get some sense of TCP and UDP throughput, latency, and error rates.

• To gain some appreciation of the tradeoff between performance and reliability.

• To gain some appreciation of the need for message framing.

• To verify that you're set up to work on the projects.

A major goal of this assignment is to verify that you have set up the infrastructure required to do future projects. This includes forming a team, figuring out what platform you will work on, and making sure you can deal with Eclipse and its Android plugins. Experience says that this usually goes smoothly, but you should make sure you can build the project in Eclipse as soon as possible, as resolving difficulties with that can take some time.

The ping and dataxfer Applications

ping

ping is a program that measures the time required for a client to contact a server and receive a reply. Ideally, the ping client sends a length 0 message to the server, and upon receiving it the server responds with a length 0 message. The client measures the time from the send to the receive.

We'd like to measure client-server latencies for both UDP and TCP. The software distribution includes implementations of echo clients and server. The echo client send data to the server, which simply sends it back to the client. Both the echo server and the console (desktop) client support both UDP and TCP; the Android client supports only UDP.

You should create a ping console client by modifying the console echo client to introduce taking timings. You can use the unmodified echo server as the pingserver. There is no need to create an Android ping client for this assignment; we'll get to Android in Project 2.

UDP and TCP
Under both UDP and TCP the client should send a short (few byte) string to the echo server to cause it to respond to you. The time interval you should measure is from immediately before creating the client socket that will be used (your should create a new socket each trial) until just after you have received the response from the echo server. Your TCP implementation should be careful to close the TCP socket when done with it.

Note: There is a "real" ping application available on your system. You can use it to get some idea if the your implementation's timings are plausible, but you must implement your own version of ping using Java and the project infrastructure.

dataxfer measures the server to client data transfer and error rates. You should write both the server and a console client for this application, supporting both UDP and TCP data transfers. (There is no need to create an Android client.) Your code should run repeated trials of the transfer, and report mean results.

A data transfer error is a failure to correctly receive all of the expected data. We simply count the number of bytes received, and assume the results are correct if we get them all and incorrect otherwise. (That leaves out the question of ordering, which we address extensively in class but not in this project.) The error rate is simply the fraction of trials for which there was an error.

If there is no error, we define the transfer rate to the be the amount of data transferred divided by the transfer time. The transfer time includes the time to create the socket. It is the time from just before creation of the socket until the final byte of data arrives.

To see if transfer rate depends on the total amount of data sent, the server offers a few transfer sizes. In particular, for both UDP and TCP, the server allocates four consecutively numbered UDP ports (e.g., 22000, 22001, 22002, and 22003). It returns 1000 bytes of data on the lowest numbered port, and a factor of 10 more bytes on each successively higher numbered one. (So it returns 1,000,000 bytes on the highest numbered port.)

UDP
The client sends a packet with 0 data bytes to the server. The server responds by sending back a fixed amount of data as fast as it can. The server should send back no more than 1000 data bytes in a single packet.

TCP
The client creates a socket and connects it to the server's socket. When the server receives the connection, it immediately starts sending its data as fast as it can. Similarly, the client immediately begins reading from the socket when the connection is established. Both sides close their socket when they are done with it.

The server uses the same four port numbers for TCP sockets that it used for UDP sockets, and transfers the same amount of data on each as in the UDP case. There is no port number conflict because the sockets support different protocols.

Implementation note: Your implementation should be capable of transferring any amount of data, and in particular amounts far larger than the size of main memory. That means the overall transfer must be structured as possibly repeated transfers of fixed size blocks of data, and that a single block must fit comfortably in memory. Very small blocks will result in very slow transfer times, because of per-block overheads.

What Do I Do?

Finish the implementation of the following:

Source File	Interface File	Eclipse Project
PingRaw.java	PingInterface.java	ConsoleApps
DataXferRaw.java	DataXferInterface.java	ConsoleApps
DataXferRawService	None	Net (edu.uw.cs.cse461.Net.Base)

The Interface File column indicates what promises are made specifically by this class. The classes need to conform to existing interfaces to operate within the infrastructure. That is clear from the code, though.

Running Your Code

To run, you need a client and a server. We are providing a fully functional implementation of the projects. You can use it as a server while debugging the client, and as a client while debugging the server. The behavior of the solution can be controlled by the configuration file you point it at - see the Project 1 Source page.

Your client and server should also work with each other, and with implementations by other teams.

What to Turn In

Turn-in is online. We'd like a single file containing the items listed next. The file should be in .tar.gz, .zip, or .jar format. The file name should list the UWNetID's of the members of your team, following the format of this example name: emmett15_mwinst_zahorjan.tar.gz. (Substitute .zip or .jar for .tar.gz if you use either of those formats.)

You should include in that file:

1. Your modified PingRaw.java, DataXferRaw.java, and DataXferRawService.java source files, and possibly a README.txt file.
   We will insert your source into a test harness (the solution code, essentially) and run it. For that to work, you should not have done anything unexpected, like changing class or package names, or introducing new source files. If you have done something unexpected, and can't undo it before turn-in, add a README.txt file that explains what you've done and what we're going to need to do to build our solution code with your code injected into it.

   If your code isn't fully working, please characterize what doesn't work in file README.txt.

2. An answers.txt or answers.pdf file that answers the following:
   1. What does your UDP ping code measure, and why do we need more than one measurement?
      Briefly explain how your UDP ping measurement works in the common case, where the client's packet is delivered to the server promptly, the server responds by sending a response packet promptly, and the response packet is delivered promptly. What is it your code actually measures? (It's unlikely it's exactly "network latency," for instance.) Why might the measured time change from one trial to another? (Why do you need to run multiple trials?)

   2. Why might the UDP ping client time out?
      Suppose your UDP ping client experiences a timeout while waiting for a response. List all distinct possible causes of the timeout.

   3. What is an appropriate response to a timeout?
      Suppose your ping client is asked to make 100 trials UDP pings. The client code experiences a timeout on trial number 5, and no other timeouts.
      1. There's an argument that when the timeout occurs, the client code should give up, not perform the remaining 95 trials, and return "I don't know" as the estimated ping time. What is that argument?
      2. There's also an argument that the code should go ahead and perform the remaining 95 trials, returning the average of the 99 successful trials and an indication that one trial failed. (This response is interpreted as "When the ping is successful, the average latency is xx msec., but it's successful only Y% of the time," which isn't quite the original goal but is still something worth knowing.) Briefly explain that argument.
      3. There's no argument that you should just keep running trials until you have 100 completed without timeout, and then simply return the mean of those 100 trials. Briefly explain why not.
      4. Very briefly, what does your UDP ping code implementation do when a timeout occurs? (This is just a question of what you actually do. You don't have to have done "the best imaginable thing." In fact, the project discourages you from trying to do the best imaginable thing because it's much too complicated for this project.)

Setup Details

There are two primary issues to setup: the general one of getting your build/test environment set up, and the specific code base used in this project.

1. Setting up Eclipse + Android
2. Setting up The Project 1 Projects

Project 1 Software: Modifications and Execution

You have to make some modest changes and additions to the distributed software. A separate page describes the software architecture, and how to run the software.

1. The Project 1 Source

Downloads

The "downloads" are actually files in the CSE file system that you copy to your platform (not web downloads).

1. The skeleton code is located at /cse/courses/cse461/12au/461projects.jar. Un-jar it to produce an Eclipse workspace. (You'll need to follow the directions above to establish your build environment before the projects in the workspace will build without problems.)

2. The solution files are located in directory /cse/courses/cse461/12au/461solution/. Copy that entire directory to your machine. The directory contains the solution code (461solution.jar), a sample configuration file (default.config.ini) and many native code libraries required by sqlite (which is used in a later project).

   To run the solution, first look at and perhaps modify the configuration file. (For instance, the configuration file names attu2 as the server for almost all applications. You can change that, or simply delete those entries - most applications will ask if they don't find a configuration file entry.) Then, while in the directory with the 461solution.jar file, say

   $ java -jar 461solution.jar -d .