Java Assignment

Implementation Notes:

You will implement the sender and receiver components of a transport layer. The sender reads a stream of data (from a file), breaks it into fixed-sized packets suitable for UDP transport, prepends a control header to the data, and sends each packet to the receiver. The receiver reads these packets and writes the corresponding data, in order, to a reliable stream (a file).

A high-level overview of the system:

Input File Sender data datagrams travel over UDP Receiver Output File

← ACK datagrams travel over UDP

Note:

The Receiver should exactly reproduce the Sender's input file's content in its output file, regardless of a lossy, congested, or corrupting network layer.

· You will ensure reliable transport by having the Receiver acknowledge packets received from the Sender; the Sender will detect missing acknowledgements and resend the dropped, delayed, or corrupted datagrams after a timeout period. The default timeout period is 2000ms, but you may change this with the -t command-line option.

· The Receiver will only use positive ACKs for any datagrams that it receives.

· Acknowledgement datagrams do not need to be acknowledged by the Sender.

· Your Receiver should ensure that data are written in the correct order, even if the network layer reorders packets.

· Provide trivial flow control – based on the send window. You should support arbitrary window sizes. Allow multiple packets to be outstanding at any time. The window size is supplied by the -w command-line option.

· File data will be text.

· Because we are doing this between two processes on a single machine, latency is near 0, and no network faults can occur. As a result, you should introduce errors to test the correctness of your implementation. The Sender and Receiver programs must both accept options to force packets to be lost, delayed, or corrupted at both processes.

· User Interface Design a simple UI (command line, or optionally GUI). (java edu.metrostate.Sender -s 100 -t 30000 -w 4 -d 0.25 receiver_ip_addr receiver_port java edu.metrostate.Receiver -w 4 -d 0.5 receiver_ip_addr receiver_port) The user may specify:

· For the Sender:

· size of packet using the -s command line argument

· timeout interval using the -t command line argument

· the IP address and port at which the receiver is listening

· For the Receiver

· the IP address and port at which the Receiver should listen

· For the Sender and Receiver:

· sliding window size, using the -w command line argument

· percentage of datagrams to corrupt, delay, or drop using the -d argument

· You will start your Sender and Receiver in two separate JVMs.

· Both programs should run outside of your IDE

· Do not launch them from Eclipse

· Both windows should be open side by side, so you can watch the output from each

· Windows should have reasonable contrast and font size so text is easily readable (use black text on a white background, and a medium to large font)

· Your programs should present enough information to demonstrate the protocol in action.

· The information provided in the sender’s window should include (in fixed width columns):

· For each datagram attempted to be sent:

· Static text:

· If first time datagram is being sent: [SENDing]:

· If resending a datagram: [ReSend.]:

· sequence number of datagram (integer, [0,(size of file)/(size of packet)]

· byte sequence carried in datagram: [<start byte offset>:<end byte offset>]

· datagram sent time in milliseconds

· datagram condition depending on random error [SENT|DROP|ERRR|DLYD] for a delayed datagram, show it twice: first with DLYD, and later with SENT

· For each ACK received

· Static text [AckRcvd]:

· Sequence number of datagram that was ACKed

· Static text:

· if duplicate ACK received: [DuplAck]

· if corrupted ACK is received: [ErrAck.]

· if ACK will move window: [MoveWnd]

· For each timeout event

· Static text [TimeOut]:

· Sequence number of datagram that timed out

· The information provided in the receiver’s window should include (fixed width output), for each datagram received:

· Static text

· if first time datagram is being received: [RECV]

· if duplicate datagram received: [DUPL]

· Sequence number of data datagram

· Condition of data Datagram

· if datagram is corrupt: [CRPT]

· if datagram is received out of sequence: [!Seq]

· if datagram is good: [RECV]

· For each ACK datagram, decision for the ACK: [DROP|SENT|ERR]

It is important that your console output be slowed down to human time, and that you can explain the behavior of your software program as it reacts to packets.

Implementation Details

Packet Types and Fields

There are two kinds of packets, Data packets and Ack-only packets. You can tell the type of a packet by its length.

public class Packet {

short cksum; //16-bit 2-byte

short len; //16-bit 2-byte

int ackno; //32-bit 4-byte

int seqno ; //32-bit 4-byte Data packet Only

byte data[500]; //0-500 bytes. Data packet only. Variable

}

· cksum: 2 byte IP checksum. Use 0 for good, 1 for bad.

· len: 2 byte total length of the packet.

· For Ack packets this is 8: 2 for cksum, 2 for len, and 4 for ACK no

· For data packets, this is 12 + payload size: 2 for cksum, 2 for len, 4 for ackno, 4 for seqno, and as many bytes are there in data[] Note: You must examine the length field, and should not assume that the UDP packet you receive is the correct length. The network might truncate or pad packets.

· ackno: 4-byte cumulative acknowledgment number. ackno is the sequence number you are waiting for, that you have not received yet – it is the equivalent of Next Frame Expected. This says that the sender of a packet has received all packets with sequence numbers earlier than ackno, and is waiting for the packet with a seqno of ackno. The first sequence number in any connection is 1, so if you have not received any packets yet, you should set ackno to 1.

The following fields will not exist in an ACK packet:

· seqno: Each packet transmitted in a stream of data must be numbered with a seqno. The first packet in a stream has a seqno of 1. This protocol numbers packets.

· data: Contains (len - 12) bytes of payload data for the application. To conserve packets, a sender should not send more than one unacknowledged Data frame with less than the maximum number of bytes (500)

Use a datagram with an empty data[] to indicate the end of your stream.

Interoperability bonus