RTI DDS发送数据的模型
默认情况下，Connext 使用尽力而为的交付模型：无需花费任何精力来确保按顺序交付或重新发送丢失的 DDS 样本。尽力而为的 DataReader 会忽略丢失的 DDS 样本，而选择最新的 DDS 样本。仅当您的应用程序在特定时间段（在 47.7 DEADLINE QosPolicy 中设置）内未收到新的 DDS 样本时，才会收到通知。
尽力而为交付模型最适合连续发送的时间关键型信息。例如，考虑 DataWriter 传感器设备的值（例如水箱内的压力），并假设 DataWriter 连续发送 DDS 样本。在这种情况下，本主题的 DataReader 只对提供最新的压力读数感兴趣 — 较旧的 DDS 样品已过时。
２．Reliable Delivery Model
可靠的交付意味着 DDS 样品可以保证按照公布的顺序到达。
DataWriter 维护一个发送队列，该队列有空间来保存最后发送的 X 个 DDS 样本。同样，DataReader 维护一个接收队列，其中包含用于连续 X 个预期 DDS 样本的空间。
发送和接收队列用于临时缓存 DDS 样本，直到 Connext 确定 DDS 样本已送达且不再需要。Connext 在所有可靠订阅确认 DDS 样本后，从发布的发送队列中删除 DDS 样本。禁用肯定确认时（请参阅 QosPolicy DATA_WRITER_PROTOCOL 47.5（DDS 扩展）和 QosPolicy DATA_READER_PROTOCOL 48.1（DDS 扩展）），DDS 样本将在相应的保持持续时间过后从发送队列中删除（请参阅表 47.14 DDS_RtpsReliableWriterProtocol_t）。
如果到达无序的 DDS 样本，Connext 会推测性地将其缓存在 DataReader 的接收队列中（前提是队列中有空间）。只有连续的 DDS 样本才会传递到 DataReader。
可以将 DataWriter 设置为在发送 DDS 样本时等待可用的队列空间。这将导致发送线程阻塞，直到发送队列中有空间为止。（或者，您可以决定牺牲可靠地发送 DDS 样本，以便不会影响发送速率。如果 DataWriter 设置为忽略整个队列并仍然发送，则较旧的缓存 DDS 样本将在所有 DataReader 收到它们之前被推出队列。在这种情况下，DataReader（或其订阅服务器）会通过其 Listener 和/或 Conditions 收到缺少 DDS 样本的通知。
Connext 会根据需要自动发送确认 （ACKNACK） 以保持可靠的通信。DataWriter 可以选择在指定的持续时间内阻塞以等待这些确认（请参阅 31.11 在 DataWriter 中等待确认）。
Connext 在匹配的 DataWriter 和所有 DataReader 之间建立一个虚拟的可靠通道。此机制将 DataReader 彼此隔离，允许应用程序控制内存使用，并为 DataWriter 提供平衡可靠性和确定性的机制。此外，使用发送和接收队列可以有效地实现 Connext，而不会在流中引入不必要的延迟。
请注意，write（） 的成功返回代码 （DDS_RETCODE_OK） 并不一定意味着所有 DataReader 都已收到数据。这仅表示 DDS 示例已添加到 DataWriter 的队列中。要查看是否所有 DataReader 都已收到数据，请查看 31.6.8 RELIABLE_WRITER_CACHE_CHANGED状态（DDS 扩展）以查看是否有任何 DDS 样本未确认。
假设 DataWriter A 可靠地发布 DataReaderB 和 C 可靠地订阅的主题。B 的队列中有空格，但 C 没有。DataWriter A 会收到通知吗？DataReader C 是否会收到任何错误消息或回调？确切的行为取决于 QoS 设置：
- 如果 C 指定了 HISTORY_KEEP_ALL，则 C 将拒绝无法放入队列的 DDS 样本，并要求 A 重新发送缺失的 DDS 样本。Listener 会收到 on_sample_rejected（） 回调的通知（请参阅 40.7.8 SAMPLE_REJECTED状态）。如果 A 的队列足够大，或者 A 不再编写新的 DDS 样本，则 A 不会注意到，除非它检查 31.6.8 RELIABLE_WRITER_CACHE_CHANGED状态（DDS 扩展）。
- 如果为 C 指定了 HISTORY_KEEP_LAST，则 C 将丢弃旧的 DDS 样本并接受新的 DDS 样本。对于 A 来说，就好像 C 已经收到了所有 DDS 样本（即，它们都已被确认）。
３．Overview of the Reliable Protocol
Connext 的一个重要优势是，它可以在非常广泛的传输之上提供 DDS 要求的可靠性和其他 QoS 保证，包括基于数据包的传输、不可靠的网络、支持多播的传输、突发或高延迟传输等。Connext 还能够保持活跃度和应用程序级 QoS，即使在传输层存在零星连接丢失的情况下， 这是移动网络中的一个重要优势。Connext 通过实施一个可靠的协议来实现这一点，该协议对应用程序级消息进行排序和确认，并监控链接的活跃度。这称为实时发布-订阅 （RTPS） 协议;它是一个开放的国际标准。1
为了在如此广泛的环境中工作，RTPS 定义的可靠协议是高度可配置的，其中包含一组参数，这些参数允许应用程序微调其行为，以权衡延迟、响应能力、活跃度、吞吐量和资源利用率。本节在了解配置参数如何影响其操作所需的范围内描述了最重要的功能。
- 支持推式和拉式操作模式
- 支持肯定和否定确认
- 支持高数据速率 DataWriter
- 支持多播 DataReader
- 支持高延迟环境
为了支持这些功能，RTPS 使用多种类型的消息：数据消息 （DATA）、确认 （ACKNACK） 和检测信号 （HB）。
- DATA 消息包含数据对象值的快照，并将快照与 Connext 用于在 DataWriter 历史记录中标识它们的序列号相关联。这些快照作为应用程序在 DataWriter 上调用 write（） 的直接结果存储在历史记录中。每次调用 write（） 时，DataWriter 都会自动分配增量序列号。在图 32.1：基本 RTPS 可靠协议到 32.4 使用 QosPolicies 优化可靠协议中，这些消息使用表示法 DATA（<value>， <sequenceNum>） 表示。例如，DATA（A，1） 表示一条消息，该消息传达值“A”并将序列号“1”与此消息相关联。DATA 消息用于键控和非键控数据类型。
- HB 消息向 DataReader 宣布，它应该已经收到了所有快照，直到用一系列序列号标记的快照，并且还可以请求 DataReader 发回确认。例如，HB（1-3） 向 DataReader 指示它应该已经收到了用序列号 1、2 和 3 标记的快照，并要求 DataReader 确认这一点。
- ACKNACK 消息向 DataWriter 传达特定快照已成功存储在 DataReader 的历史记录中。ACKNACK 还告诉 DataWriter DataReader 端缺少哪些快照。ACKNACK 消息包括一组表示为位图的序列号。序列号指示 DataReader 缺少哪些 ID。（位图包含尚未接收的基序号，后跟位图中的位数和可选的位图。位图的最大大小为 256。所有数字直到（不包括）集合中的数字都被视为肯定确认。它们在图 32.1：基本 RTPS 可靠协议到图 32.7：heartbeat_period 的用法中表示为 ACKNACK（<first-missing>） 或 ACKNACK（<first-missing>-<last-missing>）。例如，ACKNACK（4） 表示序列号为 1、2 和 3 的快照已成功存储在 DataReader 历史记录中，而 4 尚未收到。
请务必注意，Connext 可以将上述多条消息捆绑到单个网络数据包中。这种“子消息捆绑”提供了更高性能的通信。
还值得注意的是，由于 HB 和 ACKNACK 消息传达单个写入器和读取器对之间的可靠通信状态，因此 Connext 至少需要一个单播目标，以便可以将这些消息发送到正确的目标，而不是通过多播目标广播。Connext 支持使用 44.10 WIRE_PROTOCOL QosPolicy（DDS 扩展）中的 enable_multicast_periodic_heartbeat 启用向多播目标发送定期检测信号。