Interprocess Communication
Marshall Lake
however).
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.
Did I forget anything?
Any help is appreciated.
Dan Espen
Without knowing what this application is really doing, I'd vote for
what I would find easiest:
Perl.
Do:
man perlipc
The Natural Philosopher
only read by another/many basis per record.
Handover Phist
Disclaimer: I'm an ignorant bastard who knows nothing.
Isn't this what hald is for?
--
Vegetarians for oral sex -- "The only meat that's fit to eat"
Marshall Lake
>> 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.
> Without knowing what this application is really doing, I'd vote for
> what I would find easiest:
>
> Perl.
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.
Marshall Lake
>>> 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.
> Well I'd prolly either use files or a mysql database..on write by one
> only read by another/many basis per record.
Using files written to a hard drive won't work in this case. That's not
really IPC, is it?
Marshall Lake
>> 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.
> Disclaimer: I'm an ignorant bastard who knows nothing.
>
> Isn't this what hald is for?
I think hald is for hardware.
The Natural Philosopher
shared filesystem? None really. It just so happens that an operating
system tends to allow shared access to a file system but deny it to RAM.
And since most of the moving file system is in fact cached in RAM
anyway, there ain't much difference in speed..
There are more complicated ways to do the same thing, like named pipes
and so on, or if you really need speed, kernel mechanisms.
Or you can 'do your own daemon' and use socket level communication to
it, and it can sit there and arbitrate between processes.
Or make4 use of a daemon you may already have, like mysqld, which is
utterly designed to do things like write one ready many, in strict sequence.
The Natural Philosopher
Now obsoleted by UDEV. Mostly. Or merged with it or something.
Anyway its all teh gubbins that works out what you have plugged in as
peripherals, and where to make the devices appear and in what form, in
the /dev, and other pseudo file system trees.
Jean-David Beyer
If you are sure all the processes that will be communicating are on the same
computer, you can use pipes or named pipes. I find them clumsy to get set
up, and useful only if the number of processes are few, and the connections
among them are very simple.
man pipe
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.
Red Hat Enterprise Linux 5 has them. This is a group of IPC mechanisms you
can use depending on what you need. There are semaphores if you wish to
exchange only a bit or so of information, shared memory, or messages (called
message queues). I was involved in a project where using messages was very
appropriate. We had hundreds of processes that needed to communicate among
each other. What we did was build each process as a finite-state-machine
whose main loop waited for a message, and when it received a message, acted
depending on the state of the f.s.m. and the message type received. In the
process, the f.s.m. did as much as it could with the message (possibly
including sending messages to the sender or other processes), adjusted the
state of the f.s.m., and then waiting for the next message. This is a great
way to run a system designed as a number (possibly large and dynamic) of
communicating processes. 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.
man svipc
Neither of the above approaches work particularly well if there is a
possibility that the processes involved are not, or cannot be assumed to be,
all on the same machine. 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. In the system as
described above, we did both. It was able to be distributed over multiple
machines, but most of the communication was done among processes on each
machine, so we used System V ipc on each machine, with the communication
between machines with sockets.
man socket
--
.~. Jean-David Beyer Registered Linux User 85642.
/V\ PGP-Key: 9A2FC99A Registered Machine 241939.
/( )\ Shrewsbury, New Jersey http://counter.li.org
^^-^^ 06:10:01 up 22 days, 12:24, 3 users, load average: 5.86, 4.74, 4.27
John Hasler
> [HAL] Hardware Abstraction Level Device IIRC.
> Now obsoleted by UDEV. Mostly. Or merged with it or something.
Unfortunately, no. Udev replaces Hotplug.
Description: Hardware Abstraction Layer
HAL provides an abstract view on hardware.
.
This abstraction layer is simply an interface that makes it possible to
add support for new devices and new ways of connecting devices to the
computer, without modifying every application that uses the device.
It maintains a list of devices that currently exist, and can provide
information about those upon request.
Homepage: http://hal.freedesktop.org/
Description: /dev/ and hotplug management daemon
udev is a daemon which dynamically creates and removes device nodes from
/dev/, handles hotplug events and loads drivers at boot time. It replaces
the hotplug package and requires a 2.6.18 or newer kernel version.
--
John Hasler
jo...@dhh.gt.org
Dancing Horse Hill
Elmwood, WI USA
Dan Espen
Ok, thanks.
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.
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.
Marshall Lake
>>>> 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?
Another poster also seemed to be recommending sockets. Maybe I should
go that route?
Jean-David Beyer
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