The Process Abstraction and Creating Processes

1. Objectives

By the end of this lab you will be able to:

1. Create a child process with fork() and tell parent from child by its return value.
2. Replace a child’s process image with execvp(), passing arguments the way the shell would.
3. Explain what a child inherits from its parent, and what it does not.
4. Observe process isolation directly, by printing the same variables from both processes.
5. Drive a client-server exchange: build a request, send it, and read the response.
6. Shut a system down cleanly, so that no process is left running and no parent waits forever.

Every lab this term builds on one project: a financial management system. This is where it starts. You write the client. The three servers are written for you.

2. Background

2.1 The client-server model

A client handles the user. A server owns a resource and answers requests about it. The client never touches the resource itself; it asks. That buys two things: the resource lives in one place, and each server can be understood, changed, and crashed on its own.

This lab has one client and three servers, each owning a different resource.

Notice what each server owns. The logging server’s file survives the run; the finance server’s accounts do not, because they live in that process’s memory and die with it. That difference is the whole reason the log file exists.

2.2 Requests and responses

Both types are in common.h. A request carries everything a server might need; most fields go unused for any given request type.

struct Request {
    RequestType type;      // QUIT, DEPOSIT, WITHDRAW, BALANCE,
                           // UPLOAD_FILE, DOWNLOAD_FILE, LOGIN, LOGOUT
    int         user_id;
    double      amount;
    std::string filename;
    std::string data;

    Request(RequestType t, int uid = 0, double amt = 0.0,
            std::string fname = "", std::string d = "");
};

Only type is required; the rest default. So a quit is just Request(QUIT), and a balance enquiry is Request(BALANCE, user_id).

A response comes back with four fields, and again only some are filled:

struct Response {
    bool        success;   // did the server do what was asked?
    double      balance;   // finance server only
    std::string data;      // file contents, on a download
    std::string message;   // short explanation, useful when success is false
};

2.3 fork() and execvp()

fork() is called once and returns twice, because after it there are two processes. The return value is the only thing that differs, and it is how each process learns which one it is:

pid_t pid = fork();
if (pid < 0)  { /* fork failed  */ }
if (pid == 0) { /* the child    */ }
if (pid > 0)  { /* the parent   */ }

The child is a copy: same code, same variables, same next line to execute. What it is not is the same memory. Change a variable in the child and the parent’s copy does not move. Task 2 has you prove that to yourself.

execvp() then throws that copy away and loads a different program into the process:

char* args[] = {(char*)"./program", (char*)"arg1", (char*)"arg2", nullptr};
execvp(args[0], args);
perror("execvp");   // only reached if execvp FAILED
exit(1);

Two things to hold on to. The array must end with nullptr, and args[0] is by convention the program’s own name. And a successful execvp never returns — there is no longer any code to return to. So any line after it runs only on failure, which is exactly why the two lines above are there.

2.4 The RequestChannel

channel.h gives you the whole interface you need:

RequestChannel(const std::string process_name, const Side side);
Response send_request(const Request& req);

A channel is identified by its name. The client and the server must construct it with the same string, or they are not talking to each other. The names the servers use are in their source: "finance", "file", "logging". Note the file server’s channel is called "file" even though its executable is ./fileserver.

Each name must be opened exactly once from each side — one CLIENT_SIDE, one SERVER_SIDE. Opening the same side twice is undefined behaviour.

You only ever call send_request. receive_request and send_response are the servers’ half of the conversation, and they are already written.

3. Environment setup

3.1 Accept the assignment

1. Sign in to classroom50.org with your GitHub account.
2. Accept Lab 2: https://classroom50.org/CSCE-313-FA26/csce-313-fa26/assignments/lab-2/accept. Your repository is created for you.
3. Clone it:

git clone https://github.com/CSCE-313-FA26/<your-lab-2-repository>.git
cd <your-lab-2-repository>

3.2 Install clang

The RequestChannel implementation ships as LLVM IR, which clang assembles:

sudo apt update
sudo apt install clang

You do not need clang for anything else in this lab, and you never edit the IR.

3.3 Repository layout

3.4 Build

make

That produces four executables: client, finance, fileserver, logging.

Note the file server’s executable is fileserver, not file — file is already a standard Unix command. Its channel, however, is named "file". The two are different things and both spellings are correct in their own place.

3.5 Running the servers by hand

The finished client starts the servers itself. While you are still building it, you can run each one in its own terminal and drive it from a fourth:

./finance -m 1000            # accounts 0 through 1000
./logging -f system.log      # log to system.log
./fileserver .txt .h         # allow uploads of .txt and .h only
./client

This is a debugging aid, not the deliverable. The autograder fails every test if the client does not start the servers itself, so implement Task 1 first.

4. Walkthrough

