iceoryx(冰羚)-简介

概要

RouDi

RouDi是Routing and Discovery的缩写。RouDi负责通信设置，但实际上并不参与发布者与订阅者或客户端与服务器之间的通信。鲁迪可以被认为是iceoryx的总机操作员。它的另一个主要任务是设置共享内存，应用程序使用共享内存交换有效负载数据。RouDi有时被称为守护进程，它管理共享内存并负责服务发现，即使订阅者/客户端能够找到发布者/服务器提供的主题。它还跟踪所有已初始化运行时的应用程序，从而能够创建发布者、订阅者、服务器或客户端。它为应用程序查询此信息提供了便利。
当应用程序崩溃时，RouDi会清理所有资源。由于我们的进程间机制大多是无锁的（只有最后一个锁；我们正在努力删除它），与使用锁定的传统机制相比，基于iceoryx的通信要可靠得多。

共享内存

为了实现零拷贝进程间通信，iceoryx使用共享内存方法，即发布者和订阅者或客户端和服务器可以通过共享内存进行通信，从而实现零拷贝通信。
共享内存是指多个进程可以通过映射到其虚拟地址空间中的内存区域来访问的物理内存。
有关更多信息，请参阅我们的共享内存概念文章。

Runtime

每个想要使用iceoryx的应用程序都必须实例化其运行时，这基本上实现了与RouDi的通信。
为此，需要以下代码行
iox::runtime::PoshRuntime::initRuntime(“some_unique_application_name”);

runtime是用户应用程序中的一个对象，它将共享内存映射到用户应用程序的地址空间中。
(注意)每个用户应用程序只允许有一个运行时对象。

Creating service descriptions for topics

iceoryx中的ServiceDescription表示一个主题，发布者和订阅者或客户端和服务器可以在该主题下交换数据，并由三个字符串标识符唯一标识。
1.Group name
2.Instance name
3.Topic name
由这样的字符串组成的三元组称为ServiceDescription。如果这三个字符串在元素上都相等，即组、实例和主题名称都相同，则两个ServiceDescriptions被视为匹配。这意味着可以忽略组和实例标识符来创建不同的ServiceDescriptions。它们将在未来用于高级过滤功能。
iceoryx的服务模型是从AUTOSAR派生的，并且仍然在API中使用这些名称（service、Instance、Event）。所谓的规范协议是在名称空间capo中实现的。
下表概述了不同的术语和当前映射：

服务与实例相关，就像类与C++中的对象相关一样。服务描述一个抽象主题，实例是该抽象的一个实例化，就像对象是一个实例化的类一样。事件在这种上下文中类似于类的成员。
Example:
class MyRadarService {
public:
bool hasObstacleDetected;
float distanceToObstacle;
};

MyRadarService frontLeftRadarInstance;
std::cout << frontLeftRadarInstance.hasObstacleDetected << std::endl;

例如，在iceoryx世界中，我们会订阅该服务（“MyRadarService”、“frontLeftRadarInstance”、“hasObstructureDetected”），并在检测到障碍物时接收样本。或者，我们会订阅distance ToObstruct，并收到一个恒定的数据流，显示到障碍物的距离。

限制

传输数据的数据类型可以是任何C++类、结构或纯旧数据类型，只要满足以下条件：
1.没有使用堆
2.数据结构完全包含在共享内存中——没有指向进程本地内存的指针，没有指向进程局部结构的引用，也没有动态分配器
3.数据结构必须是可重定位的，因此不能在内部使用指针/引用
4.没有虚拟成员函数

Publisher

发布者与主题相关，需要构建服务描述。如果它是类型化的，则需要额外指定数据类型作为模板参数。否则，发布者只知道原始内存，用户必须确保它被正确解释。
一旦提供了主题，就可以发布（发送）特定类型的数据。请注意，默认情况下，同一主题有多个发布者（n:m通信）。可以使用编译时选项将iceoryx限制为1:n通信。如果使用1:n通信，RouDi会检查同一主题的多个发布者，如果一个主题有多个发布器，则会引发错误。

Subscriber

