Which Linux Ipc Technique to Use

Which Linux IPC technique to use?

I would go for Unix Domain Sockets: less overhead than IP sockets (i.e. no inter-machine comms) but same convenience otherwise.

Which kind of inter process communication (ipc) mechanism should I use at which moment?

Long story short:

Use lock files, mutexes, semaphores and barriers when processes compete for a scarce resource. They operate in a similar manner: several process try to acquire a synchronisation primitive, some of them acquire it, others are put in sleeping state until the primitive is available again. Use semaphores to limit the amount of processes working with a resource. Use a mutex to limit the amount to 1.
You can partially avoid using synchronisation primitives by using non-blocking thread-safe data structures.
Use signals, queues, pipes, events, messages, unix sockets when processes need to exchange data. Signals and events are usually used for notifying a process of something (for instance, ctrl+c in unix terminal sends a SIGINT signal to a process). Pipes, shared memory and unix sockets are for transmitting data.
Use sockets for networking (or, speaking formally, for exchanging data between processes located on different machines).

Long story long: take a look at Modern Operating Systems book by Tanenbaum & Bos, namely IPC chapter. The topic is vast and can't be completely covered within a list or a paper.

Linux IPC selection?

Selection of IPC technique depends on application which you are trying to implement. Below is a good comparison base on performance:

IPC name      Latency     Throughput   Description
-----------------------------------------------------------------------------------------
Signal        Low          n/a         Can be used only for notification, traditionally-
                                       to push process to change its state

Socket        Moderate     Moderate    Only one mechanism which works for remote nodes,
                                       not very fast but universal

D-Bus         High         High        A high-level protocol that increases latency and
                                       reduces throughput compared to when using base
                                       sockets, gains in increased ease of use

Shared        n/a          High        Data saved in-between process runs(due to swapping
memory                                 access time) can have non-constant access latency

Mapped files  n/a          High        Data can be saved in-between device boots

Message      Low           Moderate    Data saved in-between process runs. The message
queue                                  size is limited but there is less overhead
                                       to handle messages

Here is one more nice comparison

Comparing Unix/Linux IPC

Choice of Linux IPC technique

I suggest a combination of shared memory and a socket. Have a shared memory area, say 1MB, and log all your information in some standard format in that buffer. If/when the buffer fills or the process terminates you send a message, via the socket, to the reader. After the reader ACKs you can clear the buffer and carry on.

To answer caf's concern about target application corruption, just use the mprotect system call to remove permissions (set PROT_NONE) from the shared memory area before giving control to your target process. Naturally this means you'll have to set PROT_READ|PROT_WRITE before updating your log on each allocation, not sure if this is a performance win with the mprotect calls thrown in.

EDIT: in case it isn't blindingly obvious, you can have multiple buffers (or one divided into N parts) so you can pass control back to the target process immediately and not wait for the reader to ACK. Also, given enough computation resources the reader can run as often as it wants reading the currently active buffer and performing real-time updates to the user or whatever it's reading for.

What is a good Inter-Process Communication method between C and PHP in Linux

Possibly the simplest solution you can find is to use pipes. The processes would have an open pipe for reading "calls" and answering them in the same fashion.

One possible way of setting this up is to have a pair of named pipes (mkfifo) in a specific or variable location. Such pipes are known to both this process and PHP. The process would block reading a loop for requests/commands in some textual "protocol" and write back to PHP through the other pipe. In this way both PHP and the external processes could be stopped/killed and restarted and the communications path would still be stable.

You might need to do something else in order to verify whether the process is actually running, if this is needed, but a simple "ping" command over this "protocol" would be enough.

This assumes:

you have the possibility of making improvements to the processes that communicates to the hardware (otherwise, your are bound to whatever it already offers)
you don't have high performance requirements (pipes are relatively slow)
there's no parallelism problem in case of concurrent accesses from the PHP script to process (unless you do some locking, 2 concurrent requests would be written mixed in the pipe)

There are off course other ways of achieving this, but I find hard to consider other way that is as simple as this. Queueing (d-bus, others), as suggested in some comments, are just building on top of this idea but adding more complexity IMHO, therefore, if no functionality provided by these other services is needed, pipes should be enough.

Using IPC for different systems

IPC just means Inter Process Communications. There are many ways for processes to communicate, There really is no difference if two processes are local to the same machine or not.

If you are talking across machines, some forms are not available to you such as Shared Memory, Signal, Pipe, Memory mapped File or Semaphore. (There is middleware that can simulate shared memory if you really want to go that route).

Some of the more common methods are:

File Most operating systems.

Signal Most operating systems; some systems, such as Windows, only implement signals in the C run-time library and do not actually provide support for their use as an IPC technique.

Socket Most operating systems.

Message queue Most operating systems.

Pipe All POSIX systems, Windows.

Named pipe All POSIX systems, Windows.

Semaphore All POSIX systems, Windows.

Shared memory All POSIX systems, Windows.

Message passing
(shared nothing) Used in MPI paradigm, Java RMI, CORBA, MSMQ, MailSlots and others.

Memory-mapped file All POSIX systems, Windows. This technique may carry race condition risk if a temporary file is used.

Edit: This list is taken from Wikipedia. The list is as good as any.

Which Linux Ipc Technique to Use