12 Spawning Computations Remotely: Remote

# 12 Spawning Computations Remotely: `Remote`

The module `Remote` provides the class `Remote.manager` by which new Oz processes on arbitrary networked computers that also have Mozart installed can be created. Creating an instance of that class does the following two things:

- A new Oz process with a module manager `M` is created on a networked computer.

- The newly created object `O` serves as a proxy to `M`. `O` is called a remote module manager. This allows to start applications remotely that access remote resources by local system modules.

The methods of the class `Remote.manager` are as follows.

`init`

  > > `init(host:` `+HostV``<= localhost
  > > fork:` `+ForkA``<= automatic
  > > detach:` `+DetachB``<= false)`

  Creates a new Oz process at the computer with host name `HostV` (specified by a virtual string), where `localhost` is the computer running the current Oz process.

  `ForkA` (an atom) determines an operating system command to fork the remote Oz process. The atoms `'automatic'` and `'sh'` have special meaning. `'automatic'` is the default method. Other useful values for `ForkA` are `'rsh'` (remote shell command) and `'ssh'` (secure shell command).

  `sh` configuration

  If `'sh'` is used as fork method, a new Oz engine is created on the current host by using the Unix `sh` command. You can test whether this method works on your computer by:

  > `sh -c 'ozengine x-oz://system/RemoteServer.ozf --test'`

  This should be always the case, if Mozart has been installed properly on your computer. This in particular requires that `$OZHOME/bin` is in your path of executables (`$OZHOME` refers to the directory where Mozart has been installed).

  Note that the value of `HostV` is ignored (the hostname is assumed to be `localhost`), if `'sh'` is used as fork method.

  If `HostV` is `'localhost'` and `ForkA` is `'automatic'` (which is the default), then on some platforms the forked and forking processes communicate through shared memory rather than sockets, which is more efficient. The system property `'distribution.virtualsites'` carries a boolean telling whether this facility, called virtual sites, is supported in the running Mozart process; the `'sh'` fork method is used as a fall-back.

  If `HostV` is different from `'localhost'` and the method is `'automatic'` the command `'rsh'` is used. `'rsh'` creates a shell remotely by using the Unix `rsh` command, which in turn creates the new Oz engine.

  `rsh` configuration

  Remote managers with method `rsh` only work properly, if the `rsh` command has been set up properly. You can test it for the host Host by executing the following command in the operating system shell:

  > `rsh` Host`ozengine x-oz://system/RemoteServer.ozf --test`

  If the message

  > `Remote: Test succeeded...`

  is printed, your configuration is okay. This requires two things:

  1. Execution of `rsh` Host must not prompt for a password. This is usually achieved by having a special file `.rhosts` in your home directory. Each entry in that file must be a host name. For those hosts having an entry in that file, `rsh` does not prompt for a password.

     Take the following sample `.rhosts` file at the computer `wallaby.ps.uni-sb.de`:

     > `godzilla.ps.uni-sb.de
     > bamse.sics.se`

     If `rsh wallaby.ps.uni-sb.de` is executed on `bamse.sics.se` or `godzilla.ps.uni-sb.de`, then `rsh` does not prompt for a password.

     With other words, all host names that you ever want to use with `Remote.manager` should be in `.rhosts`.

  2. After the login performed by `rsh` the command `ozengine` must be executable. This should be always the case, if Mozart has been installed properly on your computer. This in particular requires that `$OZHOME/bin` is in your path of executables (`$OZHOME` refers to the directory where Mozart has been installed).

  Other commands

  Rather than using `rsh`, any value for `ForkA` is possible. In that case the following operating system command:

  > ForkA`` Host`ozengine x-oz://system/RemoteServer.ozf --test`

  should print the message

  > `Remote: Test succeeded...`

  A prominent example of a different command and a very recommended substitute for `rsh` is `ssh` (secure shell) which is a more powerful and secure replacement for `rsh`. For more information on `ssh`, see `www.ssh.fi`.

  If `DetachB` is `false`, a non-detached process is created. A non-detached process terminates as soon as the creating process does (think of crashes, there will be no orphaned processes). The lifetime of a detached process (that is, `DetachB` is `true`) is independent of the creating process.

  On some platforms (in particular on `solaris-sparc`) the operating system in its default configuration does not support virtual sites efficiently. Namely, the Solaris OS limits the total number of shared memory pages per process to six and the number of shared memory pages system-wide to 100, while each connected Mozart process requires at least two shared memory pages for efficient communication. Please ask your system administrator to increase those limits with respect to your needs.

  The Mozart system tries to do its best to reclaim shared memory identifiers, even upon process crashes, but it is still possible that some shared memory pages become unaccounted and thus stay forever in the OS. In these cases please use Unix utilities (on Solaris and Linux these are `ipcs` and `ipcrm`) to get rid of them.

`link`

  > > `link(url:``+UrlV``` `ModuleR``<= _)`

  > > `link(name:``+NameV``` `ModuleR``<= _)`

  Links the module identified either by a url `UrlV` (a virtual string) or a module name `NameV` (a virtual string). Returns a module `ModuleR`.

  For explanation see Chapter 2.

`apply`

  > > `apply(``+Functor``` `ModuleR``<= _)`

  > > `apply(url:``+UrlV``` `+Functor``` `ModuleR``<= _)`

  > > `apply(name:``+NameV``` `+Functor``` `ModuleR``<= _)`

  Applies the functor `Functor`, where the url `UrlV` (a virtual string) or the module name `NameV` (a virtual string) serve as base url for resolving the functor's import.

  For explanation see Chapter 2.

`enter`

  > > `enter(url:``+UrlV``` `ModuleR``)`

  > > `enter(name:``+NameV``` `ModuleR``)`

  Installs the module `ModuleR` under the url `UrlV` (a virtual string) or the module name `NameV` (a virtual string).

  For explanation see Chapter 2.

`ping`

  > > `ping()`

  Raises exception if remote process is dead. Blocks until executed by remote process.

`close`

  > > `close()`

  Performs a controlled shutdown of all remote processes (for a discussion of controlled shutdown see Section 2.2.1 of ``Distributed Programming in Mozart - A Tutorial Introduction'').

## 12.1 Process Termination and Remote Managers

Here are some tentative explanations of what happens to the children of a process when the latter is terminated.

- if a process is properly shutdown, then detached children survive and non-detached children are terminated.

- if a process is killed with `kill -INT`, then its children are terminated whether they are detached or not.

- if a process is killed with `kill -KILL`, then no child is terminated because the proper shutdown sequence is not executed.

- if a process is killed by typing C-c, then the `INT` signal is sent to the process group to which both parent and children belong.1 Thus all are terminated.

1. This is the case in the current regime, but could be changed if desired