Which IPC is better for message exchange
I am working on a problem where I need to pass a message from one thread to other, for example I have 3 threads one for each player, each player has to send 2 messages to other players. Other players also need give their acceptance or rejection based on message they receive.
Please advice which IPC is better for this scenario? |
Quote:
|
Quote:
|
You need to define some parameters. Does each player have a thread that is blocking on the message queue? Are the messages to be kept "secret" from other players? Are messages contemporaneous or is a mailbox adequate (read and respond at some interval)?
It's possible you don't need IPC - since it is internal to a signal thread, managing data structures might work just as well. |
Just use globals. Protect them with mutexes when threads are writing to them.
BTW, "IPC" is between processes, not threads. You might want to look up what it stands for. |
You can use any or all of the IPC mechanisms you want. I submit that it really depends what message you need to convey. For instance if it is related to the processes or threads, you can use a signal. You can use a pipe, you can use sockets, both of those will convey greater information than singular information. You also can use memory protected by a mutex, as stated earlier in the replies.
There may be a "best" for your situation, but you'll need to determine which of these conveyances works best for your program architecture. |
I've recently tried a multi-threaded process where messages are forwarded on pipes (pipe(2)), and a message is always an address of the actual data-area.
|
Quote:
I guess, I would prefer sockets, because currently I am working on a standalone game , but later it might be an online game. correct me if I am wrong.., there is no other IPC which communicates through network other than sockets right? so better use sockets only even if it is a standalone, so that we can improve latter point of for online? |
Quote:
You should at least abstract your communication modules so they can be easily swapped out if you want to try something other then sockets. There are a variety of flavors and options to consider so even if you use sockets abstracting your communication methods is a good idea. |
I wouldn't suggest using threads that run on different computers. Actually, they shouldn't called 'threads' to begin with.
|
If we're talking about multiple executable programs, then I'm not sure if you're using the word "threads" correctly.
|
So I think the question basically is client-server vs peer-to-peer networking.
|
Quote:
Quote:
Quote:
While it seems subtle, I think it would be beneficial to recognize the difference here and that IPC, to me, is defined as InterProcess Communications. Sockets is available, but that really means "local sockets". And I do feel you have an answer for this question. |
Quote:
Thanks, This is a good suggestion :) |
Use the network, TCP or UDP sockets.
It will work locally or distributed. It will scale from a desktop PC to the entire universe. |
All times are GMT -5. The time now is 02:40 AM. |