Objective: Expand on the implementation of the server program to make it look more like an OS receiving system calls fro
Posted: Sun Jul 10, 2022 11:25 am
Objective: Expand on the implementation of the server program tomake it look more like an OS receiving system calls from multipleuser processes (clients) and implementing some simple APIfunctionality.
Modify the Server program as follows:Allow the server to receive “connect” requests (as described inProgram 1, from multiple clients. All clients will talk to theserver through the same “well-known” fifo that the server creates.Eachclient will create and communicate the name of its private fifothat the server will use to reply to each client as in Program1.The server program should keep a simulated processID counterinitialized to 1, increment and return the simulated processIDvalue to each client that initiates a connection with theserver.(Clients will need to save their simulated PID to include with eachsimulated “system call” made and sent to the serverafterwards).When the server receives a QUIT/EXIT system call (the client isgoing away), the server should remove the entry for that clientfrom its list/array and close the client’s fifo, and make theentryavailable for future use by new clients. The QUIT/EXIT system callshould include an exit status that should be passed to anotherprocess that may be waiting for this client to exit (via thewaitPID system call as described below. When the server receivesany other system call, it should identify the client sending it(with thesimulated processID included in the system call, find that clientin its list/array and respond to that client like in program1(where you echoed the system call).Simple API functionality:Server should also be able to receive the following two systemcalls from clients:a) waitPID(pid) system call, server should not return any messageuntil the specified process(simulated process id) issues a QUIT/EXIT system call, at thatpoint it should send amessage to the process that sent the waitPID(pid) call (in additionto process theQUIT/EXIT system call of course).b) createmessagequeue(msgqname) system call – system should createa message queue wheremessages can be dropped by the client and retrieved by otherclientsc) sendmessage(msgqname, message) system call, the server shouldsave the message in thecorresponding message queued) retrievemessage(msgqname) system call, the server should retrivethe oldest message inthe message queue and return it, if no messages are available inthe message queue, itshould return a failure value.All system call should have a successful or failure return (-1)value.Make appropriate minor modifications to the Client Program:
The client program should be able to send system calls like inprogram 1, except that in the reply to the first request, theclient will receive a reply that will include a simulated processIDfrom theserver. The client should save this simulated processID and includeit with every future system calls sent to the server, so the serverknows which client the system call is coming from and isable to reply to that particular client through its correspondingpipe. Include code in the client menu to be able to send the system callsa) through d) as described in theserver program.Report success or failure return from the server and returned dataas appropriate.
---------------------------------------------------------------------------------------------------------------------------------------
(Previous Question for reference )
Objective: Create programs that run independently and canperform simple IPC using FIFOs/named pipes to pass information backand forth in a client/server fashion.This assignment requires the analysis, implementation, testing anddocumentation of two small program written in C on the UHCL Linuxserver ruby or your own Linux box or virtual machine. A serverprogram and a client program that will be run concurrently.
Server program:The server program will provide a simple “echo” service to clientsthat connect with it and send it requests.Server program will be an iterative server (can process ONLY oneclient at a time) and it needs to do the following:Create a well-known receive FIFOs where it will read itsinputs/requests from the client and open it in READ mode (willblock of course until a client opens the fifo in writemode).Then go into an infinite loop to read requests from the clients,each request will be a “simulated system call”, each request/systemcall should include:o System call number (integer or byte)o Process ID of process sending/making the system callo Number “n” of parameters in the system call (integer orbyte)o Actual value(s) for the “n” parameters indicated above System Call 1 – would be the first request sent by a newclient (“connect system call”)and it should include 2 parameter which would be 1 - a simulatedprocess id (or real)and 2 - the name of the client’s specific FIFO which the servershould use to reply to thatclient. Server should open that client-specific FIFO in WRITE mode,save the filedescriptor and the pid of the client for use when replies need tobe sent to that client. Server must print to the screen a message indicating the“system call received”,something like:
Client pid: 1System Call Requested: 10 with 3 parameters which are:Param1=xxxx param2=YYYY param 3=zzzz
Server must reply back to the client through the client specificfifo with a reply message that should just echo (for now) thesystem call number received, number of parametersand values of parameters received (just echo the request)
If the request is the system call 2 “EXIT”, the server programmust close the client specific fifo and continue to receive thenext system call When the last client terminates, the server should close thewell known FIFO, delete it and terminate as well.Client Program:The client program will “connect” to the server through thewell-known FIFO and send requests through it to the server,obtaining information from the user as to what “system call tomake” and the corresponding values for the parameters, morespecifically, the client program should: Acquire from the user (through the command line or readingfrom the keyboard) what the client number this instance of theprogram will be (i.e., client 1, client 2, etc.) or usethe processid if you prefer
Open the well-known server’s fifo in write mode to communicatewith the server (which will unblock the server from its fifo opencall)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 includingClient number and name of the client-specific FIFO.Open the client-specific FIFO in READ mode to be able to readreplies from the server.(This will block the client until the server opens the fifo inwrite mode). After this, the client should go into a loop where the clientwill ask the user what to donext? providing two choices:o 1 – Send request to server, in this case it will ask the user fordata: What sytem call? (maybe provide choices that include “quit”,“read”,“write”, “open”, etc. (4 or more choices) 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 shouldinclude: System call number (integer or byte) Number “n” of parameters in the system call (integer orbyte) Actual value(s) for the “n” parameters indicated aboveAfter sending the request to the server, read the reply from theserver in theclient-specific FIFO and write it to the screen.o 2 – QUIT - indicates THIS client does not want to issue morerequests to theserver, it should send a “EXIT” system call to the server, closeits fifos, delete theclient specific FIFO and exit.
The first step in writing a client/server application is definethe communications protocolbetween both applications. In other words, how are you going toencode the requests andreplies into a message, you can encode data in string forms, youcan use integer data,separating each piece with a “,” “-“ a space, a new line character,or any other kind ofseparator.
Modify the Server program as follows:Allow the server to receive “connect” requests (as described inProgram 1, from multiple clients. All clients will talk to theserver through the same “well-known” fifo that the server creates.Eachclient will create and communicate the name of its private fifothat the server will use to reply to each client as in Program1.The server program should keep a simulated processID counterinitialized to 1, increment and return the simulated processIDvalue to each client that initiates a connection with theserver.(Clients will need to save their simulated PID to include with eachsimulated “system call” made and sent to the serverafterwards).When the server receives a QUIT/EXIT system call (the client isgoing away), the server should remove the entry for that clientfrom its list/array and close the client’s fifo, and make theentryavailable for future use by new clients. The QUIT/EXIT system callshould include an exit status that should be passed to anotherprocess that may be waiting for this client to exit (via thewaitPID system call as described below. When the server receivesany other system call, it should identify the client sending it(with thesimulated processID included in the system call, find that clientin its list/array and respond to that client like in program1(where you echoed the system call).Simple API functionality:Server should also be able to receive the following two systemcalls from clients:a) waitPID(pid) system call, server should not return any messageuntil the specified process(simulated process id) issues a QUIT/EXIT system call, at thatpoint it should send amessage to the process that sent the waitPID(pid) call (in additionto process theQUIT/EXIT system call of course).b) createmessagequeue(msgqname) system call – system should createa message queue wheremessages can be dropped by the client and retrieved by otherclientsc) sendmessage(msgqname, message) system call, the server shouldsave the message in thecorresponding message queued) retrievemessage(msgqname) system call, the server should retrivethe oldest message inthe message queue and return it, if no messages are available inthe message queue, itshould return a failure value.All system call should have a successful or failure return (-1)value.Make appropriate minor modifications to the Client Program:
The client program should be able to send system calls like inprogram 1, except that in the reply to the first request, theclient will receive a reply that will include a simulated processIDfrom theserver. The client should save this simulated processID and includeit with every future system calls sent to the server, so the serverknows which client the system call is coming from and isable to reply to that particular client through its correspondingpipe. Include code in the client menu to be able to send the system callsa) through d) as described in theserver program.Report success or failure return from the server and returned dataas appropriate.
---------------------------------------------------------------------------------------------------------------------------------------
(Previous Question for reference )
Objective: Create programs that run independently and canperform simple IPC using FIFOs/named pipes to pass information backand forth in a client/server fashion.This assignment requires the analysis, implementation, testing anddocumentation of two small program written in C on the UHCL Linuxserver ruby or your own Linux box or virtual machine. A serverprogram and a client program that will be run concurrently.
Server program:The server program will provide a simple “echo” service to clientsthat connect with it and send it requests.Server program will be an iterative server (can process ONLY oneclient at a time) and it needs to do the following:Create a well-known receive FIFOs where it will read itsinputs/requests from the client and open it in READ mode (willblock of course until a client opens the fifo in writemode).Then go into an infinite loop to read requests from the clients,each request will be a “simulated system call”, each request/systemcall should include:o System call number (integer or byte)o Process ID of process sending/making the system callo Number “n” of parameters in the system call (integer orbyte)o Actual value(s) for the “n” parameters indicated above System Call 1 – would be the first request sent by a newclient (“connect system call”)and it should include 2 parameter which would be 1 - a simulatedprocess id (or real)and 2 - the name of the client’s specific FIFO which the servershould use to reply to thatclient. Server should open that client-specific FIFO in WRITE mode,save the filedescriptor and the pid of the client for use when replies need tobe sent to that client. Server must print to the screen a message indicating the“system call received”,something like:
Client pid: 1System Call Requested: 10 with 3 parameters which are:Param1=xxxx param2=YYYY param 3=zzzz
Server must reply back to the client through the client specificfifo with a reply message that should just echo (for now) thesystem call number received, number of parametersand values of parameters received (just echo the request)
If the request is the system call 2 “EXIT”, the server programmust close the client specific fifo and continue to receive thenext system call When the last client terminates, the server should close thewell known FIFO, delete it and terminate as well.Client Program:The client program will “connect” to the server through thewell-known FIFO and send requests through it to the server,obtaining information from the user as to what “system call tomake” and the corresponding values for the parameters, morespecifically, the client program should: Acquire from the user (through the command line or readingfrom the keyboard) what the client number this instance of theprogram will be (i.e., client 1, client 2, etc.) or usethe processid if you prefer
Open the well-known server’s fifo in write mode to communicatewith the server (which will unblock the server from its fifo opencall)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 includingClient number and name of the client-specific FIFO.Open the client-specific FIFO in READ mode to be able to readreplies from the server.(This will block the client until the server opens the fifo inwrite mode). After this, the client should go into a loop where the clientwill ask the user what to donext? providing two choices:o 1 – Send request to server, in this case it will ask the user fordata: What sytem call? (maybe provide choices that include “quit”,“read”,“write”, “open”, etc. (4 or more choices) 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 shouldinclude: System call number (integer or byte) Number “n” of parameters in the system call (integer orbyte) Actual value(s) for the “n” parameters indicated aboveAfter sending the request to the server, read the reply from theserver in theclient-specific FIFO and write it to the screen.o 2 – QUIT - indicates THIS client does not want to issue morerequests to theserver, it should send a “EXIT” system call to the server, closeits fifos, delete theclient specific FIFO and exit.
The first step in writing a client/server application is definethe communications protocolbetween both applications. In other words, how are you going toencode the requests andreplies into a message, you can encode data in string forms, youcan use integer data,separating each piece with a “,” “-“ a space, a new line character,or any other kind ofseparator.