In C programming please. CSCI 4534 Operating Systems Programming Assignment #2 Date Due: Monday, Mar 13th, 2023 @ 11:59pm submitted to Blackboard This assignment is meant to: 1. Introduce students to writing basic client/server programs in C using the UNIX/Linux platform 2. Provide an opportunity to write code that will become the base for projects similar to that of a simulated operating system component 3. Extend the server to be able to handle requests from multiple clients simultaneously. Objective: Create programs that run independently and can perform simple IPC using FIFOs/named pipes to pass information back and forth in a client/server fashion. This assignment requires the analysis, implementation, testing and documentation of two small programs written in C on the UHCL Linux server ruby or your own Linux box or virtual machine. A server program and a client program that will be run concurrently. Server program: There is no change in the functionality of the server program (as far as the convert&store) other than: 1. Make the server keep a simulated processID counter initialized to 1, increment and return the simulated processID value to each client that initiates a connection with the server. (Clients will need to save their simulated PID to include with each simulated system call made and sent to the server afterwards). 2. Save the file descriptors for the return fifo for each client in an array/list so that when a request comes in from client X, a proper reply is sent to client X through its own return fifo. The server program will provide a simple convert&store service to clients that connect with it and send it requests. Server program will be an iterative server (can process ONLY one client at a time) and it needs to do the following: Create a well-known receive FIFOs where it will read its input/requests from the client and open it in READ mode (will block of course until a client opens the same fifo in write mode). Then go into an infinite loop to read requests from the clients, each request will be a simulated system call, each request/system call should include: 1. Process ID of process sending/making the system call 2. System call number (integer or byte) 3. Number n of parameters in the system call (integer or byte) 4. Size of the rest of the message that includes 5. Actual value(s) for the n parameters indicated in 3 As described below: System Call 1 would be the first request sent by a new client (connect system call) 1. Process ID 2. System Call Number = 1 3. Number n of parameters = 1 4. Size of 5 5. Actual value(s) for the 1 parameter = the name of the clients specific FIFO which the server should use to reply to that client. Server should open that client-specific FIFO in WRITE mode, save the file descriptor and the pid of the client for use when replies need to be sent to that client. 6. No need to return anything. Increment the processID counter and return the next available simulated ClientID/processID System Cal.

1. In C programming please. CSCI 4534 Operating Systems Programming Assignment #2 Date Due:
Monday, Mar 13th, 2023 @ 11:59pm submitted to Blackboard This assignment is meant to: 1.
Introduce students to writing basic client/server programs in C using the UNIX/Linux platform 2.
Provide an opportunity to write code that will become the base for projects similar to that of a
simulated operating system component 3. Extend the server to be able to handle requests from
multiple clients simultaneously. Objective: Create programs that run independently and can
perform simple IPC using FIFOs/named pipes to pass information back and forth in a client/server
fashion. This assignment requires the analysis, implementation, testing and documentation of two
small programs written in C on the UHCL Linux server ruby or your own Linux box or virtual
machine. A server program and a client program that will be run concurrently. Server program:
There is no change in the functionality of the server program (as far as the convert&store) other
than: 1. Make the server keep a simulated processID counter initialized to 1, increment and return
the simulated processID value to each client that initiates a connection with the server. (Clients will
need to save their simulated PID to include with each simulated system call made and sent to the
server afterwards). 2. Save the file descriptors for the return fifo for each client in an array/list so
that when a request comes in from client X, a proper reply is sent to client X through its own return
fifo. The server program will provide a simple convert&store service to clients that connect with it
and send it requests. Server program will be an iterative server (can process ONLY one client at a
time) and it needs to do the following: Create a well-known receive FIFOs where it will read its
input/requests from the client and open it in READ mode (will block of course until a client opens
the same fifo in write mode). Then go into an infinite loop to read requests from the clients, each
request will be a simulated system call, each request/system call should include: 1. Process ID of
process sending/making the system call 2. System call number (integer or byte) 3. Number n of
parameters in the system call (integer or byte) 4. Size of the rest of the message that includes 5.
Actual value(s) for the n parameters indicated in 3 As described below: System Call 1 would be
the first request sent by a new client (connect system call) 1. Process ID 2. System Call Number =
1 3. Number n of parameters = 1 4. Size of 5 5. Actual value(s) for the 1 parameter = the name of
the clients specific FIFO which the server should use to reply to that client. Server should open
that client-specific FIFO in WRITE mode, save the file descriptor and the pid of the client for use
when replies need to be sent to that client. 6. No need to return anything. Increment the processID
counter and return the next available simulated ClientID/processID System Call 2 Number to text
1. Process ID 2. System Call Number = 2 3. Number n of parameters = 1 4. Size of parameter (4
bytes for integer) 5. Actual value(s) for the parameter 6. Return the number converted to text ( 0 ->
zero, 1 -> one, 2 -> two, 3 -> three, etc. assume number will be between 0 and 9) System Call 3
Text to number 1. Process ID 2. System Call Number = 3 3. Number n of parameters = 1 4. Size
of parameter 5. Actual value(s) for the 1 parameter (zero, one, two, three, etc.) 6. Return the
number (four -> 4, five -> 5, etc) System Call 4 Store 1. Process ID 2. System Call Number = 4 3.
Number n of parameters = 1 7. Size of parameter 4. Actual value(s) for the 1 parameter 5. Return
stored value System Call 5 Recall 6. Process ID 7. System Call Number = 5 8. Number n of
parameters = 0 9. Actual value(s) for the 1 parameter = N/A 10. Return stored/recalled value
System Call 0 Exit o Process ID o System Call Number = 0 o Number n of parameters = 0 o
Actual value(s) for the parameter = N/A o Return value N/A System Call -1 Terminate o Process

