Computer Networks Assignment 2Name: Alex Tang

Candidate number: 132219

Date: 03/05/2016

TFTP Using UDPTo begin with the implementation, I had to create a way for the user to specify firstly the IP address of the server and secondly the file name of the file being sent/received to/from the server. Simply, a buffered reader handles all the user input client side.

Using the specification of RFC 1350, I created a class containing the 5 possible types of UDP packets that can be sent/received.

RRQPacket

As specified in RFC 1350, the RRQPacket had a buffer size of

where the mode represented ‘octet’ mode and the filename represented the file name of the file wanted to be read off the server.

Apart from the op code which was held between two bytes, each character of the file name and mode were treated as a single byte along with the ‘zero byte’ and placed at known indexes in the buffer byte array.

To distinguish the different components of the buffer, the zero byte was used, if iterating through the buffer array the different sections were intuitively located using the ‘0’s for guidance.

WRQPacket

Almost identical to the RRQPacket was the WRQPacket, with only the op code differing in value. Again, the client would send such a packet if wishing to commence a write to the server.

DataPacket

For a data packet, an ‘ArrayList’ of byte arrays (of size 512) was implemented to store blocks of data read from a file ready for transport.

The Byte array of size 516 would contain 4 bytes of vital information; the op code (3) and the block number of the current data block from the file. The server/client would need the block number to check for transport errors as well as for use in sending acknowledgements. The other 512 bytes were used as space for data from the file.

ACKPacket

The ‘ACK’ packet was used by both the server and the client, the client would send acknowledgements for when reading a file to signal the receival of a block of bytes and the server would send an acknowledgement with a block number 0 to signal to the client to signal the server is ready for a file to be written to it.

ERRORPacket

Although hardly used during the version of the assignment, the error packet was used in my code to signal a file not found error. An error message containing user friendly information is found inside the packet buffer array to explain to the user what had caused the receival of such a packet.

Moving onto the code, my client class had two key methods, the readFile() and writeFile() methods.

readFile()

Reading a file requires the sending of an RRQPacket to the server along the default Port and specified IP address. The sending datagram contains the RRQPacket byte array as well as the byte arrays length (for use in the UDP layer for error checking, but not used in my code), but also the destination address and port.

Upon the receival of the RRQPacket, the server begins sending 512 chunks of data from the specified file back to the client. The client has a blocking call

which specifically waits for the first block of data from the server. If the received UDP packet has a buffer array with an op code of ‘3’ the client knows a block of data has been sent, whereas if the op code was ‘5’ this signals an error packet and the client simply closes down after outputting the message of the error packet to the user.

Given data has been received, the client copies said data to a file output stream before sending an acknowledgement for the relative block number back to the server (using the new TID as the destination received from the

initial data packet). This process loops until a received UDP packet of length less than 516 is received; as this signals the end of the file.

.

.

.

A timeout occurs if the client waits too long for a data packet from the server, and if a received packet is identical to the previously received packet then we know the server has occurred a timeout, so the current packet needs to be resent.

Looking closely at the RFC 1350 specification, each data block is acknowledged before the next block of data is sent, so my implementation is for the most part valid.

writeFile()

Writing to the server requires again an initial packet to be sent from the client, which in this case is the WRQPacket.

Before any writing to the server can occur, the client expects an acknowledgement back from the server with a specific block number of 0 to signal the server is ready to start receiving packets. This ack packet will also contain the new TID of the server thread for which the client will send to.

.

.

.

The client is ready to write to the server, using the method discussed earlier to create an array list of data packets (createTFTPDataPacket) to be sent to the server. In turn, each data block is sent, an acknowledgement is received from the server, looping until there are no more byte arrays in the array list.

Moving onto the server side, a threading approach was taken so that multiple clients can be handled simultaneously over a series of different ports.

The main server method TFTPServer has a default port of 9000, which the client needs to know to commence communication.

Looping infinitely, the server has a blocking call to receive the first initially sent packet from a client/multiple clients.

For each of these client requests, the server assigns a new thread to process any read/writes that may happen. Each of these threads is given a new and random TID so that no two ports are identical (to eradicate the chance of two server threads having the same port number and in turn cause unreliable data transfer).

Upon a new thread starting, its local port is set to the random TID set to it by the server.

The server needs to be able to distinguish between different types of requests sent to it by the sever, so inside the thread run() method is a call to a different method which reads the opcode of the received UDP packets buffer array.

The server sends to the client an error packet for when the file on the server side is unreachable/doesn’t exist.

Upon receiving a write request, the server starts a new file output stream with the filename being the filename located inside the data buffer array from the UDP WRQPacket. The server acts identical as the client here for when the client is reading a file, as in the server blocks until a single block of data has been received, for which it then sends back an acknowledgement letting the client know it can send over the next block of data.

With the reading request, the server simply replies with the first block of data from the specified file.

It then blocks until an acknowledgment from the client has been received for the relative block number.

Apart from the run() method the server is almost identical to the client, as both entities act both a client and a server (in the sense one sends data and received ack’s and the other received data and sends ack’s).

TFTP Using TCPImplementing TFTP using TCP was simple yet challenging in some aspects, one of which was communicating to the server the file name of the respected file before sending/receiving the file.

Taking the same approach as my UDP implementation, the client side uses a buffered reader to input the information the user chooses for the IP address of the server as well as the file name of the file being sent/ being received.

Given the user choose to read a file from the server, the client has to create a new socket with the default port number of the server for communication upon.

Before being able to read from the server, the client needs to inform the server of the file that’s needed to be read (for error checking in the case the file does not exist). This is done by writing the filename the user initially input using the buffered reader to the data output stream.

Since files can be transported all at once, a simple while loops receives the whole file over the input stream from the server.

The write to server method simply locates the file the user wants to send over and outputs the files name and size to the server so that the server side knows how to save the file. Upon completion, the actual file is sent over the output stream.

The client also implements a check method to see if the file being written to the server actually exists, if false the client quits.

Looking into the server side of the two way communication link, a threading approach is used to handle multiple clients. As each client knows the initial default port of the server, the server creates a new thread for each time a new client commences communication with it, accepting its socket and hence resulting in simultaneous communication.

In the server thread the processes mirror that of the client. To send a file back to the client, the server reads the file name from the data input stream, checks the file actually exists and commences writing the sockets output stream the files data.

When receiving a write request, the server needs to know which file is being sent over the socket, so again the data input stream readUTF() method is used to receive the filename from the client. The server then proceeds to the write the data received to the respective filename.

ConclusionAs a whole, both implementations required exploring new functionalities of java as well as UDP/TCP. The assignment helped me understand at a practical level the up sides and down sides of both methods of implementations and thus giving me the knowledge needed to decide my opinion of each methods applications in real life scenarios.