Re: Interprocess Communication

Marshall Lake wrote:
I'd like some feedback as to a good type of IPC to use under the
following scenerio:

platform - Linux (I really don't care about supporting any other platform)

Multiple children, all of the same parent and on the same machine, will
be communicating. There will be two different types (read: having two
different sets of responsibilities) of children. Call the two different
types of children CH1 and CH2. There can be many CH1 children and only
one CH2 child. The CH2 child will be the controlling process. All the
CH1 children will communicate in both directions with the CH2 child.
Once control is completed two CH1 children will be communicating in both
directions with each other.

I should have included that in my scenerio. I'll be using C.

The application will be a game environment where one person will be
competing against another person. It won't be in real-time. It will
be more of move-based environment. Think Chess between two people.

First, I'd think about using Perl instead of C.
The syntax of the 2 languages isn't that far apart.
Sure you can go crazy writing unreadable perl, but you don't have to.

I have 0 experience with Perl and a lot of experience with C. I think
I'd be more comfortable using C. Additionally, although this may not
make a difference, the parent and the CH1 child identified above are
already written in C.

For C, sockets/fork exec isn't all that hard.
I've done it many times.
There are lots of on-line examples.

Make sure to set up a simple 2 way send/response protocol.
You can do dup/popen etc. but I find sockets simpler with C.

I've used sockets in the past and you're right ... socket programming
isn't difficult. In fact, this project is a client/server paradigm
using sockets. The client can reside on another machine from the server.

I thought I would do the additional child (CH2, see above) using IPC
since it will always reside on the same machine as the other processes
with which it will be communicating. Surely there must be advantages
to using IPC over sockets when sockets are not necessary, isn't there?

I do not know about the present with Linux. In the past on UNIX (15 years ago) sockets were a little more expensive in time that the Sys 5 IPC when either would serve. Nowdays, connecting to a port on 127.0.0.1 is probably almost as cheap as Sys 5 IPC. Bear in mind that if most of the time consumed is in passing messages, then the processes may not be thought out all that well. They should spend more time processing (or waiting) than in passing messages. So the efficiency question should not matter much. In the old days, we had only 10 MHz NIC cards for that kind of thing, but now it may be much more. And to your own machine, no NIC is used.

I suggest you pick one or the other and use just one IPC mechanism for all IPC because of the reduced complexity. And if there is any chance this system would run on more than one interconnected machine, sockets is the way to go.

Another poster also seemed to be recommending sockets. Maybe I should
go that route?



--
.~. Jean-David Beyer Registered Linux User 85642.
/V\ PGP-Key: 9A2FC99A Registered Machine 241939.
/( )\ Shrewsbury, New Jersey http://counter.li.org
^^-^^ 16:30:01 up 22 days, 22:44, 3 users, load average: 4.05, 4.18, 4.45
.

Relevant Pages

  • Re: Interprocess Communication
    ... Once control is completed two CH1 children will be communicating in both ... For situations where many processes will exist, where they may be created and destroyed frequently, where the interconnections among them are not well known in advance, etc., you can use System V IPC if your system has them. ... It is great for simplifying the design of complex systems because each process is designed to do only one thing, and as long as the system is properly designed, the processes do a great job of separating concerns, information hiding, and other reliability-increasing good stuff. ... If the system may grow to run on more than one machine, yet IPC must be preserved, you are almost certainly better off using sockets and communicating with sockets using IP. ...
    (comp.os.linux.misc)
  • Re: Interprocess Communication
    ... Multiple children, all of the same parent and on the same machine, will ... The CH2 child will be the controlling process. ... Once control is completed two CH1 children will be communicating in both ... I've used sockets in the past and you're right ... ...
    (comp.os.linux.misc)
  • IPC : Named Pipes, RPC and Sockets etc.
    ... In SQL Server BOL it it is mentioned that Named Pipes, RPC and Sockets ... What are these IPC mechanisms? ...
    (microsoft.public.sqlserver)
  • Re: IPC in C#
    ... I mean IPC as an inter process messages queueing mechanism. ... Answer messages use the same mechanism (in another queue ?) ... >> A first version has been written, using Tcp sockets (1 thread by ...
    (microsoft.public.win32.programmer.networks)
  • Re: IPC in C#
    ... working with sockets:8-) ... > Generic method of C# is remoting but that (as MSMQ btw) use sockets as ... >> I write a routing messages application in C#. ... >> I would like to use a real and fast IPC. ...
    (microsoft.public.win32.programmer.networks)