The Cedar Remote Terminal makes it possible for one machine (called the "terminal" machine, or the "server") act as a terminal for another (called the "host" machine, or the client). In the context of the HomeComputing project, the terminal machine would most usefully be at home, and the host machine in the office. Each of the four combinations of the Host and Terminal being PCedar and DCedar works.

In PCedar, there is a packaged world, RemoteViewersHostWorld, that contains all the Host side stuff; RemoteViewersHostWorld is like X11ViewersWorld and RawViewersWorld, differing in the way terminal services are acquired. Also, there is a RemoteViewersHost Commander Command; again, it is analogous to the RawViewers and X11Viewers commands. In DCedar, boot with the standard bootfile, using the J switch; this will do a full boot but use Remote.loadees instead of the usual Basic.Loadees. If you roll your own loadees, be sure to start from Remote.loadees, which you can find with `OpenR Remote.Loadees'. Alternatively, you can `Install RemoteViewersHost' (in a directory into which you've BroughtOver the public parts of RemoteViewersHost.DF). Rollbacks will screw you, because of a deadlock that occurs in the bootfile when trying to open a remote Simple Terminal to an ARPA location.

The terminal side can be loaded into any Cedar world.

In PCedar, the Host side of the Cedar Remote Terminal is implemented by the Cedar packages HostCoordination, ImagerSender, ViewerContexts, and RemoteViewersHost; the Terminal side is implemented by the Cedar packages TerminalCoordination, ImagerReciever, and RemoteViewersTerminalByViewer.

Each Host sends its output to a set of terminal locations. A terminal location is either undefined, local, or a remote terminal location. The undefined terminal location is used when a Host is not connected to any terminal. The local terminal location is not used in PCedar; in DCedar, it's used by a Host to indicate that the locally attached screen and keyboard are to be used. A remote terminal location consists of a machine and a pair of port numbers. The textual form of a remote terminal location is, in general, "<machine>-<protocol>:<control Port>&<viewers Port>"; the "&<viewers Port>" may be elided when the viewers port is 58811 (which it always is, at the moment); the ":<control Port>" may be elided when the control port is 58813 (which it always is, at the moment) and the <machine> and <protocol> contain no colons; the "-<protocol>" may be omitted when the protocol is ARPA (which is the only one supported, at the moment) and <machine> contains no dashes.

In DCedar, secondary terminal locations are not supported; the network requests to add secondary terminal locations, and all Host-side Commander commands, are not understood.

Each Host takes its input from a single terminal location. This is called the primary terminal location. Output goes to both the primary terminal location and the secondary terminal locations. A rudimentary form of floor control is available through a Commander command on the Host side.

A Cedar world with the Terminal side loaded can instantiate multiple Terminals; each Terminal serves at most one Host. There can be multiple Terminal worlds on a machine (in PCedar).

Each instantiated Terminal is either connected to a particular Host, or is unconnected. In PCedar, the textual specification of a Host is, in geneeral, "<machine>-<protocol>:<control Port>"; the ":<control Port>" may be elided when the control port is 58812 and the <machine> and <protocol> contain no colons; the "-<protocol>" may be omitted when the protocol is ARPA (which is the only one supported, at the moment) and <machine> contains no dashes. In DCedar, a host address is given as a protocol family followed by an address or name in brackets. Case is significant in the protocol family name. Examples are "pup[McCormick]", "pup[3#265#]", "xns[Tallahatchie]", "xns[0-003.2-857-435-576.]", "arpa[Skipjack]", and "arpa[13.0.12.200]".