You do not have to read the servers line by line, but you do have to know which fields each one reads out of your request. These three diagrams are that summary.

4.1 The finance server

Started as ./finance -m <max_account_num>. Accounts 0 through max_account_num inclusive are valid; anything else is refused. Accounts are created on first use with a balance of zero.

resp.balance is set on all three successful operations, so you can print the new balance straight from the response without asking again.

4.2 The file server

Started as ./fileserver <ext_1> ... <ext_n>. It owns the storage/ directory.

4.3 The logging server

Started as ./logging -f <log_filename>. It appends one line per request, and the file survives between runs.

Which field the log line uses depends on the request type, and getting this wrong is the most common way to lose points on Task 3:

4.4 The session you are aiming at

storage/example_execution.txt is a complete correct run, and storage/example.log is the log it produced:

[1]: logged in
[1]: deposited 500
[1]: withdrew 200
[1]: viewed balance: 300
[1]: uploaded file: channel.h
[1]: downloaded file: example.log
[1]: logged out

Reproduce that log exactly and Task 3’s logging half is done.

5. To-do

Everything you write goes in client.cpp, at the TODO comments. Do the tasks in this order: nothing else can be tested until Task 1 works.

5.1 Task 1 — Run the servers as child processes (45 points)

Start finance, logging and fileserver as children of the client, so that running ./client in one terminal brings the whole system up.

For each of the three, at its TODO:

1. fork(), and check for failure.
2. In the child only, run the block already written there — it changes the three variables and calls print_process_info — and then execvp the server.
3. The parent does nothing here and carries on to start the next server.

The command lines are:

./finance   -m <max_account>
./logging   -f <log_file_name>
./fileserver <extension1> <extension2> ...

The file server’s argument count is not known until run time, so build its argv on the heap. Every array must end with nullptr.

5.2 Task 2 — Print process details (15 points)

Fill in print_process_info so each line carries a real value:

Parent process before fork:
PID: 48120
PPID: 3310
Global variable address: 0x5b1f0a2c4010 value: 100
Stack variable address: 0x7ffd41b2ec44 value: 200
Heap variable address: 0x5b1f0b3d52c0 value: 300
----------------------------------------

Use getpid() and getppid(). Print the address and then the value for each of the global, stack and heap variables. Do not change the label strings or the line order — the tests read these files by line.

This is the part of the lab that shows you the process abstraction directly. Each child bumps the three variables by a different amount before exec, so afterwards compare parent_attributes.txt against the three child files:

• Every child’s PPID is the parent’s PID. They really are its children.
• Every child’s values differ from the parent’s, and from each other’s.
• Every child’s addresses are the same as the parent’s, or nearly so.

That last one is the point worth sitting with. Two processes report the same address holding different values, because the address is virtual: each process has its own mapping from those numbers to physical memory. Nothing is shared, and nothing needed to be copied until it was written to.

5.3 Task 3 — Client-server communication (30 points)

Create the three channels after the servers are running:

RequestChannel finance("finance", RequestChannel::CLIENT_SIDE);
RequestChannel file("file",       RequestChannel::CLIENT_SIDE);
RequestChannel logging("logging", RequestChannel::CLIENT_SIDE);

Then fill in each menu action. Save every reply into the resp variable the starter already tests, and use send_request for all of them.

Every action that succeeds is logged, and only after it succeeded — the audit line goes inside the if (resp.success) branch that is already written for you.

Read every response. A request whose reply you never read leaves the channel out of step, and the next reply you read will be the wrong one.

5.4 Task 4 — Close the channels (10 points)

Before the client returns, send Request(QUIT) down all three channels.

The client’s last act is while (wait(NULL) > 0);, which returns only once every child has exited — and a server exits only when it receives QUIT. So a client that misses even one QUIT does not crash or complain. It hangs, forever, with no output. If your program stops responding at exit, this is why.

5.5 Test your work

make test

That runs lab2-tests.sh, which is the same set of checks the autograder runs, out of 100. Run it before you push; it is much faster than waiting for the grader.

If the script reports a hang, run the client by hand and compare against storage/example_execution.txt.

6. Deliverables

Commit and push your work to your assignment repository:

git add client.cpp
git commit -m "lab 2"
git push

That is the whole submission. The programs’ output files — *_attributes.txt, your log file, and anything uploaded into storage/ — are produced when the grader runs your code, and are deliberately ignored by .gitignore. Do not commit them, and do not commit the built executables.

The autograder runs on every push, so you can push as often as you like and read the result.

6.1 Mistakes that cost points

7. Getting help

Ask on Discord. Bring the exact command you ran and the exact output, not a description of it. The Canvas inbox is not monitored.

Office hours and TA contact details are in the syllabus.

Revision history