The objective of this exercise is to implement a simple and robust file-sharing system, using both TCP and UDP.
Overview and Functioning
A client connects to a server using TCP. Once the TCP connection is established, the client uses it to give commands to the server, specifically:
- Send a file (from the server) to the client on a specific IP address and port number
- Retransmit part of a file to the client on a specific IP address and port number.
The server sends the file to the client using UDP, chopping the file up in chunks and sending each chunk in an UDP datagram. UDP datagrams can be both lost, and can arrive out of order. Thus when reconstructing the file, the server must take care to properly order received chunks, to verify that all chunks have been received — and otherwise to request retransmissions.
For convenience, the implemented file-sharing system only needs to support requests and transfer of files with size
TCP Connection Message Formats
The server accepts, over the TCP connection, HTTP 1.1 requests for URLs of the following form:
- /sendfile///
- where:
is the name of the file to send
is the (IPv4) address of the client, to which the file should be sent
is the UDP port number of the client, to which the file should be sent.
- /retransmit/////
- where:
is the name of the file, for which a chunk is to be retransmitted
is the (IPv4) address of the client, to which the file should be sent
is the UDP port number of the client, to which the file should be sent.
is the index of the first octet of the file to retransmit
is the number of octets from to retransmit.
The server responds, over the HTTP|TCP connection, with either of the following:
- OK
- (in response to a sendfile request), where:
is the size of the requested file
- OK
- (in response to a retransmit request)
- ERROR No such file
- In case the requested file does not exist on the server
- ERROR Internal error
- where:
may indicate additional information about the nature of the error
- ERROR
- where:
may indicate additional information about the nature of the error
Duly note that the server expects a properly formatted and complete HTTP 1.1 request, least an error will be returned. After responding to a HTTP request, the server closes the TCP connection.
UDP Message Formats
The server will send the file back to the client using UDP. To this end, the server will chop up the file in “chunks”. These “chunks” must be small enough to fit within an MTU.
The format of each chunk, as contained within the UDP packet, is as follows:
- where:
is a 16 bit unsigned integer in network byte order, and which indicates the position of the first octet of the data, in the complete data stream.
is a 16 bit unsigned integer in network byte order, and which indicates the number of octets in the data part.
is a sequence of chunk_size octets
Your Assignment
- You are required to implement both the client and the server.
- Your server must be able to handle multiple concurrent file transfers with multiple clients.
- Your implementations will be tested against, and must interoperate with, our implementations.
- You are expected to figure out on your own every aspect that is not explicitly indicated in the specification -- several solutions may be valid, as long as they interoperate with our implementations.
- You are required to submit complete source-code for both the client and the server.
- You are required to accompany your source-code with a readme.txt file, explaining how we are expected to use, and test, your implementation.
A binary version of the server is provided for you to test against.
How To Make Sure That You Will Fail This Assignment
Below is anon-exhaustivelist of things, which will definitely give you zero points for this:
- Your submission contains any form plagiarism.
- Your submission does not include a readme.txt that explains how we’re supposed to use/test your implementation
- Your client does not manage to properly reassemble the original file, for any file type. Special cases of the above if are:
- If your client manages to properly transfer and reassemble a text file, but an image file cannot be viewed or an executable cannot be executed, then your client is considered to “not manage to properly reassemble the original file”.
- Your client or server assumes that chunks are not lost,and/orthat chunks are received in order.
- Your client and your server interoperate with each other, but either (or both) does not interoperate with our implementation. (Given that you have our server implementation to test against, there really is no excuse)
- Your submitted code does not compile without warnings (this includes“unused variables”or implicit typecasting warnings, etc.)
- Your client or your server crashes, or corrupts the file being transferred.
- Your server implementation is unable to handle multiple clients concurrently.