TCP Lightweight Agent
First Report
Abstract
For many reasons of optimization and protocol development, one may need information about the connection between a client and a server on the Internet. To gather this information, tests need to be run, and their output needs to be analyzed. In this project, we will implement an agent on a client and on a server, which will be a platform for test running. An application will run on the server, and the client will download and run an applet. We will also write some tests, which will be run by these agents. All tests will implement a common interface, so that more tests can be added by request. The results of the tests are returned as an interface and stored in a file, and can then be listed and viewed by a special application.
User Interface
The application on the server will receive the tests it has to run in a configuration file.
To run the client, the user will connect to the server where the application is listening on, and download the applet by downloading an html file.
All results will be written into an html file.
Modules and their Algorithm
1. Server Application: The server application is invoked and is listening on a special port. For each request the application receives from a new client, it creates a new thread to handle the tests, and an additional thread that announces timeout. The first thread goes over the tests and prepares the tests that need to be run by the client: it creates threads for some of the tests (if this is required), it sends to the client a list of these tests, and an additional list of parameters for the tests. After the client applet returned a list of results, the server kills the additional threads it created. At this point, the server has to run the remaining tests (those who need to be run by the server). To do that, the server sends the client a list of classes it has to create in different threads. The client’s reply is a list of ports on which those threads listen. This is used for server tests, which need a reply from the client. The server runs its tests and sends a termination message to the client applet. The last thing the thread on the server has to do is gather all results together and save them in an html file, including a time stamp and the relevant IP addresses. After that, the connection is closed and the thread is killed.
2. Client Applet: The client connects to the specific test server and downloads an html file on which the applet resides. On initialization, the applet creates a thread that does all the work:
public class Agent extends Applet
{
public void init();
{
//create a new thread which runs the tests as
// described above
}
public void start()
{
//empty
}
public void stop()
{
//empty
}
public void destroy()
{
//kill all threads, close all connections
// and exit.
}
}
3. Document View: all results are saved by the server application in a file, in html format, and so can be viewed in a browser.
Data Structures
There is an interface which all currently written tests, and tests designed in the future, must implement. This Interface consists of one method.
Interface TestInterface
{
public ResultType check(Object param);
}
For example:
class TestTroughput implements TestInterface
{
private void initialize(SomeClass sc)
{
//do some initializing
}
public ResultType check(Object param)
{
//call initialize, run a test and return the results
}
private int DoSomeMore()
{
//do something
}
}
interface ResultType
{
public String TestType();
public boolean Succeeded();
public String Results();
}
For example:
class ResultOfThroughput implements ResultType
{
double dThroughput;
boolean fSucceeded;
String strTestName; //initialized by the constructor
// to the test’s name
public String TestType()
{
return strTestName;
}
public boolean Succeeded();
{
return fSucceeded;
}
public String Results();
{
//formats the results into a string,
// which can then be shown in an html file.
}
public double GetThroughput()
{
return dThroughput;
}
package void SetThroughput(double dChecked)
{
dThroughput = dChecked;
}
}
Tests
The following tests will be implemented:
a. Ping – counts the roundtrip time of an echo message in IP level.
b. Router Tracing – returns the routers through which the connection to the client passes.
a. HTTP open – counts the time to open an http connection. All stages (name resolution, TCP connection opening…) will be counted separately.
b. HTTP download – counts the time for downloading an http page, including embedded files. This test will have an http 1.0 and an http 1.1.
c. TCP echo – opens a TCP connection other than http and counts the roundtrip time.
d. Throughput – this test will have two versions:
Time Table and Milestones
11/8 – First report review with Lior Horn
22/8 – End of “skeleton component” development and start of “test components” writing
25/8 – Meeting with Lior Horn
27/8 – Component testing
30/8 – Integration and debugging
6/9 – Project Presentation
9/9 – Final Report Submission
Teams
Client Team: Regev Smadar and Alon Golan
Server Team: Robert Parham and Eyal Keren