INTRO(1) INTRO(1)
NAME
intro - introduction to the Octopus
DESCRIPTION
The octopus is a system built to achieve a distributed com-
puting system by using a centralized one. The idea is that
all the applications run at a single, central, computer.
Users connect devices found in the Internet (probably
attached to full-fledged computers) to their (remote) cen-
tral computer, so that they do not have to carry hardware
around, yet they see a single, homogeneous, reliable system.
Even while using a distributed, heterogeneous, and dynamic
environment.
The octopus inherits most ideas from Plan B and therefore
from Plan 9 and Inferno. Thus, it would be appropriate to
read the intro(1) manual page from Inferno before proceeding
with this one. See also http://lsub.org/ls/octopus.html.
The octopus mounts file systems across network links with
bad latency, that is, links exhibiting RTT times from 50 to
120 milliseconds. Such links are used to connect devices
(found in the Internet) to the central PC.
A machine providing one or more devices to the central com-
puter is known as a terminal. The central computer is known
as the personal computer or the PC, and provides a central
name space to terminals. Both the PC and terminals run file
servers to provide services to be mounted on the other end
of the link. Terminals and PCs cooperate using the Op file
protocol, described in section O of this manual. Only in
particular cases do they use Styx to talk to each other.
Usually, two (network) connections are set up between the PC
and a terminal in the octopus. In one of them, the PC is a
client (for terminal devices) and the terminal is a server.
In the other, the roles are exchanged. But note that for
the octopus implementation in Inferno, Styx is used within
the central computer, and also within any terminal using
Inferno. However, servers in the terminal speaking to
clients in the central computer do so using Op, and the same
happens for exporting the central computer name space to
terminal devices.
The computing environment as seen by the user is that of the
central computer. In the current implementation, it would be
an Inferno computing environment or perhaps a Plan 9 comput-
ing environment. It depends on which machine is designated
as the central computer and which software does it run.
INTRO(1) INTRO(1)
The central computer is implemented by an Inferno system
running the o/pcrc start-up script, described in pcrc(1).
This script starts listeners providing network services
expected at the PC, and makes the PC able to import terminal
devices and to export a central name space. The central com-
puter adapts to changes in device availability. This way,
the central name space changes depending on the set of
devices available and the name space as configured by the
user. See mux(4) and netget(1) for a description of what
this means.
A terminal in the present implementation is an Inferno sys-
tem running the o/termrc start-up script. But note that any
machine following the conventions for terminals would be a
terminal. In particular, a machine exporting through Op one
or more devices would be a perfect terminal. User I/O hap-
pens at terminals, the central computer runs applications
instead.
In the implementation for Inferno, /dis/o contains portable
(Dis) binaries for the octopus. This manual includes just
those manual pages that must be added to an Inferno user's
manual to convert it to an Octopus user's manual. Section 1
describes commands implemented for the octopus, section 2
describes Limbo modules for the octopus, section 4 describes
file servers, and section O describes the file protocol used
to glue the system together. But note that usually, all file
servers in the octopus are Styx (i.e., Inferno) file
servers. Only oxport(4) and ofs(4) need to speak Op, when
Inferno is being used on both terminals and the PC.
On each manual page, the Platform section describes which
platform the command or module is meant for. This is needed
because some commands may be implemented only for certain
hosts or terminals. When this section is missing, the com-
mand or module is considered portable enough to run at any
supported platform.
SEE ALSO
intro(O), http://lsub.org/octopus, and various papers men-
tioned there.