irab@amtfocus.UUCP (Ira Brenner) (03/12/88)
Here is a cross-posted question regarding the use of STREAMS and their viability as an IPC tool. Any responses can me e-mailed back to me, or posted to one of the relevent groups for others as naive as myself on the topic. The Problem: I have four main processes running simultaneously (A, B, C, D). Process B needs to communicate with a child (C) and another process, which may or may not be a child, (D). No direct communication between C and D is necessary. Process B also needs to communicate with process A. In addition, I would like processes B, C and D to be able to send messages up to process A in a uni-directional manner. Furthermore, although all of the processes initially will be running on a single machine, it is possible that process A, and possibly process D, may be running on different machines or single board computers. In a semi-graphical view this would look something like: -----------------------------A | | | | | | |----------------------------B------------------------- | | | | | | | | | | C D | | | | | | ________________________________________________________ What I would like to do is have process B open a bi-directional stream between processes A-B, B-C, and B-D. Also, I need process B to open a universal uni-directional stream from any process up to A. I don't know if I can use streams in this manner of IPC. If I can, I could use a few pointers on how to do it. I don't think any of the other methods of IPC for Unix (shared memory, semephores) are viable in this message passing scheme. Any ideas/solutions would be greatly appreciated. Thanks in advance, Ira irab@amtfocus:UUCP UUCP: {gatech, ihn4p, chinet, clyde}!mcdchg!amtfocus!irab
dmt@ptsfa.UUCP (Dave Turner) (03/17/88)
In article <117@amtfocus.UUCP> irab@amtfocus.UUCP (Ira Brenner) writes: > I have four main processes running simultaneously (A, B, C, D). Process > B needs to communicate with a child (C) and another process, which may > or may not be a child, (D). No direct communication between C and D is > necessary. Process B also needs to communicate with process A. In > could use a few pointers on how to do it. I don't think any of > the other methods of IPC for Unix (shared memory, semephores) are System V messages will do what you want. Have each process open a message queue for reading. The other processes can open the same msg queues for writing. The message could contain the message id if replies are expected (required?). A set of files can be used to allow the processes to open the msg queues. Use ftok() (see stdipc(3c) to convert filenames to key-t's for msgget(). Give the files names that make sense to the set of processes. /usr/spool/xxx/A # the msg queue read by process A /usr/spool/xxx/B # the msg queue read by process B /usr/spool/xxx/C # the msg queue read by process C /usr/spool/xxx/D # the msg queue read by process D Each process should ftok and get its msg queue first. Processes B-D should read (and wait for) messages. Process only needs to read its msg queue occassionally and probably should not wait. -- Dave Turner 415/542-1299 {ihnp4,lll-crg,qantel,pyramid}!ptsfa!dmt