DU: Distributed Users


Introduction

DU provides means for a user to transparently communicate with other users on remote UNIX machines, as if they were logged on to the local machine.

The transparency is achieved by using the low level tty/pty handling routines. In effect, whenever somone logs into one machine on the cluster, they are immediately logged on to every other machine on the cluster.


Terminology

The following terms will be used in both this document and in the documentation for DU.

Cluster
A cluster is a network of machines, often similar in architecture, configuration, and purpose. Relative to DU, a cluster refers to all the machines which are on the DU network.
Logging on
This is used in the traditional UNIX sense. Logging on to a UNIX machine usually usually involves entering a user name and possibly a password. UNIX keeps track of people who have logged on to a machine through files such as the utmp and wtmp.
Registration
After logging on, the user may wishe to make his presence known to the rest of the cluster. The process of notifying DU that a person has logged on is called 'registration.'
Daemon
A background process that provides a service. The first implementation of DU will use one deamon per DU user on every machine. Each daemon will be responsible for providing the transparent network interface between the DU machines.
User
A person on the local machine.
Remote user
A user of a remove machine.
Message
A string that is communicated between a local user and a remote user.


Interface

DU requires very little modification to the machines on the cluster. The fact that a remote user is not really logged into a machine is not important to most communication programs since a user is represented by 1) a utmp entry and 2) a tty. Specific examples of such programs are wall(1), write(1), or cat(1).

Other manifestations of a user's presence can be found in the process table or in the open file table, although few programs access these in a direct enough fashion to warrant a very low level solution (w, ps). However, DU does not attempt to maintain compatibility with these programs.


Time Line

Hopefully, James Wang

(jwang@csua.berkeley.edu)
will be helping me out with this project.

At this point, DU's networking is not yet implemented. I'm expecting to use PVM for this purpose. A PVM implementation should be ready by Nov 18.

After then, I'm planning on having DU undergo a two week beta test period, where I will incoporate plausible RFE's.

A final release will be made by Dec. 1.