I have doubt in using Linux Pipes for IPC. My question is
Can Linux pipes can be used to communicate between the processes running on different machines?.
Thanks,
No, you can't use only pipe to communicate between different machines, because pipe is defined as local machine communication method (IEEE standard says that it creates two file descriptors in current process. Descriptors usually can't be send to other machine, only inherited from parent or passed via local machine sockets).
But you can try to use pipe to some external socket program, like netcat, which will resend all data over tcp socket, and remote netcat will replay it back into the program.
And if you are developing some application, it can be better to use tcp sockets directly.
PS: The IPC - Inter-process communication - AFAIK means communications between different processes on one (same) machine (linux IPC from Linux Programmer's Guide 1995).
PPS: If sockets are hard to work with them directly, you may choose some Message Passing library or standard. For example MPI standard (OpenMPI, MPICH libraries) is often used to communicate between many machines in tightly-coupled computing clusters, and there are some popular interfaces like RPC (Remote procedure call, several implementations) or ZeroMQ
Pipe is only used for communication between related process on the same host (eg. parent and child process).
Related
is it possible to pass parameters between services runtime? What I've already found is how to start services with variables and how to pass them parameters using an external file at run-time. However, I could not find information about exchanging data between services.
You're looking for an IPC mechanism. Systemd does not provide one because Linux already has quite a few.
The most common method is for a service to listen on a socket (usually an AF_UNIX socket in /run, but TCP is also an option, e.g. if you're writing in Java) and for other services to connect to it and submit or receive data. You can invent your own protocol, but practically any RPC system (such as gRPC or SunRPC or REST) that's built for network use will also work for local use, both across TCP and across AF_UNIX sockets.
D-Bus is one specific IPC system that systemd itself uses (which is also built on top of AF_UNIX sockets, but with a central "message bus" daemon), but it is not part of systemd. It will likely be available on any systemd-based distribution, however. D-Bus bindings are available for most programming languages.
Aside from AF_UNIX sockets, Linux also has several forms of "shared memory" and "message queue" systems (POSIX IPC and SysV IPC variants of each).
Currently I'm developing a data acquisition program for my experiment in C++ from a Linux based machine (Ubuntu), I also have many VIs in Labview who is programmed in Windows to control the instruments of the experiment (motors, Signal Generator..). The purpose is to have a 2-way communication between 2 pc, the Linux will ask which VIs to be executed, and when it's finished, send back a signal to Linux machine.
My questions are:
Can I send a signal or a command to Labview in Windows from Linux (Terminal, and it can be implemented into my C code) and vice versa? How?
TCP Labview could be a solution? Or should I try to set the inter-PC "talking" through serial communication (which is easy to setup physically)?
The best (also the easiest) way is to implement TCP-based client-server communication (TCP will ensure data is lossless. When using other mechanisms like UDP or serial you should always make sure your commands are received correctly).
At LabVIEW site, you will have TCP listener (server) which will listen to commands from the Linux machine at your specified port.
Upon command reception, LabVIEW code can do the work and reply by the same TCP connection.
This is very good article about your question: https://decibel.ni.com/content/docs/DOC-9131
Their are several choices for communicating between C++ and LabVIEW. (As well as Linux / Windows).
If you are willing to run LabVIEW on your linux machine you can make use of several of the LabVIEW communication architectures. Here is NI's white paper.
http://www.ni.com/white-paper/12079/en/
Provides choices such as Shared Variable, Network Streams, Web Services, TCP/IP.
You can also take your LabVIEW code and compile it to a DLL and call it from C++ to make use of some of the above features. If not you are likely going to have to go to the TCP/IP route or web service.
I would recommend using TCP/IP, its pretty simple to implement on both sides.
If you are more familiar with serial protocols you can also use them to communicate.
On Linux a fairly common method for IPC between userland processes and services is, for example, a socket interface (either Unix domain or netlink).
Simply -- What is the Windows analog of this and how do userland processes communicate with services?
To set the stage: Assume I have a background service running that monitors devices on a network. If I wanted to write a program to utilize the services provided by this service, what would be the common "Windows-way" of doing this?
If I am completely off-base here, what is the common way a Windows service may extend itself on the Windows OS so other processes may know it is actively listening for connections?
Windows has named pipes,
"A named pipe is a named, one-way or duplex pipe for communication
between the pipe server and one or more pipe clients. All instances of
a named pipe share the same pipe name, but each instance has its own
buffers and handles, and provides a separate conduit for client/server
communication. The use of instances enables multiple pipe clients to
use the same named pipe simultaneously."
https://msdn.microsoft.com/en-us/library/windows/desktop/aa365590%28v=vs.85%29.aspx
I am trying to study all the different ways I can find in order for a process on a linux machine to establish IPC with a second process (not a child) on the same machine. I did find that socket can be used given I know the path on file system the second process is listening to.
Is IPC communication with an second process possible in other ways ? I don't want the first process to know the pid/uid of the second process. The scenario is more towards communicating with an untrusted process, by a different author, on the same machine, but still have some information like where the socket in the second process is listening ?
Shared Memory and Sockets can be used for IPC communications between the processes that are not related to each other. Pipes can be used for IPC communications between the parent and child processes.
Shared memory is the fastest form of interprocess communication. In all other methods, the system calls copy the data from the memory area of one process to another process. The drawback of shared memory is, you need to implement synchronization methods to avoid race condition.
Sockets interfaces enables communication in a connection oriented way between the process across the network as well as locally. UNIX domain sockets provides local IPC using a known file path.
Possible ways:
Shared memory (shmget, shmctl, shmat, shmdt)
FIFO queues aka named pipes (mkfifo)
Message queues (msgget, msgsnd, msgrcv, msgctl)
Semaphores - for synchronization (semget, semctl, semop)
Hint:
Useful commands: ipcs, ipcmk, ipcrm
Also, you can use mmap POSIX standard call with flag MAP_SHARED specified. Here https://www.cs.purdue.edu/homes/fahmy/cs503/mmap.txt you can find an example of using it.
I'm writing a daemon that interfaces with a USB device (an Arduino). This daemon is continuously aware of the current state.
Now I want to be able to interface with this daemon through a client program, also to be written in Perl. This client must be able to query the daemon for its current state and it must be able to update the daemon with settings.
I'm on Linux (x86_64)
I don't want to use an intermediate file and preferably simultaneous queries are easily implemented.
What is the name of such a mechanism? What Perl libraries can I use or should I avoid? What should I DuckDuckGo for?
Probably, you need to implement an event loop to allow doing the tasks of your USB device communication and serve information to the new interface. This concept will change the way you solved the problem, but I think is the better approach.
You can search at CPAN for modules like POE and AnyEvent
The idea is to build an event loop that handles a TCP socket in order to send & receive information from te interface