Programming Project (due Friday, April 25)
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.
Ok, there are a few glitches, and the version now has the fixes; you may
make these changes yourself.
- You probably want INITTIMEOUT = 1000, not 5000.
- In the constructor public ERROR(short proto, short errcode), you need
to add the line "_errcode=errcode;" or the packet won't do anything.
- Not a glitch per se, but be sure you write the packet data received
to a separate output stream from the status messages (there should be a
status message for every packet received). I used cout and cerr;
you can also write the data to a file.
Your assignment is to do the following, by modifying and extending
the wclient.java outline file:
- Add all appropriate packet sanity checks: timeouts, host/port, size, opcode, and block number
- Generate output (to System.out)
- Terminate when a packet of size less than 512 is received
- Support arbitrary window sizes
If your program meets the other requirements but handles only a window size of 1,
you will receive a score right on the border between A and B;
your exam and homework scores will then tip the balance.
Programs received after the due date will not receive credit for sliding windows,
or for any extensions outlined below.
I recommend that you implement this in phases, as follows.
- 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.
- Add sanity checks, for (in order) host/port, packet size, opcode, and block number.
- 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.
-
Add support for an arbitrary window size.
- [optional] send an error packet when appropriate, and implement dallying (both below).
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. In some cases I have
provided sample output; note that your output may have a very different
format and may also record a very different sequence of events,
particularly if you used a different socket_timeout value.
-
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.
Sample output
-
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.
Your program should send an ERROR packet if it receives a packet from
the wrong port. The appropriate ERRCODE in this case is EBADPORT.
You will receive up to 4 points of extra credit if you implement "dallying",
which is the wump analogue of TIMEWAIT. After the client has received the
file, dallying means to wait 2.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.