LW-DDS (一)

stack-refactor 分支 简要说明

1. 期望实现支持多participant，多核多线程。限制🚫如下：
   • 每个pp有一个接收线程；后续应该也要有一个timer线程
   • 每个pp只会监听两个地址：
     1. well-known address: 239.255.0.1:7400 -> 可以配置不监听
     2. specific unicast address
2. 🈲止所有的内存动态申请与释放
   • Linux等平台下，sem/mutex等还是会使用到堆上内存
   • 但是MCU平台，AUTOSAR/FreeRTOS将全面禁用所有动态内存申请与释放
3. 更改数据结构，全面参考AUTOSAR，仅使用数组进行
   • 存储participants, writers, readers
   • 存储远端参与者、实体
4. 增加简易开源log组件，方便后续log

24-10-01分支更新说明

1. 当前重构仅进展到：
   • 接收RTPS Msg，并对RTPS Header进行处理
2. 提供了一个简单的程序，main为主入口；可以简单运行，并处理接收到的RTPS Msg， 但是只能处理头部
3. 后续步骤
   1. process_cdr，完成数据子消息的处理
   2. 发现阶段SPDP -> SEDP
   3. ……

24-10-16 发送架构

1. 从writer的history获取空闲chang buff -> 需要保护起来【而且要考虑多核】

2. 对该buff进行序列化，这里就不需要保护了

3. 遍历writer的【有效：是否有效设置应该采用原子操作保护起来】matched reader进行发送，将数据交给底层 -> 这里应该也不需要保护

   1. 对于删除matched reader操作，应该需要延迟进行！！！；当该reader处于使用状态时，就需要延迟删除该matched reader！！！，连带的可能需要延迟删除该matched reader所属的proxy participant
   • matched reader 三个状态：ok, sending, deleting

4. 底层是否支持多核发送，这就是底层需要考虑的事情了！！！

5. 还是需要实现一个多核通信queue机制，使用spin lock保护

   1. 队列满了直接警告 - 并丢弃此次事件！！
   2. 是否需要提供同步等待接口？

6. Tx event提供QoS

   • Direct Send 不经过Tx Event，直接在dds_write的调用上下文环境中将报文发送出去
   • In Direct Send 要经过Tx Event而且可以设置不同的传输优先级队列！
     • 优先发送高优先级队列中的数据

local reader and remote writer

1. changes_received 存储所有收到的不连续的数据，不能无限制的收这样的数据；因为这样的数据如果确认接收了，那么它和low_marker之间的所有change也要被缓存；因此如果一个change与change_low_marker不连续，则还需要判断是否超过了极限；才能接收