rfc2188.txt
来自「RFC 的详细文档！」· 文本 代码 · 共 1,709 行 · 第 1/5 页
TXT
1,709 行
ESROS ------------------- ------------------- ESROS
User | Layer above ESROS | | Layer above ESROS | User
(Invoker) | | | | (Performer)
------------------- -------------------
^ | | ^
| | | |
v | | v
ESROS ------------------- ------------------- ESROS
Provider | ESROS | | ESROS | Provider
------------------- -------------------
| |
| |
| |
------------------- -------------------
| UDP | | UDP |
------------------- -------------------
_ _/
_ _/
_ . _/
_ . .* . _/
. * .* .
* . *
Figure 1: ES Remote Operation Model
Banan, et. al Informational [Page 7]
RFC 2188 ESRO September 1997
Invoker Performer
ESRO SAP ESRO SAP
| |
| |
ESROS-INVOKE.req. | | ESROS-INVOKE.ind.
-------->-----------| |-------->---------
| |
ESROS-INVOKE-P.conf.| |
--------<-----------| |
| |
| |
| |
ESROS-RESULT.ind. | | ESROS-RESULT.req.
--------<-----------| |--------<---------
| |
| | ESROS-RESULT.conf.
| |-------->---------
| |
| |
ESROS-ERROR.ind. | | ESROS-ERROR.req.
--------<-----------| |--------<---------
| |
| | ESROS-ERROR.conf.
| |-------->---------
| |
| |
| |
| |
ESROS-FAILURE.ind. | | ESROS-FAILURE.ind.
--------<-----------| |-------->---------
| |
Figure 2: Time sequence diagram for ESRO services
2 ESRO SERVICE DEFINITIONS
ESRO service primitives are illustrated in Figure 2, Table 1 and
Table 2. The description of services and primitives comes in the
following sections.
ESROS-User accesses ESRO services through Efficient Short Remote
Operations Service Access Point (ESRO-SAP) as shown in Figure 2.
The RESULT.request, ERROR.request and FAILURE.indication service
primitives can be implemented in two different modes:
Banan, et. al Informational [Page 8]
RFC 2188 ESRO September 1997
1. Acknowledged Result, and
2. Non-Acknowledged Result
_____________________________________________
| ESRO Service |Type |
|________________|__________________________|
| ESROS-INVOKE |Non-confirmed |
| ESROS-INVOKE-P |Provider-initiated |
| ESROS-RESULT |Confirmed / Non-confirmed |
| ESROS-ERROR |Confirmed / Non-confirmed |
| ESROS-FAILURE |Provider initiated |
|________________|__________________________|
Table 1: ESRO Services
as described below. The difference between different modes is in
their reliability of service and efficiency. Reliability of service
is defined based on the understanding of invoker and performer about
the success or failure of the operation on the peer side. Table 3
and Table 4 summarize understanding of performer about success or
failure on invoker side in different situations. In these tables the
FAILURE.indication refers to the primitive generated by protocol and
not the failure of local provider.
2.1 Acknowledged Result Service Mode
In this service mode, the result is acknowledged by invoker, but the
mechanism by which the acknowledgment is accomplished may not be
reliable. Table 3 summarizes the relationship between performer and
invoker in success and failure cases.
2.1.1 Performer side
In this type of service, the RESULT.confirm and ERROR.confirm
primitives on performer side are generated if the result/error is
acknowledged by invoker.
The FAILURE.indication on performer side is generated if result/error
is not acknowledged by invoker or if there is a local failure on
performer side.
>From the protocol point of view, the FAILURE.indication might be
because either the result/error PDU or the ack PDU is lost. The
outcome of this is that a FAILURE.indication is not robust as the
operation may have been successful from the invoker's perspective.
One method of compensating for this shortcoming is having the
performer verify the FAILURE.indication in a separate operation.
Banan, et. al Informational [Page 9]
RFC 2188 ESRO September 1997
____________________________________________________________
| Primitive |Parameters |
|--------------------------+-------------------------------|
| |Operation-value |
| |Performer-address |
| ESROS-INVOKE.request |Invoke-argument-encoding-type |
| |Invoke-argument |
|--------------------------+-------------------------------|
| |Operation-value |
| |Invoker-address |
| ESROS-INVOKE.indication |Invoke-argument-encoding-type |
| |Invoke-argument |
| |Invoke-ID |
|--------------------------+-------------------------------|
| ESROS-INVOKE-P.confirm |Invoke-ID |
|==========================================================|
| | |
| |Result-argument-encoding-type |
| ESROS-RESULT.request |Result-argument |
| |Invoke-ID |
|--------------------------+-------------------------------|
| |Result-argument-encoding-type |
| ESROS-RESULT.indication |Result-argument |
| |Invoke-ID |
|--------------------------+-------------------------------|
| ESROS-RESULT.confirm |Invoke-ID |
|==========================================================|
| | |
| |Error-value |
| |Error-argument-encoding-type |
| ESROS-ERROR.request |Error-argument |
|--------------------------+-------------------------------|
| |Error-value |
| |Error-argument-encoding-type |
| ESROS-ERROR.indication |Error-argument |
| |Invoke-ID |
|--------------------------+-------------------------------|
| ESROS-ERROR.confirm |Invoke-ID |
|==========================================================|
| | |
| |Failure-value |
| ESROS-FAILURE.indication |Invoke-ID |
|__________________________|_______________________________|
Table 2: ESRO service primitives and associated parameters
Banan, et. al Informational [Page 10]
RFC 2188 ESRO September 1997
______________________________________________________________
|Service Mode |Performer |Invoker |
|--------------------+-------------------+-------------------|
|Acknowledged Result |RESULT.confirm |RESULT.indication |
| |-------------------+-------------------|
| |FAILURE.indication |RESULT.indication |
| | (protocol) | |
| |-------------------+-------------------|
| |FAILURE.indication |FAILURE.indication |
| | (protocol) | (protocol) |
|____________________|___________________|___________________|
Table 3: Success and Failure in Acknowledged Result Mode
__________________________________________________________________
|Service Mode |Performer |Invoker |
|------------------------+--------------------+-------------------|
|Non-acknowledged Result |RESULT.confirm |RESULT.indication |
| +--------------------+-------------------|
| |RESULT.confirm |FAILURE.indication |
| | | (protocol) |
| +--------------------+-------------------|
| |FAILURE.indication | |
| |(protocol) | |
| |does not |--- |
| |exist | |
|________________________|____________________|___________________|
Table 4: Success and Failure in Non-acknowledged Result Mode
2.1.2 Invoker side
When invoker receives failure indication, the performer has the
failure indication too.
This type of service can be implemented by protocols based on 3-Way
handshaking.
2.2 Non-acknowledged Result
In this service mode the result is not acknowledged. Table 4
summarizes the relationship between performer and invoker in success
and failure cases.
Banan, et. al Informational [Page 11]
RFC 2188 ESRO September 1997
2.2.1 Performer side
In this type of service, the RESULT.confirm and ERROR.confirm
primitives on performer side are generated without receiving
additional information from the invoker peer. In other words, these
Primitives have no protocol-related meaning and convey no
information, other than end-of-operation.
The FAILURE.indication on performer side is not generated by
protocol. The only case that can generate FAILURE.indication on
performer side is local failure in service provider on performer
side.
2.2.2 Invoker side
The FAILURE.indication on invoker side can be the resultof not
receiving result/error/failure from peer performer or it can result
from failure in local service provider.
This type of service can be implemented by protocols based on 2-Way
handshaking.
2.3 Serialized Use of ESRO Services
Although the ESRO Services are defined to support asynchronous
operation invocation in general, they can be used in the special case
of synchronous (serialized) mode too. The serialized use of ESRO
Services is implementation specific. However, one of the possible
scenarios is as follows:
2.3.1 Invoker
Invokes an operation after it receives either RESULT.indication,
ERROR.indication, or FAILURE.indication for the previous operation.
2.3.2 Performer
Considers an operation to be complete and accepts the next operation
after it receives RESULT.confirm, ERROR.confirm, or
FAILURE.indication.
Banan, et. al Informational [Page 12]
RFC 2188 ESRO September 1997
Invoker Performer
ESROS AP ESROS AP
| |
| |
ESROS-INVOKE.req. | | ESROS-INVOKE.ind.
-------->-----------| |-------->---------
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?