m4n1c22 / os2_lab Goto Github PK

Check the last page of the document for more details.

Kindly verify if the requirements are met as per the document.

Implement a process-pair linking concept with an alternative approach.

• Utilize a method is_parent_alive() which returns a value 0 or 1. If parent has crashed it returns the value 0 else 1.
• Implementation of the above described method can be done by checking the PPID(Parent Process ID) of the given process.
• The child process will periodically verify it's PPID to check if it changes to init(process which has the PID as 1 in UNIX based systems). If it is init(PID=1), it means the original parent has crashed and the given process is assumed to acquire the role of orphan child.
• Request processing for child process can be done by printing some random values rand() method can be used in this regard. (Note: This step is handle the POC[Proof of Concept]. Therefore, it can later be modified with the implementation used in the task 2).

getppid() can be used in this regard.
For more info read the document

Given the issues 1 and 2 are meant to detect the parent process failures. There is no step taken to revive the child process to acquire the role of the parent. Implement such a functionality by child process acquiring the role of parent when parent process crashes. For testing purposes make the parent process not to wait for its child. Refer task3.1 in the document

Investigating and implementing task2.2.

I am not sure whether this is a problem. I have latest version, I created requests directory under task2 folder. I ran following commands without any additional option:

Terminal 1: make comp_client_task2_3
make client_exec_task2_3

Terminal 2: make comp_server_task2_3
make server_exec_task2_3

During execution I terminate client.Seems everything ok but at the end server gives floating point exception.

Another case without even running client, server runs and at the end again same exception happens.

Running and testing task1

• Check if all the requirements are met as per the document
• Try running the shell scripts task1_1.sh and task1_3.sh

Task 1 with out error

• Open a new terminal in the location where the source files and makefile for task 1 are located.
• Run make prog for compiling the source file task1.c
• Run make exec for running the task1.c
• Run make test which will run the shell script task1_1.sh and write the logs to a log file named overall.log

Task 1 with possible errors

• Open a new terminal in the location where the source files and makefile for task 1 are located.
• Run make prog_1_3 for compiling the source file task1_3.c
• Run make exec_1_3 for running the task1_3.c
• Run make test_task1_3 which will run the shell script task1_3.sh and write the logs to a log file named overall_1_3.log
• The script will also print the number of erroneous executions and successful executions dealt by the script.

Investigate the shell script for implementing it.

Execute and test task 2.1 and task 2.2
Testing Task 2.1:

• Run make clean first.
• Execute make comp_server_task_2_1 for compiling the task 2.1
• Run make server_exec_task_2_1 for running the task 2.1. You can also run the executable server_task_2_1.bin from terminal after compilation as: ./server_task_2_1.bin -n 10. -n is the option for specifying the maximum number of forks created. You can also avoid specifying this option which will create by default 5 child processes. Note: value of n ranges from 1-50

Testing Task 2.2:

• Open two terminal windows.
• Run make clean first.
• Execute make comp_server_task_2_2 for compiling the server code for task 2.2 in the first terminal window.
• Execute make comp_client_task_2_2 for compiling the client code for task 2.2 in the second terminal window.
• Run make server_exec_task_2_2 for running the task 2.2 server program. You can also run the executable server_task_2_2.bin from terminal after compilation as: ./server_task_2_2.bin -n 10. -n is the option for specifying the maximum number of forks created. You can also avoid specifying this option which will create by default 5 child processes. Note: value of n ranges from 1-50. And the fact that execution of the server code should be done from the first terminal window.
• You will notice server program waits for requests. Therefore, in the second terminal window execute make client_exec_task_2_2.
• The requests would be created by clients and stored in a folder named request. Server process will process the requests from the above mentioned folder and delete them as soon as it is processed.

Kindly test all the edge case and random case testing involved with the above execution style. If possible write a shell script which can automate them.

Implement a process-pair linking concept as discussed in the lecture using pipes.

• Utilize a method is_parent_alive() which returns a value 0 or 1. If parent has crashed it returns the value 0 else 1.
• Implementation of the above described method can be done using pipes. In which, the parent process uses the write end of the pipe and child process uses the read end of the pipe.
• Ensure to close the write end of the pipe for the child and read end of the pipe for parent.
• Parent should write periodically some value in the pipe and child process should read it periodically. The periodicity needs to be further investigated.
• Request processing for child process can be done by printing some random values rand() method can be used in this regard. (Note: This step is handle the POC[Proof of Concept]. Therefore, it can later be modified with the implementation used in the task 2).

You can use this link as an inspiration for your pipe implementation.
For more info read the document

Integrating the feature of having error probability of 0.5 or 50% in the program defined for parent-child relationship.

• Create a clone version of the task1.c file.
• Modify the cloned file with necessary changes as described by the task1.3
• For testing the code. Kindly make modification in the Makefile to suit the same.
• It would be better if there exist a new target to compile the source code for task1.3 and another target for executing it inside the existing Makefile.
• Utilize the variable child_exit_status defined in the task1.c file. You can verify the value of the child_exit_status with all the standard wait call errors and execution errors raised by the child process on the parent process.
• Create a new target named error_prog a clone of prog target inside Makefile. It will compile $(TASK_1_3_SRC) instead of $(TASK_1_SRC). You can define a new storage specifier named $(TASK_1_3_SRC) inside Makefile and assign with your task1_3 src file name.
• Similarly Create another target named error_exec a clone of exec target inside Makefile. It will have dependency on error_prog target and execute ./error_prog executable instead of ./prog.
• Create a cloned shell script task1_3_scr.sh with the same content from task1_1.sh. Invoke make error_exec instead of make exec in the script. Also write it to the log file error_overall.log instead of overall.log
• The created shell script is invoked via Makefile target. Therefore, create a target named test_error cloned target of test but will have dependency as error_prog instead of prog and execute task1_3_scr.sh instead of task1_1.sh. You can create a storage specifier named $(TASK1_3_SCR) = task1_3_scr.sh and use the same inside the Makefile.