The Virtual Laboratory is not confined to individual machines and local file systems. The user may also invoke browsers or hyperbrowsers on different data base hierarchies, on the same local area network or over the Internet. Most operations available locally can be also performed on remote data bases, provided that proper permissions are given by their owners. For example, the user may browse a remote data base of objects, experiment with a remote object (which is transferred to the local lab table for fast experimentation), or copy objects and object hierarchies between various data bases. These transfer operations are performed by dragging and dropping, or copying and pasting, between browsers open on different data bases.
Access to remote data bases is accomplished using the remote access server, which runs as a daemon on a remote machine, and performs operations on behalf of the client browser. The underlying mechanism can be viewed as a simplification of UNIX Remote Procedure Calls. The format of messages exchanged between the browser and the remote access server has been optimized to reduce response times. For example, the browser can ask the server for information regarding an entire subhierarchy of objects in a single message, and this information is also returned in a single message. The communication flow between two VLAB applications and RAserver is graphically illustrated below:
When a VLAB application needs to access a database on a remote computer, it does so through raserver running on the remote computer. When the VLAB application has a direct access to the database, it does not go through raserver.
The level of access to remote files granted to VLAB applications connected to raserver is determined by two factors. First, since raserver is run as a user's process, raserver cannot provide functions on files that would not be granted directly to the user that invoked raserver. The second factor that determines file access permissions is the level of access granted to the remote user, as specified by the user running raserver.
The user running raserver can set up two different levels of access for each remote user: read-only and read-write. When a new VLAB application connects to raserver, it has to identify its user by a login and password. raserver then looks up the corresponding account in its own database and determines its level of access. If the account is associated with read-only level of access, raserver will refuse to perform any operation which would result in modifications to the filesystem.
To illustrate how the level of file access using raserver is determined, consider the following example. User A has set up two accounts for raserver: account one with write permissions, and account two with read-only access. There are three files on user A's computer: file1, file2 and file3. User A has read/write access for file1, read-only access for file2 and no access to file3. VLAB applications connected to RAserver using account one will have the same permissions to all three files as user A: read/write for file1, read-only for file2 and no access for file3. VLAB applications connected to raserver using account two have read-only access for file1 and file2, and no access for file3. Write access for file1 has been effectively removed for all VLAB applications connected to raserver using account two.
The user wishing to provide remote access to his/her databases invokes RAserver in the daemon mode, by issuing the following command at the shell prompt:
raserver
RAserver then listens for connections from VLAB clients, establishes multiple connections and provides services to all authorized connections.
To invoke RAserver in setup mode, the following command is typed at the shell prompt:
raserver -pe
When the user starts RAserver in the setup mode, RAserver presents the user with a command line interface for editing user accounts. At this prompt commands and their parameters can be entered, requesting information or changes to the users accounts. The following commands are available: quit, help, ls, add, del, chlog, chpass, toggle. Their meaning and syntax can be obtained through the on-line help (by typing help).
RAserver stores the account information about remote users in the account file determined at runtime by evaluating the following expression:
$VLABCONFIGDIR/rapasswords
The account file is accessed by RAserver in both of its modes. If this file does not exist, RAserver in setup mode will automatically create an empty one. If RAserver in daemon mode is invoked while there is no rapasswords file, the user is appropriately notified and RAserver automatically starts setup mode. The format of the file can be seen here.
Originally, RAserver was implemented to operate at the level of individual files, although its functionality has been later extended to add operations which perform requests at the level of VLAB objects. This extension can perform certain operations more effectively, for example it is possible to get information about all extensions of an object in a single request.
RAserver spawns a separate process for each new client. This multiprocess
implementation of RAserver provides a clean design, consistent with the
UNIX philosophy of multiprocessing. It has very important advantages over
a single-process solution. First, if a process serving one client crashes,
the other clients will be unaffected, since each process runs in a separate
address space. Secondly, the utilization of the server's resources will
be higher than with a single-process implementation. Most of the requests
made to RAserver daemon require disk access services. In a single process
implementation, if one of the clients requested a lengthy operation, the
rest of the clients would have to wait until such an operation is finished.
This problem is avoided in a multi-process implementation because of the
multitasking nature of UNIX operating systems. Last, multi-process implementation
can automatically take advantage of multi-processor workstations, where
each process could be run on a separate processor.