# MP2 Networks Grading Rubric

This should take 10 - 15 minutes.

## Specification 4

### Part A

#### Basic [4 marks]

Ask them to demonstrate the following -

1. TCP server program
2. TCP client program
3. UDP server program
4. UDP client program

Give `0.5 marks` if they are working (client is able to send some data to the server for UDP and TCP)

Give `0.5 marks` for any 4 questions out of the following questions -

1. What does `htons()` do?
2. In the server code, what happens if the listen function fails? How can you improve error handling for this situation?
3. Explain what could go wrong if the accept function fails, and how can it be handled?
4. What kind of errors might occur during the connect function call, and how can they be addressed?
5. How have you implemented error handling for invalid IP addresses or ports in the client programs?
6. What are the key differences between handling errors in TCP and UDP programs? (depends on their implementation
7. **Mandatory** Ask them to show any place in their code where they are handling some other error and explain it.

_Note_: Using perror to check for errors is fine.

#### Rock, Paper, Scissor [8 marks]

No viva question here.

1. `4 marks` for showing the working using TCP sockets
2. `4 marks` for UDP sockets

### Part B

Here's the exact specification from the project -

---

Seems hack-y? Very. But, it’s OSN not just N and the point of this course is to hopefully make you understand some stuff.

Functionalities that you have to implement are (10 marks):

1. Data Sequencing: The sender (client or server - both should be able to send as well as receive data) must divide the data (assume some text) into smaller chunks (using chunks of fixed size or using a fixed number of chunks). Each chunk is assigned a number which is sent along with the transmission (use structs). The sender should also communicate the total number of chunks being sent [1]. After the receiver has data from all the chunks, it should aggregate them according to their sequence number and display the text.
2. Retransmissions: The receiver must send an ACK packet for every data chunk received (The packet must reference the sequence number of the received chunk). If the sender doesn’t receive the acknowledgement for a chunk within a reasonable amount of time (say 0.1 seconds), it must resend the data. However, the sender shouldn’t wait for receiving acknowledgement for a previously sent chunk before transmitting the next chunk [2].

[1] Regardless of whether you use a fixed number of chunks

[2] For implementation’s sake, send ACK messages randomly to check whether retransmission is working - say, skip every third chunk’s ACK. (Please comment out this code in your final submission)

---

Run the code and ask the student to point out where the following things are implemented (Be lenient)

1. `2 marks` for adding sequencing to the packets
2. `8 marks` for implementing retransmissions
- `0.5 mark` for receiving ACK packets
- `1 mark` for displaying the data in the correct order regardless of retransmissions
- `5 marks` for implementing retransmissions (ask the student to selectively leave out some packets - we had asked to comment out this part in the code - and then check whether things are being retransmitted)
- `1.5 marks` for implementing two-way comms (both client and server should be able to send and receive packets)

_NOTE_ There are multiple ways in which students have tried to scam the implementation - do not award more than 3 marks (out of 10) if they have done so. Some of them are -
1. Sending all the packets at once and then waiting for all the acknowledgements. The best way to check for this is to ask them to change the timeout for waiting for an ACK.
2. Using TCP sockets directly (yes) - just give 0 in this case

There is only one correct way of doing this. An example could be:
1. Sender sends A1.
2. Sender sends A2.
3. Sender gets ack for A1.
4. Sender sends A3.
5. Sender notices that it hasn't receieved an ACK for A1, i.e., it times out. It resends A1. Sends A4.
6. Etc.

Do note that the sender retransmits after the timeout, so it may not be exactly at timeout.

The report consists of -

---
To make your life simpler, the rest of the 8 marks is a report -

1. How is your implementation of data sequencing and retransmission different from traditional TCP? (If there are no apparent differences, you may mention that) (3 marks)
2. How can you extend your implementation to account for flow control? You may ignore deadlocks. (5 marks)
---

If they haven't coded out but have somehow explained how they could have implemented the spec (As the questions are asked on _their_ implementation) give only 50% of the total marks for the report (4 marks out of 8)

If they haven't even explained what could have been done (and haven't code it out either) then don't give any marks.

As long as they know what they've written and can explain it they should be awarded marks.
1. 3 points for Q1
2. 200-300 word answer