Your project is to write a test program that will measure the time to transfer 1 GB of data under various conditions and prepare a report that charts the results. This is not a long or complex assignment. Your code will be shorter than this writeup. Howev

Your project is to write a test program that will measure the time to transfer 1 GB of data under various conditions and prepare a report that charts the results. This is not a long or complex assignment. Your code will be shorter than this writeup. However, start early in case you run into problems. Languages and Systems You many use Java, C, C++, Go, or Python for this assignment. Your assignment will likely run on any system but you should make sure that it runs on the Linux systems in the iLab environment. Groups You may do this assignment yourself or work in a group comprising no more than three members. Your work will be held to a higher standard if working in a group. Specifications Your program should allow you to adjust three parameters for testing: Transport: TCP or UDP Message size: ranging from 1 byte to 65,536 bytes, incrementing in powers of two (1, 2, 4, 8, 16, …) Acknowledgements: pure streaming or stop-and-wait All of these should be specified on the command line so you can easily modify them within a shell script. Your program will support two modes of communication between client and server: pure streaming and a stop-and-wait protocol. Pure streaming Pure streaming follows the logic of (in pseudocode): Client: 1G = 2^30 1M = 2^20 need_ack, msg_size = read_from_cmd_line() startmsg = { need_ack=0, total_size=1G } send(startmsg) count = total_size start_time = start_timer() while (count > 0) bytes_sent = send(buffer, msg_size) if (bytes_sent != msg_size) error() count -= bytes_sent stop_time = stop_timer() print (stop_time - start_time)/1M # throughput in megabytes per second Server: ack, size = read() send(ackbuf, 1) while (buf, bytes_read = read()) count += bytes_read if (count >= expected_size) break Stop-and-wait protocol A stop-and-wait protocol is one where each message is explicitly acknowledged by the client before the next message is sent. The logic is (again in pseudocode): Client: 1G = 2^30 1M = 2^20 need_ack, msg_size = read_from_cmd_line() startmsg = { need_ack=1, total_size=1G } send(startmsg) count = total_size start_time = start_timer() while (count > 0) bytes_sent = send(buffer, msg_size) if (bytes_sent != msg_size) error() count -= bytes_sent ack, bytes_read = read() stop_time = stop_timer() print (stop_time - start_time)/1M # throughput in megabytes per second Server: startmsg, size = read(); while (buf, size = read()) count += size send(ackbuf, 1); if (count >= expected_size) break Client Your client will accept command-line parameters that include: Hostname (or IP address in decimal dot notation) of server Port number of server Transport protocol: TCP or UDP Acknowledgement protocol: streaming or stop-and-wait Message size The server must be started first, of course, and will receive messages from the client. Prior to starting the data transfer, the client sends a message to the server with a message that, at a minimum, identifies the number of bytes that it will transfer. See the server section for possible extensions. It then waits for an acknowledgement from the server. This acknowledgement can be a single byte. Prior to transferring the data, you will note the start time. After the last message was sent, you will note the end time to compute the overall elapsed time. Basic server Your server will be given the following parameters on the command line: Port number for requests Transport protocol: TCP or UDP Acknowledgement protocol: streaming or stop-and-wait The server will start up, create a socket, and read messages from the client. The first message will contain the size. This can be assumed to be a fixed number of bytes (e.g., four bytes). This message is acknowledged (e.g., send back a single byte containing a 1 or whatever). Subsequent bytes read will contain the data. The server will continue reading the data until all the bytes have been consumed or an error occurs. Better servers A problem with the basic server is that you need to restart it each time you restart the client. You can make your server smarter by having the client communicate some more information. The command line accepts: Port number for requests Transport protocol: TCP or UDP The client, in its initial message, will identify the acknowledgement protocol to be used. You can make the server even smarter by omitting the need to specify a transport protocol and have the server create two threads, each of which is responsible for one protocol. This will take a bit more work but save you some time in running your tests. Output Server At the end of each server session (when the maximum number of bytes has been read or a TCP connection has been closed) the server will print: Acknowledgement protocol used Number of messages read Number of bytes read Client At the end of execution, the client will print Number of messages sent Number of bytes sent Total transmit time Presentation You must run your programs on different systems to avoid using a local loopback driver. You will use your programs to create four charts: TCP performance using streaming (no acks). The x-axis will list values from 1 through 65536 scaled along log base 2 (1, 2, 4, 8, 16, …). The y axis will list the throughput in megabytes per second. TCP performance using a stop-and-wait protocol. UDP performance using streaming (no acks). UDP performance using a stop-and-wait protocol.