CS333 Lab A-6:
Alternating Bit Protocol

Goal of this lab:

Introduction:

Implementations of the message-passing model, such as TCP/IP, provide the programmer with an abstraction of a stream of data messages sent from process A to process B such that each message is delivered in the order sent. However, the physical communication between A and B is not necessarily completely reliable. Due to congestion in the network (other traffic), transient noise, buffer overflows, or other problems, some of the messages sent out over the network from process A may not actually arrive at process B, or they may arrive incomplete or corrupted (usually detected with a checksum).

Therefore, it is necessary to include in these message-passing implementations a protocol that ensures that when a message is lost, it is retransmitted by the sender. At the same time, the protocol must guarantee that duplicate messages are not delivered to the receiver and that the delivery order is consistent with the sending order.

In this lab, you will study the alternating bit protocol, a simple yet effective protocol for managing the retransmission of lost messages. Consider a sender A and a receiver B, and assume that the channel from A to B is initialized so that there are no messages in transit. The alternating bit protocol works as follows.

Convince yourself that this protocol works. Notice how duplicate messages and duplicate acknowledgments are ignored.

Directions:

Read over the entire assignment before starting.

  1. Lossy channel: In order to test your implementation of the alternating bit protocol, you will need to have a way to control the loss of messages between a sender and a receiver. Therefore, implement a Playground module that acts as a lossy channel. For simplicity, let's say that all messages are PGstrings, so each communication between sender and receiver will contain a protocol bit (0 or 1) and a string. Therefore, your "channel" module should publish an input tuple containing two fields, a PGbool and a PGstring, and it should publish an output tuple of the same type.

    The job of this module is to react to each input by randomly either (1) copying it to the output or (2) doing nothing. The fraction of the time it "does nothing" is the loss rate of the channel. Publish one additional variable from your channel so that you can externally control the message loss probability from EUPHORIA. Print out each message received by the channel and say whether or not the channel chose to drop the message. You may assume that the transmission or loss of each message is an independent event. Test your lossy channel before continuing.

  2. Sender: Implement the sender side of the alternating bit protocol as a Playground module. Like the channel, your sender module should publish an output tuple containing two fields, a PGbool and a PGstring. It should have a similar input, for acknowledgments. (The string part of each acknowledgment with just be "ACK".) Your sender should let you type in (or read from a file) a series of words to be sent, one at a time, as separate messages to the receiver. The messages will be sent using the alternating bit protocol. Note that you won't be able to fully test your sender until the receiver is in place, because the sender will get stuck waiting for an ACK to the first message.

  3. Receiver: Implement the receiver side of the alternating bit protocol as a Playground module. Like the channel, your sender module should publish an input tuple containing two fields, a PGbool and a PGstring. As each new message is received, print it out. However, you should not print out duplicates. Similarly, it should publish a tuple in which it will send back acknowledgments to the sender.

  4. Testing: Hook up your sender and receiver with two channels in the middle. One channel will go from A to B (for data). The other will go from B to A (for ACKs). Vary the loss rate of each channel, and make sure that your messages are delivered exactly once and in order. If you get your input from a file, you may find it convenient to use the UNIX command "diff" to verify that the sender and receiver are communicating correctly.

To receive credit for this lab, you should:

  1. Clean up and print out your code. (Don't turn it in, but save it for your code/design review.)

  2. Turn in a Project Evaluation Form near the beginning of class on the day you want to do your demonstration and code/design review. You should be prepared to demonstrate your working application, explain your design and code, and answer questions. Also, be prepared to explain why the protocol works.