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 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 still 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.

Issuing the command `TerminalStats' (on the Terminal machine) displays three histograms of transit times for key-press events. One shows the distribution of `up-link' (terminal to host) transit times; another shows `down-link' transit times, and a third shows round-trip times. You can do all the usual Histogram things with them; try exploring the menu pop-up buttons and mouse clicks on the data area, if you refuse to read the Histograms document.

Interpreting `← RemoteTerminal.ViewHistory[]' (on the Terminal machine) makes a typescript viewer with a `History' menu button. Hitting that menu button causes the details of the recent key-press event trips to be printed. Three times are printed: the time the key was depressed, the time that event was received on the Host, and the time the reply was received on the Terminal. Then the mouse position and the event itself are printed. If you aren't running sufficiently recent software on both sides, the mouse position and event itself will look boring. The trips are remembered in a fixed-size circular buffer. Left- and Middle- clicking the History button displays the trips since the last one displayed; Right-clicking displays all available trips.

This is not optional. An area is reserved at the top of the terminal screen for display of certain information; the host machine thinks the terminal screen is correspondingly shorter than it actually is. The information displayed consists mainly of abstracts of the information presented by the transit time histograms and by the NetWatch tool; since this information is displayed on the terminal screen, it is not necessary to swap virtual terminals (which is painfully slow on certain kinds of machines) to see it. The information is updated every 15 seconds. Currently, the header line looks something like this:

The first figure is the time at which the last sampling period ended. Next is an address of the terminal machine. Next comes a summary of the round trip times: the minimum, maximum, and average over the last sampling period (15 seconds), and a running average (0.95*old avg + 0.05*new avg). Then there is a summary of received packets on the "last network": its number (among nets connected directly to the terminal machine), the incremental/total number of packets received, the incremental/total number of them that had "bad" receive status, and a running average (same decay rate) of percentage of bad packets. Finally, there are some statistics from the stream (if it's PUP) for the Viewers protocol: the incremental/total number of retransmitted, received duplicates, resource limited, received, and sent packets.

The command `Install ImagerByteSenderMonitor' (on the Host machine) will create some displays concerned with the encoding of Imager operations. As this is unlikely to be interesting to random users, I won't bother describing it.

The command `HostSpy' (on the Host machine) will create some a display concerned with the detailed operation of the stream, similar to the information at the tail of the terminal header.

The interface for this is TerminalLocation. The location of the terminal of a Cedar workstation is now variable. It may be the local hardware (previously this was the only choice). It may be across a network (the interface claims to offer PUP, XNS, and ARPA network connections; in fact, only PUP is implemented). Or it may be undefined.

The interface for this is TerminalMultiServing. It deals with the question, ``what machines, if any, am I providing terminal services for across the network?''. An older interface, TerminalServing, is also supported for backward compatibility.

The HostAndTerminalOps interface, from the HostCoordination package, provides procedures for setting and querying the protocol version ranges supported. Ignore the GetChannel procedure.

There is this more basic interface, Terminal, that exports the abstraction of multiplexing multiple "virtual terminals" onto the one physical terminal (i.e., what's managed by the previous two interfaces). However, up till now there hasn't been a good way to get all clients of this interface to coordinate properly to get the right virtual terminal `selected' for display on the one physical terminal at the right time. Now there is. The idea is to associate a priority variable with each terminal; the one with the highest priority is displayed. I've made SimpleTerminal, Idle, and RemoteTerminal subscribe to this theory.

The Inscript/Viewers conversion is carried out via a protocol that is still somewhat under development. Consequently, we are concerned with versions of that protocol. Each conversation begins with both conversants sending a range (i.e., min and max) of versions they are willing to converse in. If there is any overlap, the conversation takes place in the highest version they both can handle. If there is no overlap, both conversants stop conversing.

There is a need to document protocols (oh boy!). Here are the rules of my notation. An expression of the form "a; b" indicates that b happens after a; "a | b" indicates a and b happen in any order, even interleaved; "^ a" indicates that a is sent from the terminal to the host; "Ë a" indicates that a is sent from the host to the terminal; "l, m, ... n: T" describes data named l, m, ... n, each of type T; parentheses are used for grouping; "IF a THEN b ELSE c FI" means the obvious thing.