CSC424 Computer Networks
Simple Transport Protocol You will design a simple transport protocol that provides reliable datagram service. Your protocol will be responsible for ensuring that data is delivered in order and without duplicates. Your protocol will be tested on an emulated unreliable network.
1. Requirements You will write two programs: a sending program that sends a file across the network, and a receiving program that receives the file and stores it to local disk. It is recommended that your programs are written in C on a Linux operating system. You may not use any transport protocol libraries in your project (such as TCP). You must construct the packets and acknowledgements yourself, and interpret the incoming packets yourself. Your programs will achieve the following goals:
Â· The sender reads a local file and uses your protocol to send it.
Â· Transfer the file contents reliably.
Â· The receiver must write the contents it receives into the local directory.
Â· Your sender and receiver must gracefully exit.
Â· Your code must be able to transfer a file with any number of packets dropped, duplicated, and delayed. You have to design your own packet format and use UDP as a carrier to transmit packets. Your packet might include fields for packet type, acknowledgement number, advertised window, data, etc.
This part of the project is entirely up to you. You have to implement a retransmission protocol to deal with dropped, duplicated, and delayed packets. You may assume that packets are not corrupted so you do not need to implement any error correction codes. You must implement at least Stop-and-Wait and Go-Back-N protocols. However, more sophisticated algorithms (for example, selective repeat) will be given bonus credit. Some desired properties of your protocol include (but are not limited to):
Â· Fast: Require little time to transfer a file.
Â· Low overhead: Require low data volume to be exchanged over the network, including data bytes, headers, retransmissions, acknowledgements, etc. Better performance will result in higher points. Remember that network-facing code should be written defensively. Your code should check the integrity of every packet received.
2. Your programs The command line syntax for your sending program is given below. The client program takes command line argument of the remote IP address and port number, and the name of the file to transmit. The syntax for launching your sending program is therefore: sendfile recv_host (Required) The IP address of the remote host in a.b.c.d format. (use 127.0.0.1 for localhost) recv_port (Required) The UDP port of the remote host. filename (Required) The name of the file to send. Your sending program should print out messages to the console:
Â· When the sender sends a packet for the first time, it should print the following: [send data] start (length) where start is the beginning offset of the file sent in the packet, and length is the amount of the file sent in that packet.
Â· When the sender resends a packet, it should print the following: [resend data] start (length) where start is the beginning offset of the file sent in the packet, and length is the amount of the file sent in that packet.
Â· When the sender receives an acknowledgement, it should print the following: [recv ack] ackno where ackno is the acknowledge number
Â· You may also print messages of your own depending on your design, but make it concise and readable. The command line syntax for your receiving program is given below.
The server program takes command line argument of the port number. The syntax for launching your receiving program is therefore: recvfile recv_port (Required) The UDP port to listen on. Your receiving program should print out messages to the console:
Â· When the receiver receives a valid data packet, it should print: [recv data] start (length) status where status is one of ACCEPTED or IGNORED
Â· You may also print messages of your own depending on your design, but make it concise and readable. Both the sender and the receiver should print out a message after completion of file transfer, and then exit: [completed]
3. Testing your code
A. Unreliable network In order for you to test your code, you should emulate an unreliable network. To fulfill this task, you will use netem, which is a simple network packet loss emulation tool in Linux. In order to use netem, you need to install the iproute package through the Ubuntu package manager or sudo apt-get install iproute Once iproute is installed you can use the binary â€œtcâ€ to delay traffic. Only root can modify a network interface so either su to root or use sudo. The following command line gives a simple example in which a constant 100ms delay is added to outgoing packets of the external interface, eth0. Understand that netem only adds the delay to packets leaving the interface. sudo tc qdisk add dev eth0 root netem delay 100ms To disable the netem delay products on the interface we can delete the rules. sudo tc qdisk del dev eth0 root netem Your sending and receiving programs probably will run and be tested on a single machine. In this case, you can use lo (Local Loopback) as your device instead of eth0: sudo tc qdisk add dev lo root netem delay 100ms A detailed description of the usage of netem can be found at: You will need to try different configurations of the network by changing:
Â· Delay distribution
Â· Packet loss rate
Â· Packet duplication rate
Â· Packet re-ordering rate For example, sudo tc qdisk add dev eth0 root netem delay 100ms 20ms 25% loss 0.5% duplicate 1% reorder 25% 50% This configuration says:
Â· Delay is 100ms Â± 20ms with the next random element depending 25% on the last one.
Â· Packet loss rate is 0.5%
Â· Packet duplicate rate is 1%Â· 25% of packets (with a correlation of 50%) will get sent immediately, others will be delayed.
B. Large files Your program needs to handle file of any size. To create a dummy file in Linux (Ubuntu), use the command line: base64 /dev/urandom | head -c 10000000 > file.txt This creates a file with name file.txt size of 10MB. You can use different configurations to test other file sizes.
4. Report You will write a report for this project. There is no strict format of this report but below are the essential parts:
1. How you design the packets and your protocol.
2. A screen shot of the console in a successful run of your programs.
3. Try different configurations of netem and report the results.
4. Evaluate the efficiency of your protocol (e.g. throughput and delay).
5. Perform a comparative study of Stop-and-Wait and Go-Back-N. There are other aspects that you can explore and report, which are up to you. More comprehensive study will receive more credits. * Do not paste a lot of codes in the report. Focus on the design and analysis. Your codes will be submitted separately.
6. Submitting your project You should submit your project in Blackboard. The submission includes: a project report and your source codes. Please put everything in a zip/rar file, name it â€œFirstName_LastName_Project2.zipâ€ or â€œFirstName_LastName_Project2.rarâ€ 6. Advice Start by getting your code working without any packet manipulation. You can check whether your code successfully transmits the file by using the diff program in Linux. Test your code with each type of manipulation separately and then in combination. Note that you will likely have to introduce multiple reliability mechanisms (timeouts, retransmits, etc) in order to handle all of the possible errors. Start early! Do not wait until the last few days
CAPE5330: You have completed RTD experiments on each of the reactors: Advanced Reaction Engineering Coursework, UOL, UK
November 28, 2022
A critical argument of relevant supply chain models/concepts from multiple sources, (supported by references) have to underpin discussion.
November 28, 2022