There can now be multiple Host worlds on a machine (in PCedar). You can determine which control port a world is listening on by watching for a message of the form "At <date and time>, Host(Terminal) Control listening on TCP port XXX" from the host world as it starts up. Also, Host worlds register themselves with the Local Registry; you can query the Local Registry on a machine with the `lrls' UNIX command.

Even an unconnected Terminal maintains a window (either a Viewer or an X window). This is because a Terminal's window has buttons to control the Terminal's size, which should be set before a session begins because the Host side only notes the Terminal's size at the start of sessions.

A Host side and Terminal side are said to be connected when (1) the Terminal side appears among the primary and secondary locations of the Host, and (2) one of the Terminals at the Terminal side is connected to the Host. The Host and Terminal software strives to keep conditions (1) and (2) either both true or both false, but disparities can arise nontheless (usually as a result of one side or the other terminating (in the UNIX sense)). There are commands to query and alter the connection state.

A session is an open network stream between a Host and a Terminal. Due to the vagaries of network streams, and some other things, many sessions may come and go for a single connection.

A Host will not accept a request that comes into its control port to change its primary location unless the primary location is currently undefined. Each host maintains a state bit called observers allowed. When this bit is false, a request that comes into the Hosts's control port to add a secondary terminal location will be rejected; when the observers allowed bit is true, such requests will be accepted. There are Commander commands to query and alter this bit.

The above is a terribly crude approximation to what we really want. Unfortunately, I'm not sure exactly what it is we really want. What kind of credentials (XNS, UNIX, Kerberos, ...) should we use? Should we strive to not send passwords in the clear over the network? (and if so, how?)

With PCedar Host and Terminal, there is one way: make the advisee a secondary terminal location.

With DCedar Host and Terminal, there are two ways.

In the first way, the advisee sets the BOOLEAN variable RemoteViewersHost.cc to TRUE (after loading the Remote Host software, of course), and then uses the RemoteTerminal/RemoteHost system is used in the normal fashion. This involves the advisee idling, and the advisor remotely logging in to the advisee's machine. Because RemoteViewersHost.cc is TRUE, output goes to both screens, and the advisee can see what the advisor is doing.

The second way is a special perversion of the RemoteTerminal mechanisms, and does not involve changing who's logged in. Both the advisor and the advisee each issue a command to set up the advice session, and they both issue a command to close down the advice session. Checkpoints should not be made during advice sessions. An advise session is started by the advisor issuing the "Advise AdviseeMachine" command, and then the advisee issuing the "AdviceFrom AdvisorMachine" command, in that order. Note the spelling, and that the appropriate machine names have to be substituted. While this connection is being set up, the advisor may temporarily see a screen full of trash; more likely he will temporarily see a misleading screen (e.g., one that looks like his last use of the SimpleTerminal, which was probably to log in). During the advice session, the advisee also gets to see output on his screen, including cursor tracking. To close down the session, the "StopAdvise" command must be executed on the advisor's machine. To do this, the advisor must manually swap virtual terminals (with control-leftshift-rightshift) back to his native terminal, and issue the command. Also, the "RejectAdvice" command may optionally be executed on the advisee's machine, either before or after the advisor does "StopAdvise" (note that if it's done before, it must be done by the advisor, because he's the one driving the advisee's machine).

There is more than one way to implement a Terminal. In PCedar, there are two ways: by an X window (using the bitmap-oriented implementation for Imager contexts), and by a Cedar Viewer. In DCedar, there are two ways: by a Terminal.Virtual, and by a Cedar Viewer. A user must indicate which style of Terminal implementation is desired. This is done by issuing a command that both indicates the desired implementation style, and loads all the stuff necessary to be a Terminal side. In Cedar10, those commands are TerminalByX and TerminalByViewer; PCedar2, those commands are TerminalByX11 and TerminalByViewer; in DCedar, those commands are TerminalByVirtual and TerminalByViewer.

The TerminalByX style creates X windows whose application (in Cedar XTk terminology) is ``X11RemoteCedarTerminal''. You can thus control where the X window appears by issuing the command

The TerminalByViewer style creates Cedar Viewers whose painting is synchronized with the Host's output in certain ways. Precisely, every time the Host invokes a context's DoWithBuffer method, the Terminal Viewer not finish a Paint until that DoWithBuffer is finished; also, no Paint will finish while there are buffer names that have been given to SaveBuffer but not yet DiscardBuffer. These synchronization restrictions exist because the Imager.Context method suite makes it impossible to efficiently layer Contexts without them. What this means to users is that a Terminal viewer will be locked for the duration of every: (1) use of a pop-up menu, and (2) repaint by Tioga of a line of a document.

In PCedar2 and DCedar*, Remote Terminals respond to destruction by creating a new terminal. This is so you can set the size of the terminal before making a connection; you want to do this because the Host side only notes that Terminal's size at the beginning of a session.

In Cedar10, terminals are not automatically created when one is destroyed (nor when the relevant code is first run). Instead, the implementation-style-setting commands (TerminalByX, TerminalByViewer) cause an(other) terminal of the appropriate style to appear.

In the Viewer and X terminal styles, there is a distinction made between the current size of the terminal window and "ideal" size of the "terminal". The latter is reported to the host as the size of the terminal; the former is under control of the appropriate window manager on the terminal machine.

The RemoteTerminal protocol only communicates the terminal size at the start of each session --- no changes can be reported to the host during a session.

You can specify the initial "ideal" size with Cedar User Profile entries:

The X style terminals are also sensitive to X resources. If you specify the "geometry" resource (with the usual format and interpretation) for a widget whose class name is "X11RemoteCedarTerminal", this will be used instead of the Cedar profile information.

If no preferences are specified in the profile, a style-dependent default choice will be made. For the X style, it is 100 pixels (in both dimensions) less than the terminal machine's screen size. For the Viewer style, it is 700 wide and 750 high.

The Viewer style terminals can have vertical scrolling disabled. This prevents the annoyance of accidentally scrolling the terminal when you just missed clicking at the left of the remote area. The Viewer style terminals have a button that toggles the ``scrollability'' state bit. It is labelled either ``-> Scrollable'' or ``-> Unscrollable'', depending on which transition would be caused by a click. The initial state can be specified in your Cedar User Profile:

The output stream will be compressed with the Fiala/Greene `B4K' method, iff both sides are willing. Both PCedar sides default to willing, and both DCedar sides default to unwilling. There are Commander commands to query and change whether each side is willing. When the Terminal is a D-machine wimpier than a Dorado, compression is not worth the trouble, even over a 9600-baud link. In all other cases, compression is worthwhile over a 9600-baud link. The compression factor varies from about 3 to about 10, depending on the Imager operations used and their arguments.

