CS4333/6333 Computer Networks Fall 2018
PROJECT 2: RELIABLE DELIVERY
For this project we will explore the challenges associated with providing reliable delivery services over an unreliable network. Three different ARQ approaches have been described in class: stop-and-wait, concurrent logical channels and sliding window. Your task during this project is to develop a set of Java classes capable of reliably transferring a file between two hosts over UDP (TCP already offers reliable delivery services).
Students will be provided with a UDPSocket class that extends the DatagramSocket class provided by Java to send a DatagramPacket over UDP. Take time to familiarize yourself with the main two classes provided by Java for UDP support and their functionality. The UDPSocket class has the additional capability of allowing programmers to modify the MTU (to model fragmentation), the packet drop rate (to model unreliable networks) and add random time delays to packets (to model out-of-order reception).
Support material
Parameters regulating message transfers using the UDPSocket class are located in a file named unet.properties. This file may be modified to test different scenarios (the file includes comments describing each parameter). Note that you can also use this file to enable and configure logging options (to file or standard output stream).
Unet.properties
#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ # unet properties file #~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#== log file name ================================ #
# log.filename = system (standard output stream)
log.filename = system log.enable = true
#== packet drop rate ============================= #
- # n<0 — Drop random packets (n*-100) probability
- # n=0 — Do not drop any packets
- # n=-1 — Drop all packets
- # n>0 — Drop every nth packet (assuming no delay)
- # n=[d,]*d — Drop select packets e.g. packet.droprate = 4,6,7
packet.droprate = 0
#== packet delay rate ============================ #
- # packet delay in milliseconds
- # min==max — in order delivery
packet.delay.minimum = 10 packet.delay.maximum = 100
#== packet maximum transmission size ============= #
# -1 unlimited (Integer.MAX_VALUE)packet.mtu = 1500
1/7
M. Papa CS4333/6333 Computer Networks Fall 2018
A brief tutorial on how to use UDP in Java is provided in the Appendix. A zip file (unet.zip) containing sample code, a supporting jar file (unet.jar) as well as the default unet.properties file will be provided. Please note that Java 1.5 or better is required by UDPSocket.
NOTE: You may download all the support files from Harvey.
Programs
A minimum of two classes will have to be submitted, RSendUDP.java and RReceiveUDP where each class must implement the edu.utulsa.unet.RSendUDPI and edu.utulsa.unet.RReceiveUDPI interfaces respectively (as specified below, provided in unet.jar).
package edu.utulsa.unet;
import java.net.InetSocketAddress; public interface RSendUDPI {
public boolean setMode(int mode); public int getMode();
public boolean setModeParameter(long n); public long getModeParameter();
public void setFilename(String fname); public String getFilename();
public boolean setTimeout(long timeout); public long getTimeout();
public boolean setLocalPort(int port);
public int getLocalPort();
public boolean setReceiver(InetSocketAddress receiver); public InetSocketAddress getReceiver();
public boolean sendFile();
}
package edu.utulsa.unet; public interface RReceiveUDPI {
}
public boolean setMode(int mode); public int getMode();
public boolean setModeParameter(long n); public long getModeParameter();
public void setFilename(String fname); public String getFilename();
public boolean setLocalPort(int port); public int getLocalPort();
public boolean receiveFile();
The setMode method specifies the algorithm used for reliable delivery where mode is 0 or 1 (to specify stop-and-wait and sliding window respectively). If the method is not called, the mode should default to stop-and-wait. Its companion, getMode simply returns an int indicating the mode of operation.
The setModeParameter method is used to indicate the size of the window in bytes for the sliding window mode. A call to this method when using stop-and-wait should have no effect. The default value should be 256 for the sliding window algorithm. Hint: your program will have to use this value and the MTU (max payload size) value to calculate the maximum number of outstanding frames you can send if using the Sliding Window algorithm. For instance, if the window size is 2400 and the MTU is 20 you could have up to 120 outstanding frames on the network.
The setFilename method is used to indicate the name of the file that should be sent (when used by the sender) or the name to give to a received file (when used by the receiver).
The setTimeout method specifies the timeout value in milliseconds. Its default value should be one second.
A sender uses setReceiver to specify IP address (or fully qualified name) of the receiver and the remote port number. Similarly, setLocalPort is used to indicate the local port number used by the
2/7
M. Papa CS4333/6333 Computer Networks Fall 2018
host. The sender will send data to the specified IP and port number. The default local port number is 12987 and if an IP address is not specified then the local host is used.
The methods sendFile and receiveFile initiate file transmission and reception respectively. Methods returning a boolean should return true if the operation succeeded and false otherwise.
Operation requirements
RReceiveUDP
- Should print an initial message indicating the local IP, the ARQ algorithm (indicating the value of
n if appropriate) in use and the UDP port where the connection is expected.
- Upon successful initial connection from a sender, a line should be printed indicating IP address
and port used by the sender.
- For each received message print its sequence number and number of data bytes
- For each ACK sent to the sender, print a message indicating which sequence number is being
acknowledged
- Upon successful file reception, print a line indicating how many messages/bytes were received
and how long it took.
RSendUDP
- Should print an initial message indicating the local IP, the ARQ algorithm (indicating the value of
n if appropriate) in use and the local source UDP port used by the sender.
- Upon successful initial connection, a line should be printed indicating address and port used by
the receiver.
- For each sent message print the message sequence number and number of data bytes in the message
- For each received ACK print a message indicating which sequence number is being acknowledged
- If a timeout occurs, i.e. an ACK has been delayed or lost, and a message needs to be resent, print
a message indicating this condition
- Upon successful file transmission, print a line indicating how many bytes were sent and how long
it took.
Fragmentation and in-order-delivery
In-order delivery is implicitly solved by the stop-and-wait algorithm (only one outstanding packet at all times) and explicitly by the sliding-window algorithm. You are responsible for developing an operating solution that will allow your programs to reconstruct the file even if fragments were received out-of-order.
Design
Your programs are essentially operating at the application layer (just like ftp, http and many other protocols) using an unreliable transport layer (UDP). Please plan your design before you start coding and define a packet format that will allow safe and consistent file transfers. Your header design must include information that will allow the receiver to detect when the file has been transferred. Furthermore, the receiver should save the received data as soon as the transfer is complete.
I encourage group discussions and sharing of the packet format used for the file transfers. Implementation should be individual. The advantage of sharing the packet format with other students is that you will have the ability of testing your program with others.
DO NOT make RSendUDP and RReceiveUDP part of any package.
Usage
Program usage will be illustrated by the following example. Assume Host A has IP address 192.168.1.23 and Host B has IP address 172.17.34.56 (note that none of these IP addresses are routable over the
3/7
M. Papa CS4333/6333 Computer Networks Fall 2018
Internet). Host A wants to send a file named important.txt to Host B. Host A wants to use local port 23456 and Host B wants to use local port 32456 during the file transfer. Host B does not consider the file so important and it wants to save the received file as less_important.txt. Both Host A and B have agreed to use the sliding-window protocol with a window size of 512 bytes and Host A will use a timeout value of 10 seconds (the path between A and B has a rather large delay).
Sample Code
The following code running on Host A should accomplish the task of reliably sending the file:
RSendUDP sender = new RSendUDP();
sender.setMode(1);
sender.setModeParameter(512);
sender.setTimeout(10000);
sender.setFilename(“important.txt”);
sender.setLocalPort(23456);
sender.setReceiver(new InetSocketAddress(“172.17.34.56”, 32456)); sender.sendFile();
The following code running on Host B should accomplish the task of receiving the file:
RReceiveUDP receiver = new RReceiveUDP(); receiver.setMode(1); receiver.setModeParameter(512); receiver.setFilename(“less_important.txt”); receiver.setLocalPort(32456) receiver.receiveFile();
Sample Output
Assume our solution uses 10 bytes of header for every message, the network cannot deliver messages larger than 200 bytes and the file we are transferring is 800 bytes long. The output of your program (on the sender side) when running the stop-and-wait algorithm could look like this:
Sending important.txt from 192.168.1.23:23456 to 172.17.34.56:32456 with 800 bytes Using stop-and-wait
Message 1 sent with 190 bytes of actual data
Message 1 acknowledged
Message 2 sent with 190 bytes of actual data Message 2 acknowledged
Message 3 sent with 190 bytes of actual data Message 3 timed-out
Message 3 sent with 190 bytes of actual data Message 3 acknowledged
Message 4 sent with 190 bytes of actual data Message 4 acknowledged
Message 5 sent with 40 bytes of actual data
Message 5 acknowledged
Successfully transferred important.txt (800 bytes) in 1.2 seconds
A similar output should be seen on the receiver side.
Grading
Stop-and-wait and sliding window have to be implemented for full credit. Note that the value of the MTU cannot be changed programmatically when using UDPSocket. However, you can manipulate its value by editing the unet.properties file. The getSendBufferSize and setSendBufferSize provided by DatagramSocket (and consequently by UDPSocket) should be used when accessing MTU values (a call to setSendBufferSize in UDPSocket will throw an exception).
4/7
M. Papa CS4333/6333 Computer Networks Fall 2018
At the time your submission is graded, several values of MTU will be used (by modifying unet.properties). Please make sure you test your program thoroughly.
Report
A brief report should be typed and turned in by the due date at class time. The report does not need to be long and should only describe your approach (and challenges) in solving the problem and any methods or variables of relevance in your class. In particular, describe the packet format in detail and provide explanations for each field.
The report should also include a “feedback” section about this project.
Submission
The report and electronic submissions are due at class time on the due date
Submissions will be done via Harvey (harvey.utulsa.edu) and at a minimum, should contain your report, one RSendUDP.java file, one RReceiveUDP.java file and any other supporting classes you created.
DUE DATE: Friday, October 26th, 2018 at 11:00am
5/7
M. Papa CS4333/6333 Computer Networks Fall 2018
Appendix: UDP Datagram transfers in Java (UNET Example Program)
The following two pieces of code illustrate how to use UDP facilities in Java. A sender program is used to send a “Hello World” message to a receiver over UDP. The UDPSocket class (in unet.jar) extends the DatagramSocket class provided by Java and gives you additional control over any message transfers as specified in the unet.properties file. Please note that these two programs will still work if all instances of UDPSocket are replaced by DatagramSocket.
Server
The following code creates a server that listens on port 32456 and simply outputs the data it receives.
import java.net.DatagramPacket;
import edu.utulsa.unet.UDPSocket; //import java.net.DatagramSocket; import java.net.InetAddress;
public class udpreceiver {
static final int PORT = 32456;
public static void main(String[] args) {
try {
} }
Client
byte [] buffer = new byte[11];
UDPSocket socket = new UDPSocket(PORT);
DatagramPacket packet = new DatagramPacket(buffer,buffer.length); socket.receive(packet);
InetAddress client = packet.getAddress();
System.out.println(” Received'”+new String(buffer)+”‘ from ”
+packet.getAddress().getHostAddress()); catch(Exception e){ e.printStackTrace(); }
}
The following code creates a client, capable of transmitting a simple message to the server.
import java.net.DatagramPacket;
import edu.utulsa.unet.UDPSocket; //import java.net.DatagramSocket; import java.net.InetAddress;
public class udpsender {
static final String SERVER = “localhost”; static final int PORT = 32456;
public static void main(String[] args) {
try {
} }
byte [] buffer = (“Hello World”).getBytes(); UDPSocket socket = new UDPSocket();
socket.send(new DatagramPacket(buffer, buffer.length,
InetAddress.getByName(SERVER), PORT)); catch(Exception e){ e.printStackTrace(); }
}
Compilation and Execution
We first compile these two Java files with the following commands: 6/7
M. Papa CS4333/6333 Computer Networks Fall 2018
D:\somedir>javac -classpath unet.jar;. udpsender.java D:\somedir>javac -classpath unet.jar;. udpreceiver.java
Run the receiver first and then the sender (you will need two separate shells):
D:\somedir>java -cp unet.jar;. udpreceiver Received ‘Hello World’ from 127.0.0.1
D:\somedir>java -cp unet.jar;. udpsender
50 0 127.0.0.1:32456 –> Hello World :: 48 65 6C 6C 6F 20 57 6F 72 6C 64
The output generated by the client is part of the logging facility provided by edu.utulsa.unet.UDPSocket, and can be managed through unet.properties. This feature provides information regarding the status of packets within the UDPSocket object.
The time the packet is sent
|
0 |
127.0.0.1:32456 |
–> |
Hello World |
50
Packet status ‘-->’ indicates successful transmission
‘XXX’ indicates packet loss
:: 48 65 6C 6C 6F 20 57 6F 72 6C 64 ASCII packet data Raw packet data
Packet identification number
7/7