DDSI-RTPS V2.3版本规范中文翻译 part4--行为模块1

8.4 行为模块

该模块描述了RTPS实体的动态行为。它描述了RTPS Writer端点和RTPS Reader端点之间消息交换的有效顺序以及这些消息的时序约束。

8.4.1 概述

一旦RTPS Writer与RTPS Reader匹配，它们都有责任确保存在于Writer HistoryCache中的CacheChange更改传播到Reader的HistoryCache。行为模块描述了匹配的RTPS Writer和Reader必须如何行为，以传播CacheChange更改。该行为是根据使用8.3中定义的RTPS消息进行的消息交换来定义的。行为模块组织如下：

• 8.4.2 列出了RTPS协议的所有实现在行为方面必须满足的要求。满足这些要求的实现被认为是符合的，并且将与其他符合的实现互操作。

• 如上所述，可能有多个实现满足最低要求，其中每个实现可以选择在内存要求、带宽使用、可扩展性和效率之间进行不同的权衡。RTPS规范不强制使用具有相应行为的单一实现。相反，它定义了互操作性的最低要求，然后提供了两个参考实现，即无状态和有状态的参考实现，详见8.4.3。

• 协议行为取决于RELIABILITY QoS等设置。8.4.4讨论了可能的组合。

• 8.4.5和8.4.6定义了本模块中使用的符号约定并定义了任何新类型。

• 8.4.7至8.4.12对两个参考实现进行建模。

• 8.4.13描述了由参与者用于断言其包含的Writer的生存性的Writer生存性协议。

• 8.4.14讨论了一些可选行为，包括对分段数据的支持。

• 最后，8.4.15提供了实际实现的指导方针。

请注意，正如在8.2.9中早先讨论的那样，行为模块不对DDS实体及其相应的RTPS实体之间的交互进行建模。例如，它简单地假设DDS DataWriter在其RTPS Writer的HistoryCache中添加和移除CacheChange更改。更改是由DDS DataWriter作为其写入操作的一部分添加的，并在不再需要时被移除。重要的是要意识到DDS DataWriter可能在CacheChange传播到一个或多个匹配的RTPS Reader端点之前将CacheChange移除。RTPS Writer不能控制CacheChange何时从写入方的HistoryCache中移除。这是DDS DataWriter的责任，只能基于通信状态和DDS DataWriter的QoS移除那些可以根据通信状态和DDS DataWriter的QoS移除的CacheChange更改。例如，KEEP_LAST QoS设置为深度为1的HISTORY允许DataWriter在更改的值替换相同数据对象的值时移除CacheChange。

8.4.1.1 示例行为

该子条款的内容不是协议的正式规范的一部分。该子条款的目的是提供对协议的直观理解。

图8.14显示了RTPS Writer和匹配的RTPS Reader之间交换的序列的典型示例。在这种情况下，示例序列使用了有状态的参考实现。

图8.14 行为示例

一个独立的交互流程如下所述：

1. DDS用户通过调用DDS DataWriter上的write操作来写入数据。

2. DDS DataWriter调用RTPS Writer上的new_change操作创建一个新的CacheChange。每个CacheChange都由SequenceNumber唯一标识。

3. new_change操作返回。

4. DDS DataWriter使用add_change操作将CacheChange存储到RTPS Writer的HistoryCache中。

5. add_change操作返回。

6. write操作返回，用户完成了写入数据的操作。

7. RTPS Writer使用Data Submessage将CacheChange更改的内容发送到RTPS Reader，并通过发送Heartbeat Submessage请求确认。

8. RTPS Reader接收Data消息，并在资源限制允许的情况下，使用add_change操作将CacheChange放入Reader的HistoryCache中。

9. add_change操作返回。CacheChange对DDS DataReader和DDS用户可见，这取决于RTPS Reader的reliabilityLevel属性。 a. 对于RELIABLE DDS DataReader，其RTPS Reader的HistoryCache中的更改仅在所有先前的更改（即，具有较小序列号的更改）也可见时才对用户应用程序可见。 b. 对于BEST_EFFORT DDS DataReader，其RTPS Reader的HistoryCache中的更改仅在尚未显示任何未来更改的情况下才对用户可见（即，如果RTPS Receiver的HistoryCache中没有具有更高序列号的更改）。

