![necessary structures. I recommend using one or more character arrays of fixed size as a structure
to hold the lines of text. Use the shared memory as a means of transmission, not storage. 2.
Sends the text file name and path to the server. I recommend using the shared memory you
created. 3. Copies the contents of the file, via shared memory, to local storage. I recommend
writing into an std::vector<std::string> using std::string(const char *, std::size t) and
std::vector::push back 4. Creates four threads, each of which; Process 14 of the lines of the
shared memory to Find any lines containing the search expression 5. The client uses the results of
the threads search to write all lines of text found to its STDOUT as follows: The client must begin
each line found with a count starting from 1 and must use a tab character (t) after the count, e.g., 1
t 7, 193100, 73200, 2.64, 38, professional, house, ftb, repay 2 t 9, 83000, 62500, 1.33, 30,
professional, house, ftb, repay 3 t 18, 162700, 77400, 2.10, 37, professional, house, ftb, repay
Note that the t should be an actual tab character. If the server was unable to open the file, writes
INVALID FILE to its STDERR (use std::cerr and std::endl from iostream if using C++). 6. Destroys
the shared memory location. 7. Terminates by returning 0 to indicate a nominative exit status
Cont. CSCE 311 Project 3: IPC Page 4 of 5 Notes Client Your client should create and destroy
your shared memory. See shm open and shm unlink below. If your client does not destroy the
shared memory, subsequent runs will fail and you will lose a substantial amount of points.
Consider the barrier problem for signalling the server from the client. A named POSIX semaphore
allows processes access to multi-process synchronization. You might hard-code the named
semaphore into your client or have your server pass its name with IPC. Your client likely will not
create or destroy named semaphores. It will connect to semaphores created by your server.
Server Your server should create and destroy any named semaphores used to synchronize the
server and client. Given that your server will be killed with CTRL + t, you will only be able to
destroy a named semaphore by setting up a signal handler using void (*signal(int sig, void
(*func)(int))(int) to destroy the semaphore. Your second option is to simply attempt to destroy any
semaphore before you create it.
NotethatyourexpectationisanerrorEINVAL(semisnotavalidsemaphore)ifthesemaphore does not
currently exist. THAT IS A GOOD THING, in this case. Continue past this error and initialize the
semaphore with the named used to destroy it. The start process for your server will like proceed
as follows: 1. Create any necessary semaphoresone of which should be the barrier 2. Do the
following forever: (a) Lock the barrier semaphore (b) Attempt to acquire the locked barrier
semaphoreeffectively blocking until the client unlocks it (c) Connect to the shared memory
initialized by the client (d) Use shared memory or any other IPC to get file name/path from client
(e) Transfer file via shared memory structure Shared memory structure You may store anything in
shared memory. For example you might store a structure as follows: Shared Memory Struct1 path
length : const static std::size t path : const char[path length] line length : const static std::size t line
: const char[line length] Assuming the client places the file path in the correct member before
raising the barrier blocking the server, the server may simply read the file path from the shared
memory. You should calculate the size of the path and line such that your struct is some number
of pages in memory. No matter what you request, you will get at least one page. PROVIDE CODE
IN C++ WITH HEADER/SOURCE FILES AND A FUNCTIOING MAKEFILE.](https://image.slidesharecdn.com/thisprojectexploresusageoftheipcintheformofshared-230321162724-25cbeb73/85/This-project-explores-usage-of-the-IPC-in-the-form-of-shared-pdf-2-320.jpg)
This project explores usage of the IPC in the form of shared.pdf
- 1. This project explores usage of the IPC in the form of shared memory. Your task is to create a client/server pair to process CSV files by loading the text file into shared memory, allowing a second program to parse that file for lines of text containing a matching string. You must create a client which uses the POSIX IPC method you choose to send a command-line pro- vided file name to the server. The server will load the contents of that file into shared memory. The client will use threads to search the shared memory for a command-line provided search string. The client will print each line found containing the substring to the standard output stream. If you would like to challenge yourself with this project, make the following changes: Use a structure in the server which allows it to signal the client as soon as it begins loading lines into memory (rather than after it finishes). A circular queue would be an ideal structure. The goal is to allow the server to write lines to the queues write while the threads read from the queues read pointer until one pointer catches the other. In the client, begin writing lines to the standard output stream as soon as the first one is found by a thread. This may be modeled as a producer/consumer where the search threads are producers and the STDOUT writer is the consumer. The producers will likely be much faster than the consumer, so use multiple slots each representing a line of text containing the search string (a circular queue of strings from the producer/consumer lecture would work). Because there is only one STDOUT, multiple consumers will not provide a speedup. CSCE 311 Project 3: IPC Page 2 of 5 Server The server is started without argument, i.e., ./csv-server If the server does not execute as indicated, the server and correctness portions will receive 0 points. The server is used to accept the file and search string information from the csv-client, open the file, and write the lines of the file to the shared memory. You may hard-code the name of the shared memory provided by the client. The server must perform as follows AND YOU MUST DOCUMENT IN YOUR CODE WHERE EACH STEPS 24 TAKE PLACE: 1. At start, writes "SERVER STARTED" to its STDLOG (use std::clog and std::endl from iostream if using C++). 2. Upon receiving a file name and path (relative to the project directory) from the client, (a) It writes CLIENT REQUEST RECEIVED to its STDLOG (use std::clog and std::endl from iostream if using C++). 3. Opens the shared memory. After it writes "tMEMORY OPEN" to its STDLOG 4. Using the path, Writes "tOPENING: " followed by the provided path name to the terminals STDLOG, e.g. "tOPENING: dat/dante.txt" Opens and reads the file Writes the contents of the file to the shared memory opened above Closes the file and writes "tFILE CLOSED" to the servers STDLOG. If open fails, indicate to the client using the IPC method of your choosing Closes the shared memory and writes "tMEMORY CLOSED" to the servers STDLOG stream. 5. The server need not exit Cont. CSCE 311 Project 3: IPC Page 3 of 5 Client The client should start with the command-line arguments./csv-client, followed by: 1. The name and path of the text file, relative to the root of the project directory which should be searched and 2. A boolean search string for which the each line of the file will be parsed: ./csv-client dat/bankloan1.csv prod + ind + paid If the client does not execute as described above, the client and behavior portions will receive 0 points. The client is used to pass the file name and path to the csv-server, search the lines of text transferred via shared memory, and count the number of lines of text found, while printing each line and its count to its standard output stream. You may hard-code the name of the shared memory provided by the client. The client must behave as follows AND YOU MUST DOCUMENT IN YOUR CODE WHERE EACH STEP TAKES PLACE: 1. Creates a shared memory location and initializes with any
- 2. necessary structures. I recommend using one or more character arrays of fixed size as a structure to hold the lines of text. Use the shared memory as a means of transmission, not storage. 2. Sends the text file name and path to the server. I recommend using the shared memory you created. 3. Copies the contents of the file, via shared memory, to local storage. I recommend writing into an std::vector<std::string> using std::string(const char *, std::size t) and std::vector::push back 4. Creates four threads, each of which; Process 14 of the lines of the shared memory to Find any lines containing the search expression 5. The client uses the results of the threads search to write all lines of text found to its STDOUT as follows: The client must begin each line found with a count starting from 1 and must use a tab character (t) after the count, e.g., 1 t 7, 193100, 73200, 2.64, 38, professional, house, ftb, repay 2 t 9, 83000, 62500, 1.33, 30, professional, house, ftb, repay 3 t 18, 162700, 77400, 2.10, 37, professional, house, ftb, repay Note that the t should be an actual tab character. If the server was unable to open the file, writes INVALID FILE to its STDERR (use std::cerr and std::endl from iostream if using C++). 6. Destroys the shared memory location. 7. Terminates by returning 0 to indicate a nominative exit status Cont. CSCE 311 Project 3: IPC Page 4 of 5 Notes Client Your client should create and destroy your shared memory. See shm open and shm unlink below. If your client does not destroy the shared memory, subsequent runs will fail and you will lose a substantial amount of points. Consider the barrier problem for signalling the server from the client. A named POSIX semaphore allows processes access to multi-process synchronization. You might hard-code the named semaphore into your client or have your server pass its name with IPC. Your client likely will not create or destroy named semaphores. It will connect to semaphores created by your server. Server Your server should create and destroy any named semaphores used to synchronize the server and client. Given that your server will be killed with CTRL + t, you will only be able to destroy a named semaphore by setting up a signal handler using void (*signal(int sig, void (*func)(int))(int) to destroy the semaphore. Your second option is to simply attempt to destroy any semaphore before you create it. NotethatyourexpectationisanerrorEINVAL(semisnotavalidsemaphore)ifthesemaphore does not currently exist. THAT IS A GOOD THING, in this case. Continue past this error and initialize the semaphore with the named used to destroy it. The start process for your server will like proceed as follows: 1. Create any necessary semaphoresone of which should be the barrier 2. Do the following forever: (a) Lock the barrier semaphore (b) Attempt to acquire the locked barrier semaphoreeffectively blocking until the client unlocks it (c) Connect to the shared memory initialized by the client (d) Use shared memory or any other IPC to get file name/path from client (e) Transfer file via shared memory structure Shared memory structure You may store anything in shared memory. For example you might store a structure as follows: Shared Memory Struct1 path length : const static std::size t path : const char[path length] line length : const static std::size t line : const char[line length] Assuming the client places the file path in the correct member before raising the barrier blocking the server, the server may simply read the file path from the shared memory. You should calculate the size of the path and line such that your struct is some number of pages in memory. No matter what you request, you will get at least one page. PROVIDE CODE IN C++ WITH HEADER/SOURCE FILES AND A FUNCTIOING MAKEFILE.