

Making DIPC work on WANs

 Many distributed systems are designed with a LAN as the underlying network
in mind. But that need not be the only case. Though network access across a 
WAN can be very time consuming, there may be situations where the results are
worth it. Specially of importance here are some scientific and most 
engineering computations, which require small initial data to start, compute 
for a relatively long time, and then produce a rather small amount of 
information as the result.

 I have attempted the following to increase the chances of DIPC working on 
a WAN: 

 * Reducing network access as much as possible. 
 All the entities in the DIPC are passive, They only keep the information 
they need and act only when requested. There is no need to involve all the
computers in a cluster to do a work, and there is no such thing as
broadcasting in DIPC. See the method used in attempting to create or access
an IPC structure as an example.

 TCP or UDP connections are closed as soon as they are no longer used. This 
means that a machine forwarding a request will not keep the connection open 
while waiting for the reply, which may not come back for a long time. Another 
TCP or UDP connection should be setup for any replies. This is done with the 
assumption that it would be better not to keep a (possibly long-distance) 
connection open for a long time. Aother reason is that it helps make DIPC
more secure (see the theory file).

 * No distributed decision making.
 There is no distributed decision making in DIPC. Unique processes manage
parts of the system they are responsible for, with no consultations with 
others.  

 * No synchronized clocks are assumed to exist in the cluster.
 Events happening for an IPC structure are ordered in time, relative to the 
moment the 'manager' of it sees them. This 'manager' could, for example, be 
the referee process, or it could be the manager of a distributed shared 
memory.


Some problems
 * Because broadcasting is not used in DIPC, individual computers should be
contacted to carry out an operation involving them. This may create some
scalability problems.

 * The referee is (among other things) the name server of DIPC, and all the 
DIPC tasks in a cluster should refer to it. Though the interactions are short
and simple, in a cluster with a great number of computers, this single name
server may become a bottle neck. One remedy would be to use more that one
referee in a cluster. The options won't be considered until the need arises.

 * The transfer of information across a WAN may take indeterminate amounts
of time, which means that a process initiating a request may not receive the 
reply in time. In this case the process will assume that the request failed. 
The process's pid is used to find out where to deliver the reply, so if the 
reply comes late, there is a remote possibility that it will be delivered to
another waiting task with the same pid. The fact that process-ids in Linux
are reused after a long time makes this problem much less important.

