问题
I have to create single Server Process A and multiple client process(es). All should use Linux POSIX IPC message queue for data passing. Message(s) will flow in both direction. It is also possible that at time multiple client process(es) may have registered to Server Process A.
Currently I'm using only one named Message queue which is created and Opened by Server Process A and used/opened (only) by client process(es). This works with two process scenario (i.e One server Process A and one client Process B) but doesn't work with multiple client process(es) and one server process.
The problem i'm facing here is in design/logic. How should I de-multiplex Message at server process A from other client process(es) and also reply from server Process A should sent back to only respective client Process or may be it can sent back to all client process(es) but it must only be processed at respective client process.
For example I'm just giving one scenario. Suppose Process A has created Message queue X. Process B and C is now coming up and also opening Message queue X. Now Process B sends request message to Message queue X but here the problem is Process A and Process C both will get awake with enqueue event. Here, How process C understand that Message doesn't belongs to it.
- IPC Message size is small like less than 128 bytes.
- IPc Message is define structure contains integer and bytes array. No double/float in structure.
- IPC Message queue is in NON_BLOCKING mode.
- No mandate on high performance.
- Language: C
- Compiler: GCC
- Platform/OS: Linux
- IPC Message queue: Only POSIX.
- I'm not suppose to use other IPC mechansim like System V messages or Unix local socket or Pipes etc.
Please let me know if any more details required.
Please suggest me solution(s) for this problem.
FYI: I have already searched in database but i couldn't find similar question asked/answered already so please make sure before you mark it duplicate. If you find similar problem is already asked and answered then please provide me the link.
回答1:
If I understand the scenario correctly, then it sounds like you will need multiple message queues. Trying to use a single message queue for two-way communication between multiple processes would turn into a complex situation. Without the ability to peek at a message, it would even be difficult for the server process to send a specific message to a specific client.
- Have one message queue that is a generic one used by a client to establish a "private" message queue. A client that wants to open a communication channel with the server could send a message to the server on this queue. Perhaps have the client send the name (e.g., using process id maybe) of the queue for the server to open.
- The server can then open a new message queue specifically for that client for two-way communication (or depending on the usage, it might make sense to open two queues, one for each direction between the client and server).
回答2:
Maybe not be the answer you suspect, but consider not using POSIX IPC at all. I designed an application about 15 years ago using SysV IPC. It was one of my worst design decisions.
Today I would use TCP/UDP with a proper protocol instead. Beside the fact that it would allow to move the individual components to different computers in future, the IP stacks are heavily used and supported very well.
With TCP you can establish fine 1:1 and individual 1:many connection oriented communication. With UDP you can make 1:1, 1:many and many:many not-connection oriented communication. You need to keep an eye on security concerns, but there are lots of helpful tutorials and support libraries.
Also for TCP/UDP portability is much better.
回答3:
I build a system like this years ago and I cant really remember all details, but the idea was using a parameter in the msgrcv() that indicates how to read the messages from the queue.
In the type of the message (msgbuf.type) when the server wanted to send a message to only one client, I was using the pid of the destination process as the type of the message. The clients only read messages whose type was equal to his pid.
Of course, the clients needed to send his pid to the server in the initilization.
回答4:
System V has an option in msgrcv() to fetch specific message from the queue, such that each client can read there own message posted by server in a single queue.So we can have a single queue to do a full duplex communication . In POSIX there is no such option, so we have to go for a two saperate queue, one for server to receive all from the client and each client should have the saperate queue to recevie frm server. The qid should be globaly known to all the process.
来源：https://stackoverflow.com/questions/16173215/using-linux-posix-ipc-message-queue