PseudoServerDoc.Tioga
Copyright © 1986 by Xerox Corporation. All rights reserved.
Carl Hauser, January 24, 1986 6:38:15 pm PST
Pseudoservers
Release as: [Cedar]<CedarChest6.0>Documentation>PseudoServerDoc.Tioga
Pseudoservers are server names that are translated by Cedar workstations to network file server names using the pseudoserver name table maintained in each workstation. Pseudoservers were introduced to make Cedar geographically portable and to provide continued availability of important Cedar files in the face of crashed file servers, using file replication on other servers. This document describes how and why to set up the pseudoserver name table for some common situations.
XEROX  Xerox Corporation
   Palo Alto Research Center
   3333 Coyote Hill Road
   Palo Alto, California 94304

For Internal Xerox Use Only
1. The Pseudoserver Name Tables
There are actually two pseudoserver name tables in each workstation: one used by the running system (the temporary table) and the other stored permanently on the workstation's disk (the permanent table). Changes to the temporary table are in effect until the workstation is rebooted (or rolled back), while changes to the permanent table will persist across boots, rollbacks, and poweroffs until it is explicitly changed; the temporary table is initialized from the permanent table at each boot or rollback. The temporary table is changed using the PseudoserverAdd command in the command tool; the permanent table using Iago's Set PseudoServer command or by making a Cedar checkpoint which will copy the temporary table into the permanent table.
1.1 Format of the tables
The tables each consist of an arbitrary number of <Entry> lines:
<Entry> ::= <PseudoServerName> <replication> <WriteServer> <ReadServer> <ReadServer>*
<replication> ::= -r | empty-string
<WriteServer> ::= $ | the name of an FTP server somewhere in the internet
<ReadServer> ::= $ | the name of an FTP server somewhere in the internet
Notice that the <WriteServer> and first <ReadServer> entries are required.
Example: right now my temporary table looks like
Cedar -r Cyan Cyan
Fonts -r $ cyan Luther.alpine
User Ivy Ivy
Cedar workstations should have entries in their tables for pseudoservers Cedar, Fonts, and User at all times.
1.2 Semantics of the tables
The entry for a particular name tells the Cedar system what network file servers to use when various fetch and store operations are performed on files using that name in the server part. For example, using the table above, the file
[Cedar]<CedarChest6.0>Documentation>PseudoServerDoc.tioga
would be fetched from or stored to FTP server Cyan. $ as an FTP server name in an entry indicates that the corresponding operation is not possible. In the table above, the WriteServer for the Fonts pseudoserver is $ because I should never store files on [Fonts]. Notice that there is a secondary read server for Fonts: if, for some reason, Cyan does not respond to a read request for a file named [Fonts]..., my workstation will attempt to fetch the file from Luther.alpine.
The <replication> portion of an entry indicates whether secondary read servers should be asked for a file when the primary read server says the file does not exist. If -r is present, secondary servers are not asked for the file. Without the -r, my workstation would try each of the read servers in turn until it found the file or ran out of servers.
1.3 Interaction with DF software
Bringover operations use read servers. SModel operations store to the write server and perform SModel's limited consistency checking using the read servers. VerifyDF operations verify the consistency of a DF file using write servers exclusively: the idea is that write servers contain THE TRUTH and VerifyDF is attempting to verify the consistency of that TRUTH.
2. Commands Affecting the PseudoServer Tables
2.1 Command Tool
In a command tool, the PseudoServerAdd command (alias PSAdd) and PseudoServerPrint (alias PSPrint) commands are available to change or list the temporary table. Syntax
PseudoServerAdd <Entry>
PseudoServerAdd <PseudoServerName>
PseudoServerPrint
The first adds or replaces the given <Entry>. The second removes any entry for <PseudoServerName>.
Open ]<>RemoteNames.DontDeleteMe allows you to examine the permanent table.
The Checkpoint command (not a command specifically related to pseudoservers) has the side effect of copying the current temporary table to the permanent table.
Putting the appropriate PseudoServerAdd commands in your CommandTool.NewUser and CommandTool.BootCommands user profile entries may be the best way to insure you get what you want on every machine you use.
2.2 Iago
In Iago, reached by booting with the 'L switch, the commands are: Set PseudoServer which will give a prompt to which the proper response is an <Entry> or a <PseudoServerName> each with the expected effect on both the permanent table and the temporary table; and List PseudoServers, which lists the current contents of the temporary table. The permanent table can't be examined directly in Iago, but immediately after booting, temporary=permanent.
3. Hints About Setting Up PseudoServer Tables
For workstations located at PARC CSL, a fine standard table is
Cedar -r Cyan Cyan Luther.alpine
Fonts -r $ Cyan Luther.alpine
Summoner Indigo Indigo
DATools -r Cyan Cyan Luther.alpine
User Ivy Ivy
As long as server Cyan is working this works very well and provides some protection against file retrieval failures when Cyan is overloaded. If Cyan is down, temporarily changing the table to
Cedar -r $ Luther.alpine
Fonts -r $ Luther.alpine
Summoner Indigo Indigo
DATools -r $ Luther.alpine
User Ivy Ivy
will provide better retrieval performance. (Don't forget to change back when Cyan comes up again.) Be aware that files retrieved from secondary servers (in this case Luther.alpine) may not be up-to-the-minute copies of the files on the primary server. As of now, the delay between the appearance of a file on Cyan and its arrival on Luther.alpine is between 0 and 3 hours.
Workstations in other locations should be set up with tables pointing to the local file servers containing the Cedar release and fonts and user files. Non-PARC locations will most likely not use secondary read servers.
Of course, users are free to define additional pseudoservers.