RPC High Level Design

RPC Manager is composed of a number of layers, each consisting of a VTScada object instance. An illustration of the layers of which the RPC Manager follows:

Machines participating in the distributed domain communicate using sockets over TCP/IP. Each machine can be identified by any of the names by which it is known, or any of the IPs by which it can be addressed. RPC Manager on each machine runs a socket server which listens for socket connection requests on a specific port. The port number is configurable and defaults to 5780.

The RPC Manager layer "nearest" the sockets consists of SocketNode object instances. There is one SocketNode instance for each IP address with which the local RPC Manager is communicating. The next layer up consists of a set of MachineNode object instances. There is one MachineNode object instance for each machine participating in the distributed domain. Where all machines within the domain have only one IP address, there will be a one-to-one correspondence between MachineNodes and SocketNodes. However, where a machine has more than one IP address (otherwise known as a multi-homed system), there will be more than one SocketNode for the machine’s MachineNode.

SocketNode provides a reliable error-free transport for RPCs via a specific IP address. MachineNode provides the buffering and routing of RPCs to its sub-ordinate SocketNodes.

On a single-homed system, the RPC transport will fail when a MachineNode’s single sub-ordinate SocketNode is unable to reliably transport RPCs to the intended destination. In a multi-homed system, the RPC transport will fail only when all sub-ordinate SocketNodes are unable to reliably transport RPCs.

To identify the integrity of an RPC transport to higher layers, MachineNode maintains a session identifier (SID) (see Session IDs) for each application instance that is running on the remote machine associated with that MachineNode.

The SID is opaque data. You should not try to interpret the contents of it, just accept that the SID is unique to the reliable RPC transport to/from the multi-server application instance. If the transport fails, the SID will change to a new, unique value. If the multi-server application instance is terminated and a new one started, the SID will change to a new, unique value. If no RPC transport can be obtained to a specified multi-server application instance, (either because the application is not running or communication has failed), the SID will have a unique value, defined by RPC Manager as RPC_NO_SID. That the SID remains at an unchanging, valid value is an absolute guarantee that the same multi-server application instance is being communicated with and that no loss of RPCs is occurring.

The next higher layer, which manages service instances, uses the SID to control service synchronization. A TagNode object instance exists for each service instance that is running on the local machine. Each TagNode has a number of TagServerNode object instances, one for each machine that can be a server for the service (this may include the local machine). The TagServerNode remembers the SID that it obtains when it establishes contact with the corresponding machine and uses any change in the SID to detect loss of reliable communication with the potential server. Any change in SID, for the TagServerNode that corresponds to the server instance, will require the TagNode to initiate service re-synchronization. In this way, any loss of the information flowing via RPCs from a server to a client is detected and the service automatically re-synchronized to ensure that the client is not "out-of-step" with the server. This process is termed "service synchronization".

VTScada contains a variable, located in the root (system) scope that can be used as a prefix to access any of the methods and public data that RPC Manager provides. This variable is \RPCManager. You will see this prefix used repeatedly throughout the remainder of this document.