While cross-application RPC can be achieved between script applications, it is in standard applications that it is most useful. In standard applications, RPCs are performed between services. In cross-application RPC in standard applications, services of the same name in different applications are maintained in synchronization.
One application houses the master service, and the other applications house the slave services. The application housing the service with identical "RemoteGUID" and "LocalGUID" variables is the master. All other applications house slaves. There can be many different applications housing slaves, but only one application houses the master.
This terminology (master and slave) has been selected to try and avoid confusion between the terms "server" and "client". In cross-application RPC, we define the term "server" consistently with non cross-application services as being the only service instance that currently has servership of the service. By definition, this is the "master service".
Therefore, exactly one instance of the master service can be a server. All other instances of the master service are clients. All instances of the slave services are clients to the current master service server. This is depicted in the following diagram, where each arrow points to the server instance.

As reflected in the above diagram, each application has a service named "Service 1" and a service named "Service 2". These two services are completely independent between the applications; in other words, Application A's Service 1 has no relationship with Application B's Service 1. Service "Sample", however, is a cross-application service. Application A houses the master service. Application B houses a slave service. Application A on workstation FRED is the current server instance of this service. If you were to stop Application A on workstation FRED, servership of Application A would transfer to workstation JOE (on the assumption that the server list for all Application A services is FRED, followed by JOE). Application B's "Sample" service will follow the master service and both application B's "Sample" service instances will become clients to Application A's "Sample" service on workstation JOE.
Note that Application B's "Sample" service can never be a server instance, hence the term "slave".