Using the clientRecorder class

 

Revision:  0  (Dec 6, 2005)

 

(1) Constructor

  

clientRecorder(String name, String Id)

 

The constructor is used to allocate your clientRecorder.

Name   is your student name

Id   s your Student Id (remember that the constructor asks for a String here)

 

Example:

 

ClientRecorder myRecorder = new clientRecorder("Conron", "123456789");

 

 

 

(2) Recording the result of a received packet

  

public void record(int type, int seq, int rtt)

 

After you receive a packet from the server and decide the status of the packet, record the packet status using your allocated clientRecorder.

 

type  is the symbolic name for the packet status (see the interface recorderParams.java)

 

seq is the sequential number of the sent packet.

 

rtt is the round trip time for this packet in milliseconds.

 

These are the symbolic names for packet status and when to use them;

 

OK        if this packet was received in the correct sequence and is not corrupt or a duplicate

DUPLICATE if this packet is a duplicate of one you have already received

REORDER   if this packet was received out of order

CORRUPT   if this packet has been modified in some way

DROPPED   if you timed out waiting for this packet

 

Example 1 (packet n is OK):

 

Let n represent the sequence numbers of the packets you sent to the server, where ALL sequence numbers begin at 1.  Suppose that packet n was received in the correct order, and that it is not corrupt, and not a duplicate.  Also suppose that you calculated the round trip time r for packet n.  Then record the results of packet n like this:

 

myRecorder(OK, n, r);

 

 

Example 2 (this packet is a duplicate of packet n):

 

Note that for a duplicate, we don't bother computing rtt, so specify 0 in you call to the clientRecorder:

 

myRecorder(DUPLICATE, n, 0);

 

 

Example 3 (this packet n has been received out of order):

 

Note that for an out of order packet we DO compute the round trip time r:

 

myRecorder(REORDER, n, r);

 

 

Example 4 (this packet has been modified (corrupt):

 

Note that for a corrupt packet we DON'T KNOW n, nor do we compute r, so we pass BOTH as 0

 

myRecorder(CORRUPT, 0, 0);

 

 

 

Example 5 (this packet n has been dropped):

 

Note that for a dropped packet we know n, but we DO NOT compute r, so we pass r as 0

 

myRecorder(DROPPED, n, 0);

 

 

 

(3) Closing the recorder

 

void close(int min, int max, int avg) throws IOException 

 

min is the smallest rtt value for all OK or REORDER packets that you have received.

 

max is the largest rtt value for all OK or REORDER packets that you have received.

 

avg is the average rtt of all OK or REORDER packets that you have received.

 

You MUST call the close() method after you have recorded a status for all of the packets that you have sent.  Calling close does two things:

 

(1) it records the final statistics for your test.

(2) it writes the clientRecorder log file, which you must submit with your project.  The file will be named <name>-<Id>.log where name and Id are derived from the constructor.

 

Example:

 

Suppose the variables you used to compute the minimum, maximum, and average round trip times are, respectively, minRTT, maxRTT, and avgRTT.

 

myRecorder.close(minRTT, maxRTT, avgRTT);

 

 

Understanding what "out of order" means

 

You must maintain some idea of sequence numbers that are assigned to each packet you send.  So, the first packet is number 1, the second is 2, and the nth is n.  An echoed packet P is out of order if you received the echo of P AFTER a receiving the echo of a packet that YOU sent AFTER  P.
 
It is not necessary that it's sequence number be exactly one greater than that of the previously received packet.  Here is an example sequence of packets that you may receive:

 

1          2          3          5          6          7          4          8          10 . . .

 

 

Here are some more examples of out of order packets.  Assume we sent packets 1, 2, 3, 4, and 5 (in that order), and we get back one of the following sequences:

 

 

 

How to handle corrupt packets

 

Do not try to determine the packet number of a corrupt packet!  You cannot trust the data in a corrupt packet.  All you can do is decide that the packet is corrupt, and then call the recorder to record the fact that you received a corrupt packet (see the example above).

 

Once you’ve decided that a packet is corrupt, and because you cannot determine WHICH packet this is, then you will eventually detect that some packet that you sent has not been returned before the maximum allowable time, so you will correctly record that packet as DROPPED.  This means that some of the packets that you think have been dropped were actually just corrupted.  THIS IS OK!

 

For example, suppose the sneaky UDPServer decides to corrupt your packet number 14. The server will send this corrupt packet back in the sequence where you might expect the 14th packet to be, but you SHOULD NOT DEPEND on that.  So, you will record the corrupt packet, then some time later you will time out waiting for the REAL 14th packet.  You SHOULD record that packet 14 has been dropped.