CSc 3320: System Level Programming, homework 2

CSc 3320: System Level Programming, homework 5

As you are aware, we have lab assignments due every week. We also will have several homework assignments this semester, and this is one of those. While the labs are directed, the homework assignments present larger problems that you should break down into smaller problems. You should spend some time thinking about and planning your homework solutions before coding them.

Program Description

Purpose:
This assignment will help you conceptualize, utilize, and implement inter-process communication (IPC). Understanding how a program can be forked into multiple processes, and how those processes can communicate with each other, form a cornerstone of system-level programming.

Getting Started
Page 503 in your Unix book begins a section on pipes. Refer to the "talk.c" program on page 505. You should try it out yourself, then use it as a template to build your solution.

Task:
Create a program that sets up three processes. Two of the processes will play the Iterated Prisoner's Dilemma (a "tournament"). The other process, the parent, will coordinate the tournament, like a referee. Upon start-up, the parent will:

Start both scores at 0
Tell the players to get ready
Check that each player responded

Next, the parent will:

Tell the players to play a round
Get the choice from each player
Determine the winner of the round
Report (i.e. output) the players' choices, and the scores for that round
Communicate the score for that round back to each player. Note that player 1 might get a different score for that round than player 2.
Keep track of the scores, adding points as needed
Repeat for the specified number of rounds

Finally, the parent will:

Tell the players to quit, when the rounds are over
Wait for the players to quit
Report the final scores

Communication is done with pipes. Thus, "Tell the players" means writing a message on the pipe to player 1, and writing a message on the pipe to player 2. "Get the choice from each player" means reading the pipe from player 1 and reading the pipe from player 2.

Remember to break the problem down into smaller tasks, and work on the tasks one by one.

The Iterated Prisoner's Dilemma

The Prisoner's Dilemma is a classic game-theory model for interactions. In it, two players must choose between cooperate (with each other) and defect (against the other). Since the choice is simultaneous, each one does not know what the other will choose.

The following table shows a typical pay-off matrix. The pay-offs, or scores, are what each player gets at the end of the round. For example, if player 1 cooperates and player 2 defects, player 1 scores 0 while player 2 scores 5.

	Player 2 Cooperates	Player 2 Defects
Player 1 Cooperates	3/3	0/5
Player 1 Defects	5/0	1/1

You could have a single round of the Prisoner's Dilemma, however, the "Iterated" version means that the two players will play for several rounds. The scores will accumulate over the course of the rounds.

IPC

Create a program that forks twice. The two child processes will communicate with the parent process via pipes. Each child process needs 2 pipes, one to send data to the parent, and the other to receive data from the parent. Thus, your program will need to implement a minimum of 4 pipes. The child processes will play the Iterated Prisoner's Dilemma, with the parent process coordinating the tournament, and keeping track of the scores. Each message will be a single character.

The parent will send one of the following to the child processes.

Char	Meaning	Result
R	get Ready	Child process replies with Y
P	Play	Child process replies with move (C or D)
Q	Quit	Child process exits
0	Zero	The child process scored 0 that round
1	One	The child process scored 1 that round
3	Three	The child process scored 3 that round
5	Five	The child process scored 5 that round

The parent process should "wait()" for each child to exit before returning (or exiting) itself.

Each player sends "Y" to indicate that it is ready, only after receiving "R". Each player sends either "C" or "D", to cooperate or defect, only after receiving "P". Each player will receive "0", "1", "3", or "5" shortly after sending its cooperate/defect choice. This allows the player to know the result, and indirectly, what the other player chose. Each player should quit when it receives "Q". It does not send anything back to the player at that point.

How should the players decide what move to make? You can determine this. Your players could base their next moves on the score(s) from the last round(s), or they could ignore the score. (They are required to read it, however.) See strategies for a list of strategies that you can use.
According to your first and last name, implement the strategies below.
Name starts with, strategy to implement for one side
A-D, Unconditional Cooperator
E-K, Unconditional Defector
L-O, Random
P-R, Probability p Cooperator
S-T, Tit for Tat
U-Y, Tit for Two Tats
Z, One of the others on the list

i.e. a student named David Smith should implement Unconditional Cooperator for one player, and Tit for Tat for the other.

Running Your Program

When running your program, the user might pass "-h" as a command-line argument. If so, your program should print a "help" message about what the program does, and quit. It does not matter which argument is "-h"; if it is there, your program should print a "help" message about what the program does, and quit.

When running your program, the user might pass a number as a command-line argument. If so, your program should use that as the number of iterations. You should use "strtoimax" to convert the number from a string.

Any unusual command-line argument should be noted. Your program should indicate that the argument does not make sense and repeat the argument back, (i.e. "Argument "YOLO" does not make sense") print a "help" message about what the program does, and quit.

Criteria:
The ultimate goal is to have a program that solves the problem. Each task should have a test associated with it, to verify that it works. When all tasks have working solutions, they should all work together to solve the problem. Keep in mind that we will check to see what tasks are completed, and if your program does not solve the problem, it will still receive partial credit.

Use pipes for communication. Each process should close the end(s) of any pipe that it does not need.
Use fork and wait commands, as needed.
INPUT: The user will not provide any input beyond the command-line arguments.
OUTPUT: Output from the parent process about each round, such as "Round 5: player 1 D, player 2 C. Player 1 scores 5, player 2 scores 0."

At the end of the tournament, display the total score for each player. Also display the average score for each player, and report it with at least 2 digits after the decimal.
DEBUG OUTPUT: Define a DEBUG value. When it is true, have each process output much more information. First, each process will need to identify itself, such as "parent:", "child1:", or "child2:". It should state what it is doing, such as "waiting", "writing C to the pipe", "reading from the pipe", "choosing move to make", etc.
You will need to turn in a log file showing your program (i.e. with cat). Show that it works for several test cases. Don't forget to send any other files, like your .C file(s).
You may be asked to meet with your TA to demonstrate your solution.
You should have a return type of "int", and return 0 at the end of the main function.
As you are aware certain types of assistance are inappropriate in this class. Read the collaboration policy given to you at the beginning of the semester, if you have any questions.
Any code that you did not write yourself must be thoroughly documented.
Code documentation.
In any language, good documentation is very important. You can add comments at the end of a line, or above a line. Your program should include comments within the code, not just at the top. These comments will explain what your program is doing. You should have good comments, informative function/variable names, and consistent indentation.
Turn this in following the instructions for labs/homeworks.