A7 - Unreliable Chat Client#

Run the server

# First, install the server (only required once)
~/.local/bin/uv pip install https://compnet2526.atlarge-research.com/pip/framework-0.2.0-py3-none-any.whl
# Second, run the server
unreliable-server

By default, the server will run in reliable mode, i.e., no bit flips, bursts, delays, or packet drops will occur. To enable unreliable features, experiment with the options below. A more detailed description of the unreliable features can be found in the Unreliability section.

usage: unreliable-server [-h] [-a ADDRESS] [-p PORT] [-s SEED] [-b BURST]
                         [-f FLIP] [-pb PROBABILITY] [-d DELAY]
                         [--scenario SCENARIO] [-v]

A UDP server that simulates unreliable network conditions for testing
purposes.

options:
  -h, --help            show this help message and exit
  -a ADDRESS, --address ADDRESS
                        Set server address
  -p PORT, --port PORT  Set server port
  -s SEED, --seed SEED  Set random seed for testing (default: random)
  -b BURST, --burst BURST
                        Set the length of bursts (in bits, default: 5)
  -f FLIP, --flip FLIP  Set the bit flip ratio (default: 0.005 as a percentage
                        of all bits)
  -pb PROBABILITY, --probability PROBABILITY
                        Set the probability that an unreliability event is
                        triggered (default: 0.1)
  -d DELAY, --delay DELAY
                        The maximum delay (in milliseconds) that can be
                        introduced by the unreliability (default: 1500)
  --scenario SCENARIO   Load a scenario
  -v, --verbose         Enable verbose logging

© 2026 Vrije Universiteit Amsterdam - @Large Research

Run the client (your implementation)

python3 -m a7_unreliable_chat

Assignment (650 points)#

Your task is to implement a replica of the Transmission Control Protocol as defined in RFC 9293 to tackle possible errors encountered on an unreliable network. TCP is a very large protocol, so you will only be implementing a small set of features required to ensure reliability on our toy example.

Even though we are using an unreliable server to connect our clients, consider it an abstraction of the unreliable network running under the transport layer. In reality, when sending messages from one client to another, you must consider the connection to be a peer-to-peer connection.

The possible errors that can occur over the network are described in the Unreliability section. To handle the possible errors, you will need to keep track of sequence and acknowledgment numbers for each connection, implement a checksum algorithm for error detection, a retransmission algorithm in case an error is detected, and periodic retransmission in case an acknowledgment is not received.

Protocol#

The unreliable chat client follows a protocol similar to the regular chat client, with the significant difference being that we are now working with a binary protocol rather than a text-based protocol.

The spaces present in the protocol message formats are present for readability purposes only. In the actual message, you will not receive any additional spaces. Additionally, it is not guaranteed that the message received is encoded in UTF-8 format. Thus, you are required to extract the given parameters from a bytearray (in binary format) before decoding. For example, the message 0x01 0x06 [name] could arrive at the server in the format:

# Equivalent of the A1 protocol: HELLO-FROM daniel\n
b'\x01\x00\x06daniel'

Every single packet (incoming our outgoing) will follow the following format:

• The first 1 byte represents the message type. This is equivalent to the header of chat client.
• The next 2 bytes represent the length of the payload len in big-endian.
• The next len bytes represent the packet payload.

Note that sending any messages to the server must follow the format above; the server will also respond with messages following the same format.

Client-side protocol#

The client-side protocol represents the set of messages sent by the client to the server. The client shall never expect any of the following messages to come from the server. Message parameters have been marked as [param]. Spaces are added between bytes and parameters for clarity. Please note that your implementation should not embed uneeded space characters.

Server-side protocol#

The server-side protocol represents the set of messages sent by the server to the client, as responses to requests made by the client. The client should only expect these kinds of messages to arrive and handle them properly. Message parameters have been marked as [param], matching the parameters from the client request.

Unreliability#

There are only four classes of unreliable interaction that can happen over the virtual peer-to-peer connection. Each one of them will occur at a probability \(p \in [0, 1)\), defined with the --probability option in the server.

Unreliability is only applied to the [message] parameter inside the [payload] of the DELIVERY packet. Thus, you do not need to worry about control packets such as 0x01 being scrambled.

The --seed option of the server allows you to easily reproduce runs using the same parameters in testing. Always keep track of the seed used when encountering an issue.

The automated testing environment will test your code with multiple seeds to ensure correctness, but also with deterministic errors.

Specification#

The following section contains the required features for the basic part of the assignment. All requirements, apart from Reliability, are identical to A1 - Chat Client; namely, your task is to replicate the reliable client over an unreliable network.

The requirements lightly model the TCP specification as prescribed in RFC 9293. You will not have to implement the entire TCP specification (such as the TCP state machine), but rather a subset of features required to provide reliability in our toy example.

Reliability#