对称地，订阅者也对应于主题，因此需要构建服务描述。至于出版商，我们区分打字订户和非打字订户。
一旦订阅者订阅了某个主题，它就能够接收与该主题相关的类型的数据。在非类型化的情况下，这是原始内存，用户必须注意以与实际发送的数据兼容的方式对其进行解释。
当多个发布者提供了相同的主题时，订阅者将接收所有发布者的数据（但不同发布者之间的顺序不确定）。请注意，订阅者不会从服务器或客户端接收数据，即使它们使用相同的主题。

client

与发布者和订阅者类似，客户端与主题相关，需要构建服务描述。如果客户端是类型化的，则需要将请求和响应数据类型指定为模板参数。在非类型化的情况下，客户端只知道原始内存，用户必须注意其正确解释。
一旦客户端连接到服务器，它就可以向服务器发送请求并从服务器接收响应。序列ID用于将响应与特定请求相匹配。它必须在用户请求时设置，并在用户响应时检查。

Server

与客户端一样，服务器需要构建服务描述，并且可以是类型化的或非类型化的。在类型化的情况下，用户必须提供请求和响应数据类型作为模板参数。否则，服务器处理原始内存，用户必须确保对其进行正确解释。
一旦连接，服务器就可以接收来自客户端的请求并发送相应的响应。

避免轮询

接收数据的最简单方法是定期轮询数据是否可用，如下图左侧所示，用于发布-订阅消息模式。这对于简单的用例来说已经足够了，但通常效率低下，因为它通常会导致不必要的延迟和在没有数据的情况下唤醒。接收数据的另一种方法是等待用户定义的事件发生。这是由我们的WaitSet和Listener提供的，它们将在以下部分中介绍。

WaitSet

WaitSet可以用来放弃控制，方法是让线程在非繁忙等待时进入睡眠状态，并等待用户定义的事件发生。通常，这些事件对应于特定订阅者或客户端的数据可用性。这样，我们可以在数据可用时立即醒来，并在没有数据可用时避免不必要的醒来。
一个典型的用例是创建一个WaitSet，连接多个订阅者和/或客户端以及用户触发器，然后等待一个或多个连接的对象发出事件信号。如果发生这种情况，则会收到一个名为notificationVector的所有已发生事件的列表。这使得当它向WaitSet发出新数据或新响应可用的信号时，可以直接从订户或客户端收集数据。
WaitSet使用reactor模式，并通过推送策略通知用户发生了一个附加事件。
有关如何使用WaitSet的更多信息，请参阅我们的WaitSet示例。

Listener

侦听器可用于将自定义回调连接到用户定义的事件。与WaitSet不同，它通过在后台线程中执行连接的自定义回调来对这些事件做出反应，该回调将由Listener创建。与WaitSet一样，后台线程在接收新数据时等待非繁忙状态。
一个用例可能是创建一个Listener并附加多个订阅者。每次有新的数据可用时，都会执行相应的连接回调，例如将某些内容打印到控制台或计算算法。另一个用例可能是，服务器连接到侦听器，每次接收到请求时，都会执行创建并发送响应的连接回调。
与WaitSet一样，Listener使用reactor模式。
有关Listener的更多信息，请参阅我们的回调示例。

API

API有两种语言，C++和C。详细信息可以在C++示例和C示例中找到。
C++API的许多部分都遵循函数式编程方法，这种方法的错误较少。这需要使用此处介绍的一元类型cxx:：expected和cxx::optional。
使用C++API，我们可以区分类型化的API和非类型化的API。在类型化的API中，底层数据类型通过对某些数据类型T（通常是模板参数）的类型化指针或引用而变得明显。这允许以C++惯用和类型安全的方式处理数据，并且应该尽可能首选。类型化的API主要用于iceoryx独立使用时，即未集成到第三方框架中。
非类型化的API提供了指向数据的不透明（即无效）指针，这是灵活有效的，但也要求用户注意正确解释接收到的数据，即与实际发送的数据兼容的类型。这是与其他较低级别API交互和集成到第三方框架（如ROS）中所必需的。有关更多信息，请参阅相应的头文件。