Changelog:

  • 14 Feb 2023: refer more clearly to protocol section from exercise part; note about submitting to the submission site and requirements for that; adjust intro to refer to mailbox model.
  • 15 Feb 2023: add the parenthetical (plus a checksum) an additional tim in the protocol description
  • 15 Feb 2023: note explicitly that recvd is called when packets are received.
  • 15 Feb 2023: add note about wrong len for fwrite in some versions of the template code.

In some versions of the lab template code before approx 4pm 15 Feb, the fwrite uses len instead of len-3. If note corrected this may be the cause of some extra junk in the output on ./netlab 2.

You’ve already worked with TCP sockets in CSO1. In this lab you’ll learn how to add reliability on top of unreliable mailbox type model of a network.

You’ll have enough to do in this lab, we’ll not worry about doing it over an actual network. We’ve provided a simple network simulator for you.

  1. Download netlab.tar on a linux system (e.g., with wget https://www.cs.virginia.edu/~cr4bd/3130/S2023/files/netlab.tar).

  2. Extract it and enter the directory (e.g., with tar xvf netlab.tar; cd netlab).

  3. Test it with

    make
    ./netlab 0

    You should see a welcome message appear, ending with a !.

  4. Edit netlab.c so that you also see messages for ./netlab 1, ./netlab 2, etc. See below for a description of the messages the (simulated) server you are communicating with expects, including when you need to send acknowledgment or resend requests if you don’t receive a response.

  5. Show a TA your code or submit it to the submissoin site.

    • We expect everyone to finish ./netlab 1 and to make good progress on ./netlab 2
    • ./netlab 3 is quite a bit harder and is recommended if you have time
    • If you are submitting instead of checking off, we require ./netlab 1 and ./netlab 2 to be complete

1 Our Driver

We provide a network simulation driver program. It has the following pieces:

2 Protocol

Every message must have its first byte be a checksum. We’ll use a very simple checksum for this lab: the xor of all other bytes.

To send the array of bytes [0, 1, 2, 5] you actually send a five-byte message: [0^1^2^5, 0, 1, 2, 5].

You should send the server a 4-byte message (plus a checksum) to initiate conversation. The first three bytes should be the ASCII characters for GET; the fourth should be an ASCII digit 0 through 9. The server will then start sending you messages in discrete packets.

The first three bytes of each packet the server sends will be a checksum, a (1-based) sequence number, and the total sequence count. Both sequence number and sequence count will be encoded directly as a byte, not using ASCII.

If the server plans to send two packets, one containing [3, 1] and the other [4, 1, 5], they will actually arrive as [1^2^3^1, 1, 2, 3, 1] and [2^2^4^1^5, 2, 2, 4, 1, 5].

After receiving a message, you should reply with a four-byte message (plus a checksum). The first three bytes should be the ASCII characters for ACK; the fourth should be the sequence number you received. If a message is not delivered, you should reply with the ACK of the last message you got in order (or re-send the GET if the very first message is not delivered). However, messages may be delayed in transit and may arrive out of order. You should wait at least a few seconds before deciding a message will not arrive and re-sending its request.

Each GET will give a different message, and with a different level of errors you need to handle.

  1. sends the full message without errors
  2. sends the message without errors, one a packet at a time, requiring you to ACK properly
  3. sends messages unreliably; some messages never arrive and need to be re-requested
  4. sends messages unreliably; some messages arrive in a corrupted state and need to be re-requested

You may assume that if a message has not arrived after a full second, it will not arrive.

3 Tips