2. ID o System Call Number = -1 o Number n of parameters = 0 o Actual value(s) for the parameter =
N/A o Return value N/A Server must print to the screen a message indicating the system call
received, something like: Client pid: 1 System Call Requested: 3 with 2 parameters which are:
Param1=xxxx param2=YYYY result=XXXX Server must reply back to the client through the client
specific fifo with a reply message that should include a result as appropriate. If the request is the
system call 0 EXIT, the server program must close the client specific fifo and continue to receive
the next system call (ready for the next client to connect) When the last client terminates, i.e.
sends system call -1, the server should close the well known FIFO, delete it and terminate as well.
Client Program: The client program will connect to the server through the well-known FIFO and
send requests through it to the server, obtaining information from the user as to what system call
to make and the corresponding values for the parameter(s), more specifically, the client program
should: The server will now return the ClientID/processID upon successful connection. This ID will
need to be saved and included with all future system calls. Acquire from the user (through the
command line or reading from the keyboard) what the client number this instance of the program
will be (i.e., client 1, client 2, etc.) or use the actual processid if you prefer. Open the well-known
servers fifo in write mode to communicate with the server (which will unblock the server from its
fifo open call) Create the client-specific FIFO using an appropriate name (e.g., ./ClientNfifo, where
N is the client number and send the initial connect system call to the server including Client
number and name of the client-specific FIFO. Open the client-specific FIFO in READ mode to be
able to read replies from the server. (This will block the client until the server opens the client-
specific FIFO in write mode). After this, the client should go into a loop where the client will ask
the user what to do next? providing three choices: o 1 Send request to server, in this case it will
ask the user for data: What sytem call? How many parameters? (user enters 0, 1, 2, 3, etc.) For
each of the n parameters indicated above, Read a value Take all the information gathered,
appropriately format a system call request and send it to the server. Request should include:
Process ID System call number (integer or byte) Number n of parameters in the system call
(integer or byte) Size of the parameter(s) data Actual value(s) for the n parameter(s) indicated
above After sending the request to the server, read the reply from the server in the client-specific
FIFO and write it to the screen. o 2 EXIT - indicates THIS client does not want to issue more
requests to the server, it should send a EXIT system call to the server, close its client specific
FIFO, delete it and exit. o 3 TERMINATE - indicates THIS client does not want to issue more
requests to the server, and is flagging the server to also exit. it should send a TERMINATE system
call to the server, close its client specific FIFO, delete it and exit. The first step in writing a
client/server application is define the communications protocol between both applications. In other
words, how are you going to encode the requests and replies into a message, you can encode
data in string forms, separating each piece with a , - a space, a new line character, or any other
kind of separator, you can use integer data, strucs, etc. Create a zip file with both your programs
source file(s) and executables, do a screen recording showing your programs working (with
multiple clients running one after the other and interacting with the server) and upload to
blackboard. Alternatively, just upload a zip file of your source files and executables and visit with
the TA during his office hours so you can do a demo of your client/server system. Make
incremental progress as you develop your code and back up your files often!! For instance (each

3. version expands on capabilities of previous one): Version 1: server creates and opens receiving
fifo, client opens servers fifo and creates its own input fifo and sends its name to the server which
display it on screen Version 2: server opens clients fifo, client sends a dummy system call to
servers receive fifo, server echoes data on clients fifo. Version 3: client reads input from user to
form requests and displays the formatted request on screen Version 4: client sends request to
server and server displays it on screen Version 5: server interprets request and creates and
returns result to client, client displays reply on screen Version 6: Final version with all features.