Internet and Intranet Protocols and Applications


Programming Project 3:  UDP Echo Client program


Revision  0 (Feb 25, 2002)     initial creation

Revision  1(Mar 05, 2002)     delete reference to Message class and Recorder class

Revision  2 (Mar 13, 2002)     delete requirement to submit log files



Write a program that sends UDP packets to an Echo server over an unreliable network.  Measure average round trip time (RTT), detect and recover from failures of the network and server.



An Echo server is a server that takes a message from a client and sends it back to the client.  This is what we mean by "Echo".   This "Echo" interaction can be used to determine an average round trip time between the client and the server (the round trip time is the total elapsed time from the point at which the message is sent by the client to the point at which the message is received back at the client).


Write a program that creates and sends a new message to the server at 500 millisecond intervals, verifies that each reply matches a request, and reports the round trip time (rtt) in milliseconds for each reply (without printing the message contents).  The program should handle situations when the network duplicates, loses, corrupts, or reorders either requests or responses.


Make the following assumptions:

·      The network duplicates and drops packets.

·      The network or server can corrupt the contents of a packet.

·      The network and the server can delay a packet significantly more than one second.

·      Packets can be received at the client out of order.



·      Read the message to send as a string input from the keyboard when you start (prompt user, read input)  The maximum message size will be 128 characters.

·      Send each request exactly 500 milliseconds after the previous request.

·      Measure the rtt for the first successful response, if any, to each request. Measure the rtt in milliseconds from before the request’s write until after the response’s read. Using the rtt for each successful reply, compute the average, maximum, and minimum rtt for the entire set of messages.

·      Report duplicated responses (and do not include them in rtt calculation).

·      Report out of order responses.

·      Report packets that you think are corrupt (and do not include them in rtt calculation).

·      Report dropped packets: Eventually the client needs to decide that a request will not receive a reply.  Define a delay constant MAXIMUM_DELAY equal to 5 seconds.  If a reply takes longer than MAXIMUM_DELAY, assume it was dropped.

·      NOTE: construct your program so that it runs efficiently when given a message count that is very large (for example, 1,000,000).  I will explain this in class.


With respect to termination:

·      1. take an argument that inputs the number of messages it should send.

·      2. If no number is entered, use a default count of 100 messages.



Note:  Since the network can drop or duplicate packets, you will need to decide when to "give up".  That is, decide that, based on MAXIMUM_DELAY, it is not possible to receive any more replies from the server.  You should terminate after this time (but don't terminate too early, because you may miss messages sent by the server!)


We will supply a recording class that you will use to record your results.  Each time you receive a reply (or time out on a reply) and determine it's disposition (correct, out of order, corrupt, duplicate, or dropped), you will call a method to record the result.  When the test is complete, you will call another method to report the statistics: rtt (min, max, mean), duplicate count, dropped count, out-of-order count, corrupt count).  Then you will call a close() method.


To make sure that there is no confusion between corrupt and dropped packets, we guarantee that any packet that is corrupted by the server will appear ONLY once (corrupted).  We also guarantee that if no packet is received after MAXIMUM_DELAY time, then it will not be sent at a later time, not even as a duplicate.  We expect you to exclude corrupt and duplicated packets from your calculations of rtt, but you MUST include them in your counting.


The Server tracks every message you send to it, and records what it does to the message.  We use this information to correlate the results in the Recorder log file.



You must write in the Java programming language.  You may run it on any machine you wish.  We will provide a UDP Echo server that duplicates, loses, or reorders either requests or responses.


Several different approaches can be used to concurrently send a new request at 500 millisecond intervals and make timing measurements

·      Sequential using asynchronous I/O

Use a non-blocking socket to write and read and keep track of the time since last send.

·      Concurrent with threads

One thread sends messages in a loop with a 500 millisecond second interval between sends. The other thread reads messages and measures round trip delay.

·      Concurrent with multiple threads or processes

A master thread creates a new thread every 500 milliseconds to handle each message.

Errors to Avoid


·      Deadlock.

·      Busy-wait or infinite memory use.

·      Misinterpreting a duplicate packet as an out of order packet.


Using the clientRecorder class.

BEFORE you send any messages to the server, you must construct an instance of the clientRecorder class.  A detailed description of how to use the clientRecorder class is



An example of the log files for client and server recorders is HERE.


NOTE - pay attention here!!

You MUST include the project3.jar file in your class path when you compile your client program AND when you execute it!



How to Test your Client Program


The project jar file (project3.jar) contains everything you need to build and test your program.


It contains the interface recorderParams.class.  It also contains the clientRecorder.class that you will use in your program.  The recorderParams.class file defines the constants that you will use when you invoke methods of the clientRecorder class.  For your convenience, the definitions in the recorderParams interface that you must use are given here:


  // following are used by clients, server, and recorders

  public static final int OK        = 1;

  public static final int DUPLICATE = 2;

  public static final int REORDER   = 3;

  public static final int CORRUPT   = 4;

  public static final int DROPPED   = 5;


Note: use the symbolic names for these parameters.  DO NOT USE the numeric values in your program.


We have supplied a server that you MUST use to test your program.  The server is a Java class named UDPServer.  To run the server, execute the program like this:


java -cp project3.jar UDPServer


The server will start and listen on UDP port 7 for packets.  If you have trouble using port 7 (you may if you are running on a Unix system), you can use the command line argument -port <port#>  where <port#> is any available port (numbers above 2000 are good).  So, to start the server on port 5555:


java -cp project3.jar UDPServer -port 5555


These examples assume that you are executing your command line from the same directory as the project3 jar file.


The UDPServer will terminate when it has gone 10 seconds without receiving another packet from you (but it waits forever for your first packet). When the server finishes, it will write a log file that contains (encoded) information about your test.  You can print the server log, and your client log, using the printRecord class contained in the project3 jar file.  To use the printRecorder program:


java -cp project3.jar printRecord <log-file-name>


where <log-file-name> is the name of the server log file (UDPserver-1.0.log) or the name of your log file.  Client log files are named from your name and your student ID that you provide in the clientRecorder constructor.  So, the log file for student Alfred Neuman whose Id is 23456789 would be named Alfred_Neuman-123456789.log.


NOTE:  Do not use spaces in your name.  If you give first and last names, please use an underscore (__) or dash (-) to separate first and last names.  Also, since you are providing your student ID, you do not need to specify your first name.


You will know that your client is working when your statistics are the same as what the server statistics show (Note: it  is OK if your rtt values and server estimated rtt values differ by a few milliseconds, but not more than 10%).  The server packet counts and your packets counts must agree to achieve a perfect score.


Additionally, the sever monitors the frequency with which you send packets (and you will see these values if you print he sever log file - they are called minimum, maximum, and average packet time in the packet statistics section of the printout.  You will lose points if you do not send packets at about 2 packets per second (one packet every 500 milliseconds).

Hand in

1.    Source code (all of your java files)..

2.    YOUR answers to these questions:

2.1.  Describe the method you used to handle concurrent requests (one or two paragraphs).

2.2.  Suppose we changed the specification for this program and said that your program had to send a request at an average rate of one request every 10 milliseconds rather than every 500 milliseconds.  What resource(s) would your program use more of?

2.3.  Why?



Place these files into a jar file and email the jar file to your assigned TA.

Name your jar file  <sid>.jar where <sid> is your student ID.




We use tools that compare program source code and detect similarly constructed programs (and classes).  So, if you copy code from a classmate we will detect it, even if you change ALL of the variable names AND move the code around in the file!  So, PLEASE do your own work.  Remember that the penalty for copying is NO CREDIT for the assignment.