this project consists of using posix message queues for communic

Project Description:

this project consists of using posix message queues for communicating temperatures between each of four external processes and a central process. the project can be completed on systems that support posix message passing, such as unix, linux, and mac os x.part 1: overviewfour external processes will communicate temperatures to a central process, which in turn will reply with its own temperature and will indicate whether the entire system has stabilized. each process will receive its initial temperature upon creation and will recalculate a new temperature according to two formulas:new external temp =(mytemp * 3 + 2 * centraltemp) i 5;new central temp =(2 * centraltemp +four temps received from external processes) i 6;initially, each external process will send its temperature to the mailbox for the central process. if all four temperatures are exactly the same as those sent by the four processes during the last iteration, the system has stabilized. in this case, the central process will notify each external process that it is now finished (along with the central process itself), and each process will output the final stabilized temperature. if the system has not yet become stable, the central process will send its new temperature to the mailbox for each of the outer processes and await their replies. the processes will continue to run until the temperature has stabilized.part 2: the message passing systemprocesses can exchange messages by using four system calls: msgget (), msgsnd (), msgrcv (), and msgctl (). the msgget () function converts a mailbox name to a message queue id, msqid. (a mailbox name is an externally known message queue name that is shared among the cooperating processes.) msqid, the internal identifier returned by msgget (), must be passed to all subsequent system calls using this message queue to facilitate interprocess communication. a typical invocation of msgget ()is seen below:msqid = msgget(1234, 0600 i ipc_creat);the first parameter is the name of the mailbox, and the second parameter instructs the operating system to create the message queue if it does not already exist, with read and write privileges only for processes with the same user id as this process. if a message queue already exists for this mailbox name, msgget () returns the msqid of the existing mailbox. to avoid attaching to an existing message queue, a process can first attempt to attach to the mailbox by omitting ipc_creat and then checking the return value from msgget (). if msq id is negative, an error has occurred during the system calt and the globally accessible variable errno can be consulted to determine whether the error occurred because the message queue already exists or for some other reason. if the process determines that the mailbox does not currently exist it can then create it by including ipc_creat. (for the current project, this strategy should not be necessary if students are using standalone pcs or are assigned unique ranges of mailbox names by the instructor.)once a valid msqid has been established, a process can begin to use msgsnd () to send messages and msgrcv () to receive messages. the messages being sent and received are similar in format to those described in section 3.5.2, as they include a fixed-length portion at the beginning followed by a variable-length portion. obviously, the senders and receivers must agree on the format of the messages being exchanged. since the operating system specifies one field in the fixed-length portion of every message format and at least one piece of information will be sent to the receiving process, it is logical to create a data aggregate for each type of message using a struct. the first field of any such struct must be a long, and it will contain the priority of the message. (this project does not use this functionality; we recommend that you simply make the first field in every message equal to the same integral value, such as 2.) other fields in the messages contain the information to be shared between the communicating processes. three additional fields are recommended: (1) the temperature being sent, (2) the process number of the external process sending the message (0 for the central process), and (3) a flag that is set to 0 but that the central process will set to 1 when it notices stability. a recommended struct appears as follows:struct {long priority;int temp;int pid;int stable;} msgp;assuming the msqid has been established, examples of msgsnd() and msgrcv () appear as such:int stat, msqid;stat = msgsnd(msqid, &msgp,sizeof(msgp)-sizeof(long), 0);stat msgrcv(msqid, &msgp,sizeof(msgp)-sizeof(long), 2, 0);the first parameter in both system calls must be a valid msq id; otherwise a negative value is returned. (both functions return the number of bytes sent or received upon successful completion of the operation.) the second parameter is the address of where to find or store the message to be sent or received, followed by the number of information bytes to be sent or received. the final parameter of 0 indicates that the operations will be synchronous and that the sender will block if the message queue is full. (ipc_nowait would be used if asynchronous, or nonblocking, operations were desired. each individual message queue can hold a maximum number of messages-or bytes-so it is possible for the queue to become filled, which is one reason a sender may block when attempting to transmit a message.) the 2 that appears before this final parameter in msgrcv () indicates the minimum priority level of the messages the process wishes to receive; the receiver will wait until a message of that priority (or higher) is sent to the msqid if this is a synchronous operation.once a process is finished using a message queue, it must be removed so that the mailbox can be reused by other processes. unless it is removed, the message queue-and any messages that have not yet been received-will remain in the storage space that has been provided for this mailbox by the kernel. to remove the message queue, and delete any unread messages therein, it is necessary to invoke msgctl (), as follows:struct msgid_ds dummyparam;status= msgctl(msqid, ipc_rmid, &dummyparam);the third parameter is necessary because this function requires it but it is used only if it the programmer wishes to collect some statistics about the usage of the message queue. this is accomplished by substituting ipc_stat as the second parameter. all programs should include the following three header files, which are found in /usr/include/sys: ipc.h, types.h, and msg.h. one possibly confusing artifact of the message queue implementation bears mentioning at this point. after a mailbox is removed via msgctl (),any subsequent attempts to create another mailbox with that same name using msgget () will typically generate a different msqid.part 3: creating the processeseach external process, as well as the central server, will create its own mailbox with the name x+ i, where i is a numeric identifier of the external process 1..4 or zero for the central process. thus, if x were 70, then the central process would receive messages in the mailbox named 70, and it would send its replies to mailboxes 71-74. outer process 2 would receive in mailbox 72 and would send to mailbox 70, and so forth. thus, each external process will attach to two mailboxes, and the central process will attach to five. if each process specifies ipc_creat heninvoking msgget (), the first process that invokes msgget () actually creates the mailbox; subsequent calls to msgget () attach to the existing mailbox. the protocol for removal should be that the mailbox/message queue that each process is listening to should be the only one it removes -via msgctl () .)each external process will be uniquely identified by a command-line parameter. the first parameter to each external process will be its initial temperature, and the second parameter will be its unique number: 1, 2, 3, or 4. the central server will be passed one parameter-its initial temperature. assuming the executable name of the external process is external and the central server is central, invoking all five processes will be done as follows:./external 100 1 &./external 22 2 &./external 50 3 &./external 40 4 &./central 60 &part 4: implementation hintsit might be best to start by sending one message successfully from the central process to a single outer process, and vice versa, before trying to write all the code to solve this problem. it is also wise to check all the return values from the four message queue system calls for possible failed requests and to output a message to the screen after each one successfully completes. the message should indicate what was accomplished and by whom -for instance, "mailbox 71 has been created by outer process 1/' "message received by central process from external process 2/' and so forth. these messages can be removed or commented out after the problem is solved. processes should also verify that they were passed the correct number of command-line parameters #via the argc parameter in main###. finally, extraneous messages residing in a queue can cause a collection of cooperating processes that function correctly to appear erroneous. for that reason, it is wise to remove all mailboxes relevant to this project to ensure that mailboxes are empty before the processes begin. the easiest way to do this is to use the ipcs command to list all message queues and the ipcrm command to remove existing message queues. the ipcs command lists the msqid of all message queues on the system. use ipcrm to remove message queues according to their msqid. for example, if msqid 163845 appears with the output of ipcs, it can be deleted with the following command: ipcrm -q 163845
Skills Required:
Project Stats:

Price Type: Negotiable

Total Proposals: 5
1 Current viewersl
43 Total views
Project posted by:


Proposals Reputation Price offered
  • 3.8
    30 Jobs 19 Reviews
    $0 in 0 Day
  • 4.6
    648 Jobs 468 Reviews
    $0 in 0 Day
  • 5.0
    13 Jobs 7 Reviews
    $0 in 0 Day
  • 2.5
    8 Jobs 6 Reviews
    $0 in 0 Day
  • 0.0
    0 Jobs 0 Reviews
    $0 in 0 Day