10. DDS用户通过DDS规范中描述的机制之一（例如，通过侦听器或WaitSet）被通知，并通过在DDS DataReader上调用take操作启动数据的读取。

11. DDS DataReader使用get_change操作访问更改在HistoryCache中的数据。

12. get_change操作将CacheChange返回给DataReader。

13. take操作将数据返回给DDS用户。

14. RTPS Reader发送AckNack消息，指示将CacheChange放入Reader的HistoryCache中。AckNack消息包含RTPS Reader的GUID和更改的SequenceNumber。这个动作与通知DDS用户以及DDS用户读取数据是独立的。它可能在之前或与之同时发生。

15. StatefulWriter记录RTPS Reader已接收CacheChange，并使用acked_changes_set操作将其添加到ReaderProxy维护的已确认更改集中。

16. DDS用户调用DataReader上的return_loan操作，表示它不再使用通过之前的take操作检索的数据。此操作与写入方的操作无关，因为它由DDS用户发起。

17. DDS DataReader使用remove_change操作从HistoryCache中移除数据。

18. remove_change操作返回。

19. return_loan操作返回。

20. DDS DataWriter使用is_acked_by_all操作确定哪些CacheChange已被与StatefulWriter匹配的所有RTPS Reader端点接收。

21. is_acked_by_all返回并指示具有指定“seq_num” SequenceNumber的更改已被所有RTPS Reader端点确认。

22. DDS DataWriter使用remove_change操作从RTPS Writer的HistoryCache中移除与“seq_num”相关联的更改。在执行此操作时，DDS DataWriter还应考虑其他DDS QoS，如DURABILITY。

23. remove_change操作返回。

上述描述没有对DDS DataReader和RTPS Reader之间的一些交互进行建模；例如，RTPS Reader用于提醒DataReader应调用read或take以检查是否已收到新更改的机制（即导致执行步骤10的原因）。 同样，DDS DataWriter和RTPS Writer之间的一些交互也没有被建模；例如，RTPS Writer用于提醒DataReader应检查特定更改是否已完全确认以便从HistoryCache中删除的机制（即导致执行步骤20的原因）。 上述交互之所以未建模，是因为它们是中间件实现的内部部分，对RTPS协议没有影响。

8.4.2 互操作性所需的行为

这个子条款描述了RTPS协议的所有实现必须满足的要求，以便：

  • 符合协议规范 • 与其他实现互操作

这些要求的范围仅限于不同供应商的RTPS实现之间的消息交换。对于同一供应商的实现之间的消息交换，供应商可以选择不符合规范的实现，或者可以使用专有协议。

8.4.2.1 通用要求

以下要求适用于所有RTPS实体。

8.4.2.1.1 所有通信必须使用RTPS消息进行

不能使用除8.3中定义的RTPS消息之外的其他消息。每条消息的必需内容、有效性和解释由RTPS规范定义。 供应商可以使用协议提供的扩展机制（参见8.6）根据供应商特定需求扩展消息。这不影响互操作性。

8.4.2.1.2所有实现必须实现RTPS消息接收器

实现必须实现由RTPS消息接收器遵循的规则，如8.3.4中介绍的，以解释RTPS消息中的Submessages并维护消息接收器的状态。 该要求还包括通过在必要时为了正确解释前一个而在Entity Submessages之前使用Interpreter Submessages进行适当的消息格式化，如8.3.7中定义的。

8.4.2.1.3 所有实现的定时特性必须是可调的

根据应用程序需求、部署配置和底层传输的不同，最终用户可能希望调整RTPS协议的定时特性。 因此，如果协议行为的要求允许延迟响应或指定周期性事件，实现必须允许最终用户调整这些定时特性。

8.4.2.1.4实现必须实现简单的参与者和端点发现协议

