Server List Consistency

It is important to ensure that each machine that can be a server for a service has a consistent list of server machines. Failure to observe this will result in sporadic service synchronization failure. Note the wording of this statement. A machine that can never be a server, i.e. can only be a client can have a different server list from the server. This is the method used to implement clients-of-clients. However, a machine that can be a server must have a consistent list of servers specified for that service. Once again, note the careful wording. Consistent does not mean identical, but if a server has a different list of machines from another server, they are only allowed to be different by omitting some machines from the tail of the list.

For example, the server lists for the Sample service could be configured as follows:

<?xml version="1.0"?>
<RPC>
   <ServerLists>
      <Service Name="Default Server Lists">
         <Workstation Name="Default for Workstations">
            <Server>FREDSPC</Server>
         </Workstation>
      </Service>
      <Service Name="Sample">
         <Workstation Name="Default for Workstations">
            <Server>FREDSPC</Server>
            <Server>JOESPC</Server>
         </Workstation>
         <Workstation Name="GONZOSPC">
            <Server>FREDSPC</Server>
            <Server>JOESPC</Server>
            <Server>GONZOSPC</Server>
         </Workstation>
      </Service>
   </ServerLists>
</RPC>

You may wish to use such a configuration if machine GONZOSPC was in a remote location from FREDSPC and JOESPC. Then, if the communication medium between the two locations is broken, the area without GONZOSPC [the "Default for Workstations" list for the "Sample" service, used by FREDSPC and JOESPC] will use the higher available server of FREDSPC and JOESPC, whereas the area with GONZOSPC will lose communication with FREDSPC and JOESPC and so will fall back to GONZOSPC.

Of course, precisely the same effect would be obtained by having each machine use the first list, but this method reduces communication traffic between the two areas slightly, by not having to have FREDSPC and JOESPC examine the server status of GONZOSPC. It also prevents FREDSPC and JOESPC from every synchronizing to GONZOSPC. If GONZOSPC is isolated from the other two, higher servers, it will re-synchronize to the higher order servers when communication is restored, destroying the local state of the service on GONZOSPC.