DIPC: The Linux Way of Distributed Programming

This article discusses the main characteristics of Distributed Inter-Process Communication (DIPC), a relatively simple system software that provides users of the Linux operating system with both the distributed shared memory and the message passing paradigms of distributed programming.

DIPC Clusters

DIPC enables the creation of clusters of
PCs. Computers in the same cluster could work together to solve a
problem. DIPC's clusters are logical entities, meaning they are
independent of any physical network characteristics. Computers
could be added or deleted from a cluster without the need to change
any of the network parameters. Several clusters may exist in the
same physical network, but each computer can belong to at most one
of them. Computers on the same cluster can even be connected to
each other by a WAN. As far as DIPC is concerned, computers in one
cluster never interact with computers in other clusters.

In normal System V IPC, processes specify numerical
keys to gain access to the same IPC structure
(see Resources 4). They can then use these structures to
communicate with each other. A key normally has a unique meaning in
only one computer. DIPC makes the IPC keys globally known. Here, if
the application programmer wishes, a key can have the same meaning
in more than one machine. Processes on different computers can
communicate with each other the same way they did in a single
machine.

Information about all the IPC keys in use is kept by one of
dipcd's processes called the referee. Each
cluster has only one referee. In fact, it is having the same
referee that places computers in the same cluster. All other
processes in the cluster refer to this one to find out if a key is
in use. The referee is DIPC's name server. Besides many other
duties, the referee also makes sure that only one computer at a
time will attempt to create an IPC structure with a given key
value, hence the name. Using a central entity simplifies the design
and implementation but can become a bottleneck in large
configurations. Finding a remedy to this problem is left to the
time when DIPC is actually running in such configurations.

Users may need to run some programs (e.g., utilities) in all
the computers in the system at the same time, and these programs
may need to use the same IPC keys. This could create interference.
To prevent any unwanted interactions, distributed IPC structures
are declared by programmers. The programmer must specify a flag to
do this. The structures are local by default. The mentioned flag is
the only thing the programmer should do to
create a distributed program. The rest is like ordinary System V
IPC programming. Other than this flag to keep DIPC compatible with
older programs, the system is totally transparent to
programmers.

DIPC Programs

DIPC's programming model is simple and quite similar to using
ordinary System V IPC. First, a process creates and initializes the
needed IPC structures. After that, other processes are started to
collaborate on the job. All of them can access the same IPC
structures and exchange data. These processes are usually executing
in remote machines, but they could also be running on the same
computer, meaning distributed programs can be written on a single
machine and later run on real multi-computers.

An important point about DIPC is that no other UNIX facility
is changed to work in a distributed environment. Thus, programmers
cannot use system calls, such as
fork, which create a process in
the local computer.

The fact that DIPC programs use numerical keys to transfer
data means they do not need to know where the corresponding IPC
structures are located. DIPC makes sure that processes find the
needed resources just by using the specified keys. The resources
could be located in different computers during different runs of a
distributed program. This logical addressing of resources makes the
programs independent of any physical network
characteristics.

Simple techniques allow the mapping from logical computing
resources needed by a program to physical resources to be done with
no need to remake the program. As DIPC programs do not need to use
any physical network addresses, they do not need recompiling to run
in new environments. Of course, this does not prevent the
programmer from choosing to make his program dependent on some
physical system characteristics. For example, he could hard code a
computer address in his code. DIPC programmers are discouraged from
doing this type of coding.

When dipcd is not running, the kernel parts of DIPC are short
circuited, causing the system to behave like a normal Linux
operating system. As a result, users can easily disable the
distributed system. Also, normal Linux kernels are not affected by
DIPC programs, meaning there is no need to change and recompile
these programs when they are to be executed in single computers
with no DIPC support.

Geek Guides

Pick up any e-commerce web or mobile app today, and you’ll be holding a mashup of interconnected applications and services from a variety of different providers. For instance, when you connect to Amazon’s e-commerce app, cookies, tags and pixels that are monitored by solutions like Exact Target, BazaarVoice, Bing, Shopzilla, Liveramp and Google Tag Manager track every action you take. You’re presented with special offers and coupons based on your viewing and buying patterns. If you find something you want for your birthday, a third party manages your wish list, which you can share through multiple social- media outlets or email to a friend. When you select something to buy, you find yourself presented with similar items as kind suggestions. And when you finally check out, you’re offered the ability to pay with promo codes, gifts cards, PayPal or a variety of credit cards.