实现必须实现简单的参与者和端点发现协议，以启用远程端点的发现（参见8.5）。 根据应用程序的部署需求，RTPS允许使用不同的参与者和端点发现协议。为了实现互操作性，实现必须至少实现简单的参与者发现协议和简单的端点发现协议（参见8.5.1）。

8.4.2.2 所需的RTPS Writer行为

以下要求仅适用于RTPS Writer。除非另有说明，否则这些要求适用于可靠的和尽力交付的（best-effort）的Writers。

8.4.2.2.1 不得发送乱序的数据

Writer必须按照它们添加到历史缓存的顺序发送数据样本。

8.4.2.2.2 如果Reader要求，Writer必须包含内联QoS值

Writer必须遵守Reader的请求，以内联QoS方式发送数据消息。

8.4.2.2.3 必须定期发送可靠的心跳消息

Writer必须定期通过发送包含可用样本的序列号的心跳消息，通知每个匹配的可靠Reader有数据样本可用。如果没有可用的样本，则无需发送心跳消息。

对于严格可靠的通信，Writer必须继续向Reader发送心跳消息，直到Reader已确认接收所有可用的样本或已消失。

在所有其他情况下，发送的心跳消息数量可以是实现特定的，并且可能是有限的。

8.4.2.2.4 最终必须回应负面的确认（仅限可靠通信）

在收到指示Reader缺少某些数据样本的ACKNACK消息时，Writer必须通过发送缺失的数据样本、在样本不相关时发送GAP消息，或者在样本不再可用时发送心跳消息来作出回应。

Writer可以立即回应，也可以选择将回应安排在将来的某个时间。它还可以合并相关的回应，因此ACKNACK消息和Writer的回应之间不需要一一对应。这些决策和时序特性是实现特定的。

8.4.2.2.5 使用Writer组信息发送心跳和GAPs消息

属于某个组的Writer应向其匹配的Reader发送心跳或GAP子消息，即使Reader已经确认了该Writer的所有样本。这对于订阅者来检测那个Writer中不可用的组序列号是必要的。此规则的例外情况是当Writer发送包含相同信息的DATA或DATA_FRAG子消息时。

8.4.2.3 必需的RTPS Reader行为

一个尽力交付(best-effort)的Reader是完全被动的，因为它只接收数据而不发送消息。因此，下面的要求仅适用于可靠的(reliable) Reader。

8.4.2.3.1 在接收到未设置最终标志的心跳消息后，Reader必须最终回应

在接收到未设置最终标志的心跳消息后，Reader必须用一个ACKNACK消息回应。ACKNACK消息可以确认已接收所有数据样本，也可以指示缺少一些数据样本。

响应可能会被延迟以避免消息风暴。

8.4.2.3.2 在接收到指示缺少样本的心跳消息后，Reader必须最终回应

在接收到心跳消息后，缺少一些数据样本的Reader必须用一个ACKNACK消息回应，指示缺少哪些数据样本。此要求仅在Reader可以在其缓存中容纳这些缺失样本，并且与心跳消息中最终标志的设置无关时适用。

响应可能会被延迟以避免消息风暴。

当活动心跳同时将活动和最终标志设置为指示它是仅活动心跳时，不需要回应。

8.4.2.3.3 一旦被确认，便一直被确认

一旦一个Reader通过ACKNACK消息积极地确认接收了一个样本，它就不能在以后的时间点再次否定地确认相同的样本。

一旦所有Reader对一个Writer的样本都发出了积极的确认，Writer可以收回任何相关的资源。然而，如果Writer收到对先前积极确认的样本的负面确认，并且Writer仍然能够服务请求，Writer应该发送该样本。

8.4.2.3.4 Reader只能在对心跳消息的响应中发送ACKNACK消息

在稳定状态下，ACKNACK消息只能作为对来自Writer的心跳消息的响应而发送。 ACKNACK消息可以在Reader首次发现Writer时从Reader发送，作为一种优化。

Writer无需对这些提前发送的ACKNACK消息作出回应。