The most significant set of requirements are those related to your program’s network reliability. The following specification defines the expected (consistent) behavior given the network unreliability simulated by the unreliable server.

1. The client must not make any assumptions about the binary protocol. It is possible that special bytes such as 0x00 are present in the payload of different messages.
2. The client must implement reliability features only for the 0x0A (DELIVERY) message type.
3. The client must be able to correct all types of errors by means of error detection + retransmission or error correction within 500 milliseconds of the original message arriving.
4. The client must implement sequence numbers and acknowledgment numbers in order to deal with possible missing packets, as prescribed by RFC 9293. Note that you may implement per-packet sequence numbers rather than per-byte.
5. Messages received on the client must be displayed in the order they were delivered by the sending client, rather than the order they arrived from the network.
6. The client must implement fragmentation. Packets sent over the network should not exceed 512 bytes in size. If a client desires to send a longer message, it must be split accordingly.
7. The bytes sent as part of a 0x0A (DELIVERY) message content must not exceed 35% overhead of the actual delivered message for the maximum packet length of 512 bytes.
8. The client must implement (part of) the TCP state machine to keep track of expected sequence and acknowledgment numbers. The client must synchronize with peers using the 3-way SYN, SYN-ACK, ACK handshake, and 2-way FIN/ACK closure.

Client#

The client requirements define the general functionality the program should implement. The technical details are covered in the Technical tab. Please note that your application must follow a strict textual interface, which is defined in the Interface tab.

1. The client must ask the user for a username and attempt to log them in.
2. The client must ask the user for a new username if the provided one is already in use, with an informative message.
3. The client must inform the user if the server is full and exit gracefully.
4. The client must inform the user if their username was rejected for any other reason and ask for a new username. The list of forbidden characters in the username is !@#$%^&*, and spaces.
5. The client must inform the user if their username was rejected for any other reason and ask for a new username. Examples include commands (@username, !who)
6. The client should not have to be restarted after a failed log-in attempt.
7. The client must be able to send messages to other authenticated users.
8. The client must be able to list all logged in users.
9. The client should only respond to messages received from the server. Specifically, the client should not store any state other than the connection’s socket.

Commands#

The client must support as user input several commands. The input must originate from stdin (standard input) and follow the specific format described below. Any input that does not match one of the formats must be ignored.

1. Typing the command !quit at any point must exit the client. No additional steps should be required to exit (e.g., Ctrl+C).
2. Typing the command !who must print a list of users.
3. An authenticated user should be able to send messages to other authanticated users by using the command @[username] [message], replacing the two parameters accordingly.

Technical#

We define several technical requirements serving as a qualitative standard for your implementation. We acknowledge that several implementations may work or be correct, however, to facilitate your learning process, we limit the accepted correct implementations to a subset solely making use of basic interfaces.

1. The client must use the UDP transport layer protocol for all network communication. For this, you will be using the Python socket interface. Using any other libraries for network communcations is not allowed.
2. The client must not use the sendall() or exit() Python functions.
3. The client must not print incomplete messages.
4. The client must support the sending and receiving of messages of any nonzero length.
5. Awaiting user keyboard input should not prevent newly incoming messages from being displayed.
6. Receiving any protocol header from the server at any point in the client’s lifetime must be handled appropriately.
7. Your implementation must not make any assumptions about the data received from the network. The only specification that should be followed is that of the provided protocol.
8. The client must inform the server about exit attempts, and maintain execution until the server responds with a LOGOUT packet.
9. The client must be able to recover conversations with a peer after they relogged and lost all TCP state.

Interface#

The application must print messages to stdout (standard output) and follow a strict format. Failing to meet the exact format described below will result in failing the automated testing.

Make sure to pay close attention to spaces, punctuation and commas. Some automated tests may fail if the messages do not include spaces that may be deemed redundant.

Bonus (200 points)#

The bonus assignment consists of two parts. Both parts must be completed to obtain the 200 points.

Part 1 - Piggybacking and Sliding Window Protocol#

Implement the sliding window protocol to allow for multiple messages to be in-flight at the same time, and piggyback acknowledgment numbers on outgoing messages. This will allow you to optimize the number of messages sent over the network, and thus reduce the impact of packet drops and delays.

To pass this part of the bonus, you must implement a sliding window protocol with a window size of at least 4, and piggyback acknowledgment numbers on outgoing messages. You must also implement a timeout mechanism to retransmit messages that have not been acknowledged within a certain time frame.

Part 2 - Max Overhead#

Using Hamming codes might increase the number of bytes you have to include to provide error correction. Your task is to optimize your protocol to utilize at most 10% overhead of the actual delivered message for the maximum packet length of 512 bytes.

It might be useful to consider smaller integer sizes, unsigned integer interpretation, and other binary tricks to reduce the number of bytes needed to provide error correction and detection. Clearly define your protocol’s header overhead before continuing with this task.