I will supply a simple client and server, client.C and server.C.

The client simply sends a sequence of messages to the server until the user decides to quit. The server listens for incoming messages and displays them until the admin decides to quit.

The objectives for the lab are:

1. Establish a simple structure for all messages sent, modify the sender to put the message in the appropriate format, and modify the receiver to correctly decipher messages.

   • The first byte is 'R' if an acknowledgement is required, 'A' if the message *is* an acknowledgement message, or 'N' otherwise.

   • The next four bytes are the message id.
     For 'R' or 'N' messages these should start at 0 with the first message sent by a client/server and increase sequentially.
     For 'A' messages the id should be the id of the message being acknowledged.

   • For 'A' messages there is no text body, for other messages the remainder of the message is the actual text sent.

2. Establish a two-way communication sequence.

   If the client sends a message that requires acknowledgement they should immediately stop and listen for the ack.

   We'll have the client set up a socket for listening (since eventually they'll be listening for more than just acks), which means choosing a port number and ensuring the server knows which port to reply to.

   If the server receives a message that requires acknowledgement they should immediately send one.

   Note 1: this will involve adding sending code to the server and receiving code to the client.

   Note 2: because (so far) we are using blocking receives, if an 'R' or 'A' message is lost then communication between the two is deadlocked: the client is waiting for an acknowledgement that will never arrive. We'll address this problem in next week's lab.

   Note 3: because (so far) we are also using blocking keyboard input, the sequence of events is pretty constrained (alternating between getting a user command and then sending/receiving). Again, we'll address this in next week's lab.