- In this video we'll talk about interprocess communication.
So how does that work?
Well, to start with, there are system five IPCs
and these are the old way to handle communication
between processes.
They were introduced with the introduction of Unix
so that's really old, in modern Linux distributions,
there are other methods as well, like remote procedure calls
and the desktop bus, shortly known as D-Bus,
which allows processes to communicate directly
to one another.
Let's first have a look at IPC.
So interprocess communication
or IPC is an old mechanism to enable communication
between processes in user space
and there are different IPC mechanisms like shared files.
That is where two programs read and write to a shared file
or shared memory, which semaphores, which is about values
in memory that can be tested and set by multiple programs.
Then there are the names and unnamed pipes where the output
of one program is used as input by another.
There are message queues where one process writes
through the queue and multiple processes can access.
There are sockets, which is a local
or network port that is used
for communication and there are signals.
These are generated by the system to alert processes.
All right, so how can we show IPC information?
Well, there is the IPC's command for an overview
of all IPCs that have currently been allocated.
Now on most modern Linux distributions, this won't show much
because IPCs are not very common anymore.
You can use IPC's minus P to see names
of processes which are using these system five IPCs
or LSIPC to get a summary
of usage of all IPC resource types.
And then there is good old top which you can use
for monitoring shared memory usage.
Let's have a look.
So if you type IPCs then this is what we get,
nothing and IPC's minus P is showing the processes
but again, nothing works.
Now how about LSIPC?
LSIPC is showing the different IPC resources
that are available and the uses, as well as the limitation.
And as you can see, nothing, nothing and nothing.
As I said, IPCs are kind of old school, but IPCs are
historically so important that at least you need to
know a little bit about them.
Let's have a look at the more modern approach.
So for your convenience, the steps in this demo are
on the slide, let me run them for you.
So for this demo we need multiple terminals,
from terminal one,
I'm going to use mkfifo, myfifo, this is a named pipe
and mkfifo will make it for me.
L is minus L on my fifo is showing the pipe I just created.
First character is a P, P for named pipe and cat,
my fifo is showing nothing at all.
All right, now I'm going to a new terminal and I need to
make sure that I'm in the same directly so
that I can see this my fifo and I am going to
use a cat greater
than my fifo and then I'm typing hello world
And control C to quit my command.
And now back to terminal number one.
What do we see?
Well we see that the hello world has been written
to the myfifo, so that's how this name pipe is working.
LS minus L is showing
that myfifo still exists as a named pipe.
And if you use unlink on myfifo,
then you can see that it doesn't exist anymore.
Unlink is the elegant way.
It's not really removing it,
it's unlinking the named pipe
from the current execution environment.
The last thing I wanna talk about is D-Bus.
So what is D-Bus?
D-Bus is a modern way for IPC
which originates from the GNOME
and KDE desktop environments.
It provides a software bus abstraction
to which all processes connect.
And D-Bus provides one virtual channel which
ensures that point to point relations
between processes are no longer required
or most systems, multiple buses are used simultaneously.
So to work with D-Bus,
the application needs to be D-Bus aware.
It doesn't work for all applications.
And again that is
because D-Bus has a background of graphical desktops.
So D-Bus aware applications expose uniform interfaces
that are provided by object paths and code for
a DBUs aware application can be written in many languages.
And you can use the D-Bus send commands
from the Linux CLI to explore what D-Bus is doing
and that results in commands like this.
So what do we see here?
Well we see D-Bus send
and this D-Bus send is addressing a specific destination
which is the network manager
and then it is going to use properties.set. to set a string
on the network manager.
And the string is networking enabled
and the variant boolean false, that is going to
disable networking on the network manager.
So how do we manage D-Bus?
Well typically you don't because D-Bus is normally managed
by using API calls from your applications or scripts.
But there is a few commands that you can use from the shell
and let give a bit of insight like busctl list,
which lists the bus names or D-Bus send
which allows you to send commands to specific object paths.
Let me show you.
So busctl list is showing all the different
D-Bus that are available and as you can see,
there's quite a couple of them.
Now I would like to to show you some commands
but these commands as we have seen are pretty tough
and that is why I created a file
with the name D-Bus commands.sh, which is,
which contains a couple of example commands.
Now this is an interesting one.
All of these commands are own network manager
so you can try all of them
and I'm just going to learn one of them.
So D-Bus send will list active connections.
So we see that it as properties get,
that's a part you need to understand.
So we get properties,
on this specific naming attribute that is known to D-Bus
and the properties are obtained from the network manager
and we are looking for string value on active connections.
So if I copy all of this then we can see what it is doing.
Now as you can see, these are not really
the commands that you are easily going to compose yourself
and that is because that was never the meaning of D-Bus.
But what we see here is active connections
and the variant is an array and active connection,
active connection number four.
So what can we do with this active connection
number four, well we can run the next command.
So in this D-Bus sent, I probably changed
that in the file itself before copying it.
So Vim on D-Bus command.sh.
I'm looking for connection number four
in the example desk connection number six.
And now I can copy all of this
so that we can ask D-Bus to send us the devices.
And there we go.
And here we can see the devices, which again is number.
Well I would say I'm going to stop here
have a look at this, this example D-Bus commands.sh file.
Play with it if you're interested in how it works.
But don't forget, this is nice to know, this is not
something that you will typically do as an administrator.