Re: Interprocess Communication
- From: Jean-David Beyer <jeandavid8@xxxxxxxxxxx>
- Date: Thu, 16 Apr 2009 20:37:22 GMT
Marshall Lake wrote:
I'd like some feedback as to a good type of IPC to use under the
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
- Prev by Date: Re: how is updatedb running without a crontab entry?
- Next by Date: Re: how is updatedb running without a crontab entry?
- Previous by thread: Re: Interprocess Communication
- Next by thread: Re: Interprocess Communication