iceoryx基础_iox::popo::publisher的三个参数

背景

自动驾驶的发展带动了系统内部不同进程、线程之间巨量的数据交换，目前这样的通信量能达到 GB/s 以上，因此通过高效传输降低系统资源消耗成为中间件的一大研究重点。

典型通信方式

汽车中使用的通用通信范例是发布/订阅，最典型的一种支持IPC的中间件解决方案是在传递消息时通过中间件来回拷贝数据。由此而产生的后果是系统将在中间件堆栈内部产生多个数据副本，对数据的有效负载序列化，这将在无形中极大的消耗系统的资源。

冰羚

冰羚iceoryx通过“零拷贝，共享内存”数据传输，减少资源浪费。将共享内存技术与发布/订阅架构（publish/subscribe architecture），服务发现机制，现代 C++ 以及无锁算法（lock-free algorithms）相结合。
通过添加避免复制的应用程序接口（API），实现了真正的零拷贝，即实现了数据从“发布者”到“订阅者”的端到端传输方法，其过程中无需创建任何数据副本。

1. 工作原理
   ● 通过iceoryx API，“发布者”将信息直接写入到事先由「中间件」预订好的内存块中
   ● 当数据传递完成后，“订阅者”将收到指向这些内存块的参照指针（reference），并同时可以管理自己可配置容量的信息队列
   ● 每个“订阅者”拥有唯一的且属于自己的视角，可以查看哪些数据仍在处理状态中，以及哪些数据可以被丢弃
   ● 「中间件」iceoryx 在“幕后”则对内存块进行引用计数，当其发现被引用的次数变为零时就会释放内存块，类似于 shared_ptr
2. 技术点
   同步读写
   由于“发布者”跟“订阅者”是独立运行的，因此“发布者”可以在“订阅者”仍在读取数据的同时
   再次进行数据的写入操作而不受影响。如果先前的内存块仍然被占用，则只需为“发布者”重新分配一个新的内存块即可。
   轮询处理
   如果“订阅者”以轮询模式（polling）运行，并且内存块在排队等待被 “订阅者” 再次检测时，系统则可以启用无锁队列（lock-free queue），在被称为“安全溢出（safely overflowing）”的过程中回收较旧的内存块。
   无锁队列能够使“订阅者”更高效的使用内存，并最大限度的在队列里储存最新的消息数据，无论连续轮询之间的时间间隔有多长。
   这对高频的“发布者”和仅对最新的数据信息感兴趣的“订阅者”是非常有帮助的。
   iceoryx API在支持轮询访问（polling）的同时，也支持事件驱动回调（event-driven callback）。
   如果需要实时获取 Topic 信息，可以不断调用 subscriber 方法，但这样势必会增加计算资源造成算力浪费。因此冰羚中提供了两种方式提升数据获取效率：
   ● WaitSet 采用 react 设计模式开发，绑定对应的 subscribers，如果数据来了就触发通知
   ● 监听（Listenner）能够直接触发用户定制的 callback，起到数据来临时的回调作用
3. 注意点
   ● 由于数据消息的有效负载未被序列化，所以数据的“发布者”和“订阅者”必须具有相同的内存布局（memory layout），对于特定处理器上的IPC，我们可以通过使用相同的编译器设置来确保这一点
   ● 共享内存只支持固定长度的消息
   ● 共享内存不能使用virtual members以防止member function被派生类重新定义
   ● 被传输的数据消息中不能包含任何指向进程中内部虚拟内存空间的“指针”，此限制也适用于基于堆的数据结构
4. 核心概念
   ● RouDi：iceoryx 的守护进程，不同的应用需要与它进行连接才能正常通信。运行iceoryx程序前，一定要先启动守护进程 iox-roudi
   ● Runtime：每个需要在 iceoryx 框架下运行的应用，都需要初始化它的 runtime。
   ● Publisher：发布者，需要绑定 topic 使用。一个 Publisher 创建时需要指定 Topic，用来指定要发送的数据。
   ● Subscriber：订阅者，需要绑定 topic 使用。
   ● Topic：Topic 是数据载体，Publisher 发送一个 Topic，Subscriber 能够接收绑定的 Topic 而不需要关注 Topic 来自何处,Publisher 与 Subscriber 要正常通信就需要绑定同一个 Topic。