Using IPC for different systems

Question

Hii ,

I was asked this question in a recent interview for which i didnt answer as i was relatively new to IPC .

How would you use IPC if the processes are on different systems ?

Answer 1

IPC is an abstract term which denotes any interprocess communication between processes residing on the same or different systems.

If you have processes on different systems, most obvious are TCP-based communications, including IPC tools that use TCP as a transport. But of course this is not the only way to exchange information.

Answer 2

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.

Answer 3

IPC is Inter Process Communication, more of a technique to share data across different processes within one machine, in such a way that data passing binds the coupling of different processes.

• The first, is using memory mapping techniques, where a memory map is created, and others open the memory map for reading/writing...
• The second is, using sockets, to communicate with one another...this has a high overhead, as each process would have to open up the socket, communicate across... although effective
• The third, is to use a pipe or a named pipe, a very good example can be found here

There are complications, such as what if one process is written in one language, and the other process written in another, how do you guarantee the data flow is compatible for each process to read, you could use Google's Protocol Buffer to handle this, there is a .NET version available, here.

Although to a varying degree, IPC mechanisms are only transparent and work within the one domain, such as Windows to Windows, Linux to Linux, you may be able to do so with a Windows to Linux or vice versa, although caution must be heeded, as API differences and functionalities dictate the outcome to an agreement of data transfer encoding scheme.