Efficient Short Remote Operations (ESRO) provide an efficent mechanism for realization of Remote Procedure Call. This document specifies many aspects of ESRO including:
The overall model of ESRO is similar to and consistent with many existing protocols. ESRO's distinguishing characteristic is efficiency.
A brief comparison of ESRO and Remote Procedure Calls [7] and Remote Operation Service Elements [1] follows.
Remote Procedure Call (RPC) is specified in [7] (RFC-1831) and [6] (RFC-1833).
RPC specifications define a remote procedure model that is essentially same as ESRO. RPC's notation uses a syntax quite different from that of ESRO. RPC can rely on a connection oriented or connectionless transport mechanism. When using the connectionless mechanism, the retransmission and reliability issues are considered beyond the scope of the RPC specification. RPC is usually used in combination with External Data Representation, XDR [8] (RFC-1832).
ROSE is specified in [1] and [2]. The service definition for ESRO Service (ESROS) specified in this document is similar ROSE's Notation. The Notation specified in this document for ESROS is similar ROSE's Notation. The ESRO protocol specified in this document is very different from the ROSE protocol [2].
The operation model for ESRO Service (ESROS) is based on Remote Operations Services Element (ROSE) in [1]. In ESROS model both entities can invoke operations.
ESRO protocols can accomplish short operations with much less overhead than ROSE.
ESROS provides a service which supports interaction of applications based on a remote operation model. A Remote Operation is invoked by one entity; the other entity attempts to perform the Remote Operation and then reports the outcome of the attempt. The ESROS protocol is designed such that it could support many applications.
ESROS provides for performance of operations between two peer sublayers. Users of the ESROS assume the roles of invoker and performer which invoke and perform the operations respectively. An ESROS-User can assume both roles and be an invoker for some operations and be a performer for other operations. The performer is expected to report either the result of the operation or an error. A result reply is sent to the invoker if the operation is successful, and an error reply is sent if the operation is unsuccessful. If the performer is unreachable, the ESROS sends a failure indication primitive to the invoker.
Operations are asynchronous and the invoker may continue to invoke further operations without waiting for a reply. Synchronous or serialized operations are also supported as a subset and a special case of asynchronous service. By default the ESRO service provider on both invoker and performer sides supports the asynchronous operation invocation. However, if one side is to support only serialized (synchronous) mode, it should be in agreement with the peer side.
ESROS has no authentication mechanism. Authentication is the responsibility of the performer (which is outside of the scope of ESROS) and the performer is not expected to honor the invoker when it is not authenticated.
The ESROS operation model is represented in Figure 1. In this example, the ESROS User on the left is the Invoker and the ESROS User on the right is the Performer. The Provider is the entity providing a service to the layer above it.
