Where things are:

how to run:

NOTES: You must hit the receive button before hitting the send! button
       Please make sure the RDT level matches on both the receiver and 
       sender.

cd k:\07wi\csc_469\Ryan-Andy\program02

Semd file : java -jar Sender.jar [filename] [hostname] [port]

Receive file: java -jar Receiver.jar [filename] [port]

test files are in:

k:\07wi\csc_469\Ryan-Andy\program02\tests


See javadoc for the class specific information

Sender directory:
	Sender - the sender part of this program

Receiver directory:
	Receiver - the receiver part of the program

RDTCommon directory:
	RDTCommon - the guts, this library/package (whatever you call it)
	does all the communication stuff.
		

headers :
	Segment
		destination port - 2 bytes
		source port - 2 bytes
		sequence number - 2 bytes
		ack number - 2 bytes
		ack flag - 1 byte
		fin flag - 1 byte
		segment size - 2 bytes (unused, currently set to header size)
		checksum - 2 bytes
		
		The segments source and destination port information is not
		used by the program, but they do contain the correct values

	Packet
		packet size - 2 bytes (unused, currently set to header size)
		checksum - 2 bytes (not filled, unused)
		rdt level - 1 byte (unused idea, "for future use")
		pad - 1 byte (I like even sized headers, "for future use")
		source ip address - 4 bytes
		destination ip address - 4 bytes

		The source and destination data is not used by the code, but
		do contain the correct information
	
Tests :
	I tested with various error percentages
	I tested various sized files
	I did a diff from the original file and the copy to make sure there
	were no differences

State of Code:
	All methods (RDT 1.0, RDT 2.2, RDT 3.0, and Selective Repeat)
transfer a file correctly.  RDT 2.2 correctly handles corrupt packets.  RDT
3.0 and SR correctly handle corrupted and dropped packets.  I did not try
"out of order" packets due to lack of time, you saying we didn't need to,
and the fact the dropped packets basicly simulate this anyways.  The
programs should exit once the transfer is complete, but do not do so under certain
conditions (see problems/bugs).  

Problems/bugs/non-features :
	I wasted a lot of time trying to figure out why my select would
return immediately, when it had a timeout and no channels had data on them. 
It finally ended up being that the select method does not like having a
timeout out 1!!!!! I set the min. timeout to 5 msec, and have not had my
problem again (WRT that cause of it). Came in sunday to check if things worked at NCC,
I had the same problem I was having with linux.  Changed the min. timeout to
30 msec and things worked again. There are a few cases where the program does not exit
nicely, one is if the FIN gets dropped (I could fix it, but I don't have the time),
the other one might only happen on linux, but I need to check that.

The GUIs don't exit when the file is done.

Other things that I don't have time for:

The GUI buttons are enabled when the file is being transfered, I haven't
even checked what would happen if I try hitting send/recv a second time. 
The error rates and RDT levels should be a problem themselves, only if you
try hitting send/recv again.  It would have been nice to be able to change
error rates/types during transfer.

It would have been nice to be able to set my window size for Selective
Repeat from the GUI, but I thought of that too late.

I would have liked to have an "ETA" for the sender to send the file.

Another nice feature would have been to be able to send multiple files without
having to restart the program.  I was not thinking about this when I wrote
the program, I would probably have to add a way of resetting everything.