A client UAP can use a combination of the following three types of RPC on a single OpenTP1 system by using the multi-scheduler facility to request a service provided by a queue-receiving server (SPP that uses the schedule queue) on a remote node.

1. Ordinary RPC
   This method randomly selects one of the OpenTP1 systems containing a service request destination server and sends the service request to the master scheduler daemon of that OpenTP1 system.
   
2. RPC specifying multiple ports
   This method randomly selects one of the multi-scheduler daemons of all OpenTP1 systems containing service request destination servers and sends the service request to that multi-scheduler daemon.
   
3. RPC with a communication destination specified
   This method sends the service request to the multi-scheduler daemon having the port number specified in the arguments of the function dc_rpc_call_to().
   

The figure below shows an outline of an RPC that uses the multi-scheduler facility.

Figure 2-15 Outline of an RPC with the multi-scheduler facility

A service request that uses the multi-scheduler facility is scheduled only to nodes on which the multi-scheduler daemon is active. However, if there is no available OpenTP1 system on which the specified multi-scheduler daemon is active at the time the service request is issued, the service request is sent to the master scheduler daemon.

Specifying the port number of a multi-scheduler daemon when issuing a service request with a specified port number causes the RPC to schedule the service request via the specified multi-scheduler daemon.

If a service request's destination user server is blocked or terminated at the time the multi-scheduler daemon receives the service request, the service request is sent to a multi-scheduler daemon on another node that uses the multi-scheduler facility. If the specified multi-scheduler daemon does not exist on any other node, the service request is sent to the master scheduler daemon.

If a multi-scheduler daemon terminates abnormally while the system is online, the client UAP allocates an appropriate port number to the multi-scheduler daemon that terminated abnormally and restarts it. The OpenTP1 system does not go down in this case. However, if restart fails twice, the OpenTP1 system goes down.