DIPC(1)

NAME
DIPC - Distributed Inter-Process Communication System

Introduction

DIPC (Distributed Inter-Process Communications) is a software-only solution for enabling people to build and program multi-computers easily. Each node can be an ordinary personal computer. These nodes should be connected to each other by a TCP/IP or UDP/IP network. It does not use network broadcasting, which helps it work in networks with no such capabilities. There is also no assumption of the existence of a synchronized clock. These mean that DIPC could be used in a Wide Area Network (WAN). DIPC is suitable for writing coarse-grain parallel programs. In DIPC, UNIX System V IPC mechanisms, consisting of semaphores, messages and shared memories, are modified to function in a network environment. Here the same system calls that are used to provide communication between processes running in the same computer could be used to allow the communication of processes running on different machines. There is no new system call for the application programmers' use. There is also no library to be linked to the application code, and no need for any modifications in compilers. DIPC could be used with any language that allows access to operating system's system calls. DIPC is completely camouflaged in the kernel. The above means that DIPC supports both the message passing and the distributed shared memory paradigms of distributed programming, which results in more options for application programmers. Also, allowing the processes to share only selected parts of their address space helps to reduce the problems of false sharing. DIPC has two parts: the more important part is a program named dipcd, which runs with superuser privileges. dipcd forks several processes to do its work. The other part is inside the kernel, giving dipcd work to do and also letting it to see and manipulate kernel data. The two parts use a private system call to exchange data. This system call should not be used by other processes in the system. DIPC is only concerned with providing some mechanisms for distributed programming. The policies, i.e. how a program is parallelized, or where an application program's processes should run, are determined by the programmer or the end user. Considering the fact that in most cases the programs' codes change much less frequently than the data they use, DIPC provides easy data transfer over the network, and assumes that the code to use these data already resides at the suitable places.

DIPC Clusters
DIPC enables the creation of clusters of PC computers. Computers in the same cluster could work together to solve a problem. DIPC's clusters are logical entities, meaning that they are independent of any physical network characteristics. Computers could be added to or deleted from a cluster without the need to change any of the network parameters. Several clusters may exist in the same physical network, and each computer could belong to at most one of them. Computers on the same cluster may 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. They can then use these structures to communicate with each other. A key normally has a unique meaning only in one computer. DIPC makes the IPC keys globally known. Here, if the application programmer wants it, 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 are 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. This means that the referee is DIPC's name server. Beside 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 interferences. So as to prevent any unwanted interactions, it was decided that distributed IPC structures should be declared by programmers as being so. The programmer just has to specify a flag to do this. The structures are local by default. The mentioned flag is the ONLY thing that the programmer should do to create a distributed program. The rest is like ordinary System V IPC programming. Should it not have been the intention to make DIPC compatible with older programs, this system would be totally transparent to programmers.

DIPC Programs
Here, by DIPC programs we mean distributed application programs written to be run using DIPC. DIPC's programming model is very simple, and quite like using ordinary System V IPC. A Typical scenario is this: a process first creates and initializes the needed IPC structures. After that other processes are started to collaborate on a job. All of them can access the same IPC structures and exchange data. These processes are usually executing in remote machines, but they all could also be running in the same computer, meaning that distributed programs can be written on a single machine and later run in real multi-computers. One important point to keep in mind about DIPC is that no other UNIX facility is changed to work in a distributed environment. So programmers can not use system calls like fork(), which creates a process in the local computer. The fact that DIPC programs use numerical keys to be able to transfer data means that they do not need to know where the corresponding IPC structures are. 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 re-make 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/her program dependent on some physical system characteristics. (S)He could for example hard code a computer address in his code. DIPC programmers are discouraged to do so. When dipcd is not running, the kernel parts of DIPC are short circuited, causing the system to behave like a normal Linux operating system. So users can easily disable the distributed system. Also, normal Linux kernels are not affected by DIPC programs, meaning that the there is no need to change and recompile these programs when they are to be executed in single computers with no DIPC support.

DIPC's Distributed Shared Memory
Distributed Shared Memory (DSM) in DIPC uses a multiple-readers / single-writer protocol: DIPC replicates the contents of the shared memory in each computer with reader processes, so they can work in parallel, but there can be only one computer with processes that write to a shared memory. The strict consistency model is used here, meaning that a read will return the most recently written value. It also means that there is no need for the programmer to do any special synchronization activity when accessing a distributed shared memory segment. The most important disadvantage with this scheme is a possible loss of performance in comparison to other DSM consistency models. DIPC can be configured to provide a segment-based or a page-based DSM. In the first case, DIPC transfers the whole contents of the shared memory from computer to computer, with no regard to whether all that data are to be used or not. This could reduce the data transfer administration time. In the page-based mode, xKB pages are transferred as needed. X is determined at dipcs's startup time, and should be the same in all the computers of the cluster. This makes multiple parallel writes to different pages possible. In DIPC each computer is allowed to access the shared memory for at least a configurable time quantum. This lessens the chances of the shared memory being transferred frequently over the network, which could result in very bad performance.

FILES

/usr/sbin/dipcd - user space part of DIPC

/etc/dipc.allow - access list used by dipcd

/etc/dipc.conf - configuration file for dipcd

SEE ALSO
dipcd(8), dipcker(1), dicref(1), dipcshm(1), dipcx(1), dipc.allow(5), dipc.conf(5), rsh(1), ipc(2)

BUGS
Please send all bug reports to this address:

linux-dipc@wallybox.cei.net

MAILING LIST
There is a mailing list dedicated to DIPC which you can join by sending email to the following address: majordomo@wallybox.cei.net Simply enter "subscribe linux-dipc" (no quotes necessary) in the body and nothing in the Subject. The mailing list is also archived and can be reached at the following url:

http://wallybox.cei.net/dipc/ml-archive/

WEB SITE
Further information about DIPC can be found at the web site: http://wallybox.cei.net/dipc/

AUTHOR
  Kamran Karimi
  89, Nastaran/Ghandehari
  Khosh Shomali str.
  14578 - Tehran, Iran
  mshar@vax.ipm.ac.ir kamran@wallybox.cei.net