Best Way for Interprocess Communication in C++

Linux best way in two-way IPC in C

There are a number of different ways to implement IPC. For a good comparison, see Stevens' books. The classic is 'Advanced Programming in the UNIX environment', but there is also 'UNIX Network Programming, Volume 2, Second Edition: Interprocess Communications'. I know it is sometimes not considered good form to point to references elsewhere, but whether this is an academic or commercial problem, most UNIX programmers would recognise Stevens as an invaluable resource.

That said, here are your main options for IPC:

Use a pipe() between the processes. The format will always be stream-based; if you are sending datastructures, this can be a pain as you need to worry not only about serialization, but also about buffering and translating the 'packets' back into messages. Pipes are unidirectional, so you will need two for bidirectional communication.
Use a named pipe or fifo. This allows many-to-one communication and for the fifo to persist after one end has quit. Otherwise as per (1).
Use a socketpair between the processes - specifically a unix domain socket. Sockets are bidirectional. You can either use streaming sockets (SOL_STREAM), datagrams (unreliable, ordering not guaranteed - SOCK_DGRAM) or perhaps better sequenced reliable bidirectional packet communication (SOCK_SEQPACKET). Packet based communication means that you can (e.g.) put one datastructure in each packet.
Use signals. Effectively you get to send one integer at a time. Signals do not mix well with threading, handling interrupted system calls is hard, and various race conditions make them unreliable unless you know what you are doing and are not too worried about portability. Best avoided in most cases.
Use system V semaphores (semget etc.) or POSIX semaphores (sem_open etc.). Useful for sending signals between processes to achieve synchronization but not much more.
Use shared memory (shmget etc.) - the same page(s) are made visible to multiple processes. You will need to combine with some method of synchronisation.
System V message queues (msgget etc.) - maintain a queue of packets (messages) between two processes.
Some combination of the above.

I've omitted some things only in forks of the kernel (e.g. Binder) or under development (e.g. KDBus).

Examples of and tutorials for nearly all the above can be found here.

Now, most of these could be used for the application you mention. It looks like you want to send variable size messages, so if you use a stream based protocol, the normal hack is to send the length of the packet as the first 1, 2 or 4 bytes (depending on the maximum length). Packet based protocols are easier here (obviously) but each have their own maximum packet size. Do you care about reliability? Do you care about portability? Do you care about speed? All of these are valid concerns when choosing between them.

Finally, an advantage to the FD-based methods (e.g. pipes, socketpairs) is that you can add them to a normal select() loop; if you have other things going on in your program, this may be helpful.

You asked in comments for some examples of socketpair code. I reiterate the comment at the top re getting hold of Stephens. In the absence of that:

Socketpair() in C/Unix shows a good example of setting up a socketpair for IPC using fork().
The tutorial mentioned above has a good section on socketpair() here.

Best way for interprocess communication in C++

One Word: Boost.InterProcess. If it really needs to be fast, shared memory is the way to go. You nearly have zero overhead as the operation system does the usual mapping between virtual and physical addresses and no copy is required for the data. You just have to lookout for concurrency issues.

For actually sending commands like shutdown and query, I would use message queues. I previously used localhost network programming to do that, and used manual shared memory allocation, before i knew about boost. Damn if i would need to rewrite the app, I would immediately pick boost. Boost.InterProcess makes this more easy for you. Check it out.

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.

How to Create IPC (Interprocess Communication) C programme to create with two child process

You'r code create one parent and one child, not two child, so you need to add another fork into child block :

#include <stdio.h>
void main()
{
    int pid,status;
    pid = fork();
    if(pid == -1) {
        printf(“fork failed\n”);
        exit(1);
    }
    if(pid == 0) { /* Child */
        fork();// another child
        if (execlp(“/bin/ls”, “ls”, NULL)< 0) {
            printf(“exec failed\n”);
            exit(1);
        }
    }
    else { /* Parent */
        wait(&status);
        printf(“Well done kid!\n”);
        exit(0);
    }
}

Inter-Process Communication Recommendation

Boost has a nice InterProcess library that is cross-platform and quite intuitive.

I have only toyed with it though, so there might be better alternatives out there.

However, if you don't really need shared memory, I would stick with a messaging approach. You'll avoid deadlocks and race conditions. The pipe principle is really great, and it even allows for lazy behaviors which may save you a lot of processing depending on the matter at hand!

Best way for interprocess communication in two ways between a server and a client

If you don't know anything about communication, pick an off the shelf solution. A Bidirectional WCF channel is a good example. See What You Need To Know About One-Way Calls, Callbacks, And Events for a primer. Read WCF Overview (including all the links!) for an introduction into WCF.

If you are more versed into communications then you should had defined the problem more clearly:

what authentication model is used? Kerberos, certificates, password, none?
intranet or internet?
who's doing the listenning? your own service, http.sys, WCF activation?
and the most fundamental question: syncronous or asynchronous? And I do not mean asyn as an async API, but async as in queued message oriented protocol.