Programming Project (due Wednesday, April 27^H^H29)

Your project will be to implement the BUMP client in java. Here is an overview of the three WUMP protocols (BUMP, HUMP, and CHUMP). Here are the files wumppkt.java, containing the packet format classes, and wclient.java, which contains an outline of the actual program. Only the latter file should be modified; you should not have to make changes to wumppkt.java.

Your assignment is to do the following, by modifying and extending the wclient.java outline file:

For extra credit, you may choose to implement support for arbitrary window sizes. You may also earn extra credit by implementing the HUMP or CHUMP protocol variants, although for these you will have to work with me regarding the server side and so this option is available only by permission. You may also, with permission, earn extra credit for developing your own BUMP server.

If your program meets the other requirements but handles only a window size of 1, you will receive a score of 95/100. Programs received after the due date will not receive extra credit for sliding windows.

I recommend that you implement this in phases, as follows.

  1. Latch on to the new port: save the port number from Data[1], and make sure all ACKs get sent to this port. This will mean that the transfer completes. You should also have the output written to System.out, and make sure the client stops when a packet with less than 512 bytes of data is received.
  2. Add sanity checks, for (in order) host/port, packet size, opcode, and block number.
  3. Handle timeouts, by retransmitting the most recently sent packet when the elapsed time exceeds a certain amount (4 seconds?). One way to do this is to keep a DatagramPacket variable LastSent, which can either be reqDG or ackDG, and just resend LastSent. Note that the response to an InterruptedIOException, a "true" timeout, will simply be to continue the loop again.
  4. Add support for an dallying and error packets. After the client has received the file, dallying means to wait 2.0 - 3.0 timeout intervals (or more) to see if the final data packet is retransmitted. If it is, it means that the final ACK was lost. The dally period gives the client an opportunity to resend the final ACK. Error packets are to be sent to any sender of an apparent data packet that comes from the wrong port.
  5. Add support for arbitrary window sizes last, after everything else is working.

You can test your program by contacting the server (at ulam.math.luc.edu) and requesting files. No matter what file you ask for, the file you get is always the same. However, by asking for the following names, you get the indicated behavior:

lose
Lose everything after the first windowful (min 3). It will be retransmitted when you retransmit the previous ACK.
spray
Constant barrage of data[1]. Implies LOSE too. In this case, no timeout events will occur; you must check for elapsed time.
delay
Delays sending packet 1, prompting a duplicate REQ and thus results in multiple server instances on multiple ports.
reorder
Sends the first windowful in the wrong order.
dupdata2
DATA[2] is sent twice
losedata2
DATA[2] is lost on initial send, until you resend ACK[1]
marspacket
A packet from the wrong port (a "martian" port) arrives
badopcode
a packet arrives with an incorrect opcode
nofile
you get an error packet with a NO FILE error code.