In PCedar, a Terminal has one screen, which is either color or black-and-white, depdending on the X server or frame-buffer ultimately used; a Host also has one screen, and does not much know or care whether color is supported (there is one small exception, sometimes gotten wrong, for the background color for Viewer captions).

In DCedar, a Host has one or two screens: a main black-and-white one, and perhaps a secondary color one. The pixel depth, and color imaging method (dither, threshold), can be changed while a Cedar world is running. A TerminalByVirtual also has one or two screens; a TerminalByViewer has one screen.

If the Host and Terminal both have two screens, the Terminal tries to configure its second screen like the Host's. If the Host has multiple screens and the Terminal has one, all imaging is done on the one screen of the Terminal. If the Temrinal has more screens than the Host, the unneeded screens are not used.

A DCedar host sends the fast-mouse parameters and screen escapes to the Terminal; a PCedar host does not. A DCedar Terminal obeys any received fast-mouse parameters and screen escapes; a PCedar Terminal ignores them.

Watch the SystemScript for informative and debugging messages.

The host machine will go idle whenever it doesn't know where its terminal is. In particular, whenever you hard-boot it, it doesn't know where its terminal is.

The location of the terminal can change only when the host is idle. While in idle, if a key is hit, the location becomes the local hardware. If, while idle, an offer of terminal services comes in over the network, it will be accepted.

In general, both sides (host and terminal) of this software try to show the appropriate screen to the user. If this fails, try manually swapping screens (with control-shift-shift).

You can disconnect by idling the host. The host will drop the connection if it misses communication with the terminal long enough for PUP streams to decide it's really gone (on the order of a minute); note that the host does not miss communication while it is doing low-level things like inloading and outloading memory (e.g., for a checkpoint, rollback, or boot). You can break the connection from the terminal side by issuing the "Disconnect" command.

You can do full boots, and use Iago, and make checkpoints, and all that stuff, remotely --- except when using ARPA (ie TCP/IP) protocols, due to misfeatures in the bootfile. The only things you can't do remotely are hit the physical boot button and hold down keys to indicate boot switches.

Viewers is automatically told to assume the size of the black-and-white display is that of the terminal's viewport.

There are three different network protocols involved in the RemoteTerminal system (TerminalCoordination, SimpleTerminal, and Viewers). All are subject to further development. To help avoid confusion, there is a little version checking done whenever such a network stream is opened. A version is a small integer (e.g., 10). Each side (host and terminal) knows the range of versions that it is willing to use, and the conversation begins with an exchange of these ranges. If there is any overlap, the conversation takes place in the highest version of the protocol that both sides are willing to use. If there is no overlap, the conversation terminates. If you're lucky, there'll be messages posted in the MessageWindows of the host and terminal explaining that this has happened, and giving the protocol version ranges that the two machines are willing to use. Knowing these ranges tells you how to fix the problem. Update one or both of the machines so there's some overlap in the versions they're willing to use. The latest versions of the host and terminal software are willing to speak the following versions:

On a running system, you can determine what versions the software you're running are willing to use by issuing the `HostVersions' and `TerminalVersions' commands.

Things are chaotic. The Cedar packages have variants that don't use certain of the transport protocols. The CedarChest packages consult CommDriverRegistry and use whatever's available.

There are five sets of monitoring tools available for extracting information from the RemoteTerminal.

The first three use data collected by a special feature. When the host machine receives notice that a key has been depressed, it sends a special acknowledgement, which includes the time, back to the terminal machine. In this way, we get a time-stamped round-trip report.

There are a few interfaces introduced to deal with new concepts.

There are six package roles: {coordination, simple terminal I/O, and viewers I/O} on each of {Host, Terminal}. Here are the packages that fill them (they all live on Cedar, except those concerning Terminal or Viewers I/O --- they live on CedarChest):

There is one DF for each Host role. The two most primitive (HostCoordination and RemoteSimpleHost) Host packages are built into the bootfile. The other, RemoteViewersHost, is loaded either by booting with the J switch (which means to use the `Remote.Loadees' instead of the `Basic.Loadees') or by issuing the command `Install RemoteViewersHost' (in a directory into which RemoteViewersHost has been BroughtOver).

On the terminal side, things are more complex, because I plan to have alternate implementations of how to be a terminal. RemoteTerminal is at the top of the Terminal side's pyramid; it currently has wired into it the fact that RemoteViewersTerminalByVirtual provides the (currently) only way to implement a Viewers terminal.