8.4.3 RTPS协议的实现

RTPS规范规定，协议的符合实现只需满足8.4.2中提出的要求。因此，实际实现的行为可能会因每个实现所做的设计权衡而有所不同。

RTPS规范的行为模块定义了两个参考实现：

• 无状态参考实现： 无状态参考实现经过优化，以实现可扩展性。它在远程实体上几乎不保存状态，因此在大型系统中具有良好的扩展性。这涉及到一种权衡，因为改进的可扩展性和减少的内存使用可能需要额外的带宽使用。无状态参考实现非常适合通过组播进行的尽力（best-effort）通信。

• 有状态参考实现： 有状态参考实现在远程实体上保留完整状态。这种方法最小化了带宽的使用，但需要更多的内存，并可能导致扩展性降低。与无状态参考实现相比，它可以保证严格可靠的通信，并且能够在Writer端应用基于QoS或内容的过滤。

这两个参考实现在接下来的子条款中都有详细描述。

实际实现不一定需要遵循参考实现。根据维护多少状态，实现可能是参考实现的组合。

例如，无状态参考实现在远程实体上保留最少的信息和状态。因此，它不能在Writer端执行基于时间的过滤，因为这需要跟踪每个远程Reader及其属性。它也不能在Reader端丢弃乱序的样本，因为这需要跟踪从每个远程Writer接收到的最大序列号。一些实现可能模仿无状态参考实现，但选择存储足够的附加状态，以避免上述某些限制。所需的额外信息可以以永久的方式存储，这种情况下实现接近有状态参考实现，或者可以缓慢老化并根据需要保留，以尽可能地逼近在维护状态的情况下可能产生的行为。

无论实际实现如何，为了保证互操作性，重要的是所有实现，包括参考实现，都要满足8.4.2中提出的要求。

8.4.4 与每个匹配的Reader相关的Writer行为

RTPS Writer与每个匹配的Reader相关的行为取决于RTPS Writer和RTPS Reader中reliabilityLevel属性的设置。这控制是使用尽力交付（best-effort）还是reliable可靠协议。

并非所有reliabilityLevel的可能组合都是可能实现的。除非RTPS Writer的reliabilityLevel设置为RELIABLE，否则RTPS Writer不能与RTPS Reader匹配，或者RTPS Writer和RTPS Reader的reliabilityLevel都设置为BEST_EFFORT。这是因为DDS规范规定，BEST_EFFORT DDS DataWriter只能与BEST_EFFORT DDS DataReader者匹配，而RELIABLE DDS DataWriter可以与RELIABLE和BEST_EFFORT DDS DataReader匹配。

正如8.4.3中提到的，Writer是否能与Reader匹配并不取决于它们是否使用相同的RTPS协议实现。也就是说，有状态Writer能够与无状态Reader通信，反之亦然。

8.4.5 符号约定

使用UML序列图和状态图描述了参考实现。这些图使用一些缩写来引用RTPS实体。使用的缩写列在表8.45中。

表8.45 - 序列图和行为模块状态图中使用的缩写

8.4.6 类型定义

行为模块引入了以下额外的类型。

表 8.46 - 行为模块的类型定义

在RTPS模型类中使用的类型
属性类型	用途
Duration_t	用于保存时间差异的类型。应至少具有纳秒分辨率。
ChangeForReaderStatusKind	用于指示ChangeForReader状态的枚举。它可以取以下值：UNSENT（未发送）、UNACKNOWLEDGED（未确认）、REQUESTED（已请求）、ACKNOWLEDGED（已确认）、UNDERWAY（进行中）。
ChangeFromWriterStatusKind	用于指示ChangeFromWriter状态的枚举。它可以取以下值：LOST（丢失）、MISSING（丢失）、RECEIVED（已接收）、UNKNOWN（未知）。
InstanceHandle_t	用于表示由RTPS协议传递的数据对象的身份的类型。
ParticipantMessageData	用于保存参与者之间交换的数据的类型。此类型最显著的用途是用于Writer活动性协议。