RPC Internal Routing

RPC Manager absolutely guarantees that a sequence of RPCs generated on one machine, will be routed to the next consumer of the request in the order that the RPCs were generated.

What this means to the programmer is that two consecutive RPCs that are generated on the same machine as each other and are to execute on the same target machine will always be executed in the order in which they were generated. This assumption promotes robust algorithms when programming for a distributed system. This assumption is necessary for the correct operation of services and other parts of the RPC subsystem.

In the interests of preventing one large RPC blocking others, the version 4 RPCManager only preserves this rule within a service or between directed RPCs. An RPC issued from service A is not guaranteed to execute before an RPC from service B, even if it was issued first. Two RPCs within service A are, however, guaranteed to execute in the order they were issued.

To achieve this, RPC Manager serializes all RPC requests through a single FIFO queue on the local machine. The serialization includes not only locally generated requests, but also requests that arrive from other machines.

RPC requests are then removed, one at a time, from the serialization FIFO and examined to determine:

• If the request should be forwarded to other RPC manager instances in the distributed system. There the request will be processed in an identical fashion.
• If the request should be executed on the local machine.

In versions of RPCManager prior to version 4, each MachineNode contains a transmission FIFO, ensuring that RPC requests are delivered to the remote machine in the strict order that they were generated on the local machine.

From version 4 onwards, each MachineNode contains one FIFO for directed RPCs and one FIFO for each service that is registered with RPCManager.

MachineNode selects the SocketNode to encode and transmit the request, according to the methods outlined in the section on Multi-homed Systems.

Each SocketNode\Receiver module accepts and decodes the incoming requests and places them on the local serialization FIFO for processing.

The flow of RPC requests through the RPC subsystem is depicted in the following diagram, where the parenthesized names are the RPC Manager module that performs the operation:

The settings that were provided by the original \RPCManager\Send() subroutine call provide the initial routing information. RPC Manager may modify this information before queuing the RPC request on a transmission FIFO, so that the receiving RPC Manager will make the correct decisions about any further routing. Further routing only occurs in the "client of a client" case (see the section Clients of Clients).

To achieve this, the RPC request carries a set of "routing flags" with it, which are transported across machines. These flags and the routing strategy are discussed in section RPC External Routing.

With the Diagnostics window’s "Detail Trace" button pressed, the routing of RPC requests between the serialization FIFO and the transmission FIFOs are revealed. A request received from a remote machine is diagnostically recorded when it is posted to the serialization FIFO, when it is removed from the serialization FIFO for processing and when it is queued on each transmission FIFO.

Without this button pressed, an RPC from a remote machine will be recorded only when it is removed from the serialization FIFO or when it is queued on each transmission FIFO.