CoreDX_DDS
中间件的类型
通用中间件体系结构（IPC机制）可以分为功能性（有时称为面向服务的）中间件或面向消息的中间件（MOM）。
-
面向功能/服务的中间件示例：
- 远程过程调用（RPC）
- 对象请求代理（ORB），例如CORBA
- 数据库访问，例如SQL
从根本上，功能中间件是点对点架构，并且客户端和服务端紧密耦合。
面向功能/服务中间件
-
面向消息的中间件（MOM）的示例：
- 发布/订阅，例如CoreDX DDS
- 消息队列，例如JMS， MQSeries
面向消息的中间件发布者和订阅者之前松散耦合。
比较中间件/ IPC技术
比较CoreDX DDS和Socket API
套接字被广泛用于进程间通信，并且已经被广泛使用了数十年。几乎所有编程和脚本语言都包含某种形式的Socket API，大多数操作系统中都包含Sockets。
标准的Socket API在连接的每一侧都需要专门的代码。在“服务器”端，此代码执行创建和配置套接字，等待和接受连接以及写入数据所需的任务。在“客户端”端，此代码执行创建和配置套接字，尝试连接以及读取数据所需的任务。此外，对于每种操作系统和编码语言，此代码可能会有所不同。
相比之下，CoreDX DDS发布者和订阅者易于创建和使用。只需创建发布者（或订阅者）并写入（或读取）数据即可。此外，该应用程序对所有操作系统和编码语言使用相同的API。
比较中间件/ IPC技术
CoreDX DDS不仅比Sockets API更易于使用，而且还具有许多功能。诸如数据过滤，存储，组织和表示之类的功能。发现端点，截止日期和所有权等功能。仅当应用程序开发人员手写，测试和维护它们时，才能使用Sockets API实现这些功能。
比较CoreDX DDS和CORBA（RPC）
CORBA API需要对象请求代理（ORB）。开始通信之前，所有客户端和服务器都必须连接到ORB并向ORB注册，该通信通常是独立服务器。CORBA客户端在服务器上调用远程方法并获得响应。这是一个远程过程调用（RPC）体系结构。
每个CoreDX DDS应用程序均包含用于发现和数据通信的所有必需代码-无需服务器。
CoreDX DDS和CORBA（RPC）包含的功能
CoreDX DDS不像CORBA架构那样包含单点故障，此外，它还具有以下功能：
自动发现
量身定制沟通行为的能力
互通性
这些功能不适用于CORBA。
比较CoreDX DDS和JMS
JMS体系结构要求必须配置服务器并使其可用，然后才能进行数据通信。JMS数据的生产者和使用者必须找到并连接到该服务器。JMS服务器通常需要大量资源，并且会造成单点故障。
每个CoreDX DDS应用程序均包含用于发现和通信的所有必需代码。不需要服务器。此外，CoreDX DDS应用程序会自动发现彼此，因此它们不需要配置端点。
CoreDX DDS和JMS包含的功能
CoreDX DDS不包含像JMS这样的单点故障，此外，它还具有以下功能：
自动发现
类型安全
量身定制沟通行为的能力
互通性
这些功能不适用于JMS。
比较CoreDX DDS和SOA Web服务
Web服务要求配置的Web服务器安装了适当的Web服务模块。必须先为每个客户端配置Web服务器的地址，然后才能调用该服务。同样，此体系结构取决于服务器（在这种情况下为Web服务器）。
每个CoreDX DDS应用程序均包含用于发现和通信的所有必需代码。没有要安装或配置的服务器，架构中也没有单点故障
CoreDX DDS和SOA Web服务中包含的功能
CoreDX DDS不像Web服务体系结构那样包含单点故障，此外，它还具有以下功能：
自动发现
类型安全
量身定制沟通行为的能力
这些功能不适用于SOA Web服务。
CoreDX DDS功能：QoS策略
CoreDX DDS提供了一套丰富的服务质量（QoS）策略，以量身定制数据通信。QoS策略设置会影响数据通信的行为并控制DDS的各个方面。
动态发现使用QoS设置来适当地匹配数据的生产者和消费者。生产者和消费者的这些QoS策略不一定必须匹配，但是必须兼容。
例如，提供“ RELIABLE”通信的数据生产者将满足请求“ RELIABLE”或仅“ BEST_EFFORT”通信的消费者的要求。但是，提供“ BEST_EFFORT”通信的数据生产者将无法满足请求“ RELIABLE”通信的消费者的要求。
什么是互操作性？ 互操作性是来自不同供应商/来源的DDS实施进行通信的能力。
我们为什么要它？ 互操作性为实施决策和供应商独立性提供了更大的灵活性。
OMG的开放标准可实现互操作性：DDS API，RTPS有线协议，CDR数据编码。
CoreDX DDS功能：性能
CoreDX DDS具有低延迟通信体系结构。它包括旨在满足实时和近实时系统要求的基本设计原则，包括：
- 最少的数据副本
- 压缩编码
- 轻量级通知机制
- 资源预分配
- 预编译特定类型的代码块
连续数据解决方案
连续数据用例解决了传感器生成数据并使用此数据的情况。
传感器以高频率产生数据更新。使用者应几乎实时地接收数据，而不会出现任何明显的网络延迟。
一些使用者需要传感器生成的所有数据，而其他使用者则仅需要最新数据。
使用了以下CoreDX DDS功能：
BEST_EFFORT和RELIABLE可靠性QoS：某些数据使用者无法使网络偶尔丢弃网络数据包，而对于其他使用者，更新频率使丢弃的数据包可以接受。传感器应用程序仅发布数据，而不必担心另一端的使用者类型。
基于时间的过滤器QoS：用户显示使用者每秒可能只需要更新一次，而不是传感器每秒要更新500次。基于时间的筛选器允许使用中的应用程序配置此行为，并且传感器应用程序不需要知道。
低延迟通信：CoreDX DDS可以支持每秒500（甚至更高）的更新频率，以确保在低延迟的情况下获得最大的数据吞吐量。
不可靠网络上的可靠性解决方案
可靠性用例解决了通信不良必须使用有损或陈旧或缓慢的网络基础结构的情况。这就提出了一个常见的问题-确保在这些环境中进行可靠的数据传输。
在此示例中，我们将看到一个包裹交付服务，该服务具有一个跟踪交付状态的中心办公室，以及带有手持设备的驾驶员，可以在包裹接收或交付时对其进行扫描。
用于在手持设备和中心局之间进行通信的无线网络本质上是不可靠的。但是重要的是，中央办公室要接收来自手持设备的数据。
可靠性用例的此解决方案使用以下CoreDX DDS功能：
- 可靠的QoS（Reliable Reliability QoS）：CoreDX DDS可靠的QoS策略提供了非常有效的握手和丢弃数据的重新传输，以确保所有订阅接收者都将收到书面数据样本。实际上，就网络流量而言，CoreDX DDS可靠性协议比TCP更高效。
- 压缩的数据编码（Compact Data Encoding）：CoreDX DDS通过有线使用的压缩的数据编码提供了有效的通信，并减少了发送（和重新发送）数据所需的网络带宽。
仿真和测试解决方案
仿真和测试用例解决了一个测试场景，其中被测系统将与专用设备连接。在初始测试阶段，需要使用模拟器代替专用设备，直到测试过程中的后续测试才可用。
在许多情况下，执行不同的代码以与仿真器进行通信而不是与实际设备进行通信，这不一定是对系统的准确测试。
针对模拟和测试用例的此解决方案使用以下CoreDX DDS功能：
- 发布-订阅体系结构（Publish-Subscribe Architecture）：此体系结构使生产者与消费者脱钩。测试系统可以简单地发布数据并订阅数据，而无需知道它是另一端的模拟器还是真实设备。
-
动态发现（Dynamic Discovery）：动态发现允许DDS端点自动发现彼此-通信端点没有配置。从一个测试环境移至另一个测试环境时，无需配置IP地址或端口号。
image.png
故障转移解决方案
故障转移用例解决了存在冗余服务器的情况。CoreDX DDS提供的功能可以与其他故障转移机制结合使用，以提供可靠的解决方案。
在这种情况下，有两个数据生产者副本。数据生产者可以位于同一台计算机上，也可以位于网络中的多台计算机上。每个数据生产者都可以产生必要的数据，并且数据消费者不应看到多于一个的数据副本，并且如果一个数据生产者发生故障，数据传送也不会中断。
故障转移用例的此解决方案使用以下CoreDX DDS功能：
- 所有权QoS（Ownership QoS）：使用排他所有权，即使有两个或多个生产者在写数据，消费者也只会看到一个数据副本。消费者从最强的生产者那里接收数据。当该生产者发生故障时，消费者将自动从剩余最强的生产者那里看到数据的一份副本。
-
可靠性QoS（Reliability QoS）：可靠性QoS确保消费者可以接收一份由任何生产者写入的所有数据的一个副本。如果网络上有任何数据丢失，将重新传输。
image.png
状态信息解决方案
状态信息用例解决了传感器设备发布状态信息的情况。此状态信息的一个使用者是用户显示应用程序。
显示屏仅需要传感器的当前状态。
即使显示应用程序延迟启动（在Sensor发布其当前状态之后），显示也不会错过更新。
状态信息用例的此解决方案使用以下CoreDX DDS功能：
- 历史QoS（History QoS）：历史QoS策略允许显示应用程序和传感器指定要保留多少历史数据。在这种情况下，仅需要当前状态或历史记录。深度= 1。
- 可靠性QoS（Reliability QoS）：显示应用程序不能错过任何Sensor的更新，因此将使用可靠协议。
-
耐用性QoS（Durability QoS）：CoreDX DDS可以保留以前发布的数据（例如，传感器状态），并将其交付给在写入数据后启动的应用程序。在此示例中，显示应用程序将启动并接收每个传感器发布的最新状态
image.png
分配网络负载解决方案
状态信息用例（The State Information Use Case）解决了需要将已发布的传感器数据存储到磁盘的情况。传感器写入数据的速度快于磁盘I / O不能处理的速度，因此有必要在多个计算机上分配磁盘I / O
分布式网络负载用例的此解决方案使用以下CoreDX DDS功能：
- 内容过滤器（Content Filters）：每个使用者都可以根据内容过滤数据，确保每台机器都接收唯一的传感器数据集。
- 动态发现（Dynamic Discovery）：可以随时将新的传感器和磁盘添加到体系结构中，而无需重新配置应用程序。甚至内容过滤器也可以动态更改。
CoreDX DDS历史记录QoS
历史记录QoS策略允许DataReader和DataWriter都指定要保留在CoreDX DDS中间件中的历史数据量。每个DataReader和DataWriter都维护一个保存历史数据样本的DataCache。
对于DataWriter，此历史数据可用于可靠通信中的重传，或用于持久通信中的后期加入DataReader。
对于DataReader，可以在read（）调用中将此历史信息提供给应用程序。
历史QoS策略允许应用程序指定：
类型：KEEP_LAST或KEEP_ALL。对于种类= KEEP_ALL，CoreDX DDS保留的样本数仅受资源限制QoS设置或可用内存的限制。
深度：仅适用于Kind = KEEP_LAST，这是CoreDX DDS将针对每个实例进行采样的样本数。提供历史记录的限制使CoreDX DDS可以预分配资源和绑定的内存使用量。
CoreDX DDS耐久性QoS
耐用性QoS指定为后期加入的订户保留已发布样本的时间。然后可以将这些已经发布的样本传递给原始样本发布时不存在的订户。
有几个级别（种类Kinds）的耐久性：
种类= VOLITILE：不为以后加入的订户保留历史样本。这不会影响历史记录或可靠性QoS策略-丢弃的样本可能仍会重新传输到现有订户。
种类= TRANSIENT_LOCAL：历史样本保存在DataWriter中。这些示例将无法在应用程序退出后继续存在，因为DataWriter将不再存在。
种类= TRANSIENT：历史样本由单独的服务保存在内存中。这些示例将在应用程序重新启动后幸免，但在计算机重新启动时将被删除。
-
种类= PERSISTENT：历史样本将永久保存。这些示例将在计算机重新启动后幸存下来
image.png
CoreDX DDS过滤器
CoreDX DDS为DataReader提供了筛选选项，以限制应用程序接收的数据。可以在发送端或接收端执行此筛选，但是无论哪种方式，筛选都可以减少网络流量和CPU负载。
每个DataReader都可以指定不同的过滤器，即使那些订阅同一主题的DataReader也是如此。一些DataReader可能会接收未过滤的数据，而另一些则设置不同的过滤条件。
过滤器有两种：
- 内容过滤器(Content Filters) 由SQL-lik查询指定。
-
基于时间的过滤器(Time Based Filters) 由持续时间指定，以使样本之间的间隔最小.
image.png
CoreDX DDS内容过滤器
内容过滤器可以在源或目标处实现。
更典型的用途是在目标位置进行过滤。这允许DataWriter照常发布数据，将样本多播到所有匹配的DataReader。DataReader在数据接收过程的早期就应用了过滤器，从而消除了CoreDX DDS和应用程序的不必要处理。
从源头过滤也可能是有益的。对于将通过少量匹配的DataReader上的筛选器的数据，在源处进行筛选不仅会减少网络流量，而且不会“唤醒”线程以接收将被筛选器丢弃的数据。
CoreDX DDS基于时间的过滤器
CoreDX DDS DataReader还可以选择按时间过滤接收到的数据。这使DataReader接收的采样频率不超过最小间隔。
例如，传感器每秒发布500个更新。订阅传感器数据的显示应用程序每秒只会刷新一次。该显示应用程序可以配置基于时间的过滤器，使其每秒接收不超过一个更新。其余的499次更新将被CoreDX DDS丢弃。
每个实例都会应用基于时间的过滤器。例如，考虑5个传感器，每个传感器在温度主题的不同实例上发布。在这种情况下，基于时间的过滤器minimum_separation = 1秒的显示应用程序可能每秒接收5个样本。也就是说，订阅应用程序将为每个实例每秒接收一个样本。
CoreDX DDS可靠性 Reliability
CoreDX DDS有线协议( wire protocol)使用UDP，这是一种开销较低但不可靠的网络协议。CoreDX DDS允许应用程序选择数据通信的可靠性：要么RELIABLE或BEST_EFFORT。
RELIABLE设置增加了握手和传输功能，以确保数据传输。
BEST_EFFORT设置使用默认的UDP协议，并且不能保证数据传输。
使用RELIABLE设置，数据的重新传输取决于其他QoS策略设置：
- DataWriter上的历史记录深度History Depth必须足以保存可能需要重新传输的样本。
- 可以应用资源限制Resource Limits 来强制发布应用程序阻塞，直到所有订阅应用程序都确认已经发送的数据为止。
右图显示了当网络丢失已发布的数据样本时BEST_EFFORT和RELIABLE通信的示例。
