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.