写在开篇·蓉儿继续答疑上回说到郭靖搞清楚了DDS自动关联的本质——不是魔法是“对暗号”。开发阶段双方约定好同一个Topic名字运行时DDS听暗号暗号相同就自动连。郭靖合上笔记本但眉头还是皱着“蓉儿我还有三个疑问——”“第一发布者和订阅者启动有先后顺序吗如果订阅者先启动发布者后启动还能连上吗”“第二DDS的广播和一般的UDP广播一样吗会不会把网络搞乱”“第三发布者是一直在发数据吗发送的数据有顺序吗会不会后面的数据比前面的先到”黄蓉咬了口糖葫芦“问得好这三个问题是DDS从‘能用’到‘用好’的关键。今天就把这三个疑问彻底讲清楚。”一、疑问一发布和订阅有先后顺序吗郭靖问“如果域控制器先启动摄像头后启动还能连上吗”黄蓉画了一个时间轴┌─────────────────────────────────────────────────────────────────────┐ │ 启动顺序不影响最终连接 │ ├─────────────────────────────────────────────────────────────────────┤ │ │ │ 时间轴 │ │ │ │ t1域控制器启动 │ │ └── 创建DataReader广播“我要收 /camera/front” │ │ └── 没找到匹配的Writer进入等待状态 │ │ │ │ t2摄像头启动过了几秒 │ │ └── 创建DataWriter广播“我要发 /camera/front” │ │ └── 域控制器收到广播“暗号对上了” │ │ │ │ t3自动建立连接开始传数据 │ │ │ └─────────────────────────────────────────────────────────────────────┘场景能连上吗说明订阅者先启动发布者后启动✅ 能订阅者进入等待发布者上线后自动匹配发布者先启动订阅者后启动✅ 能发布者广播订阅者上线后收到广播自动匹配同时启动✅ 能互相收到广播自动匹配一方永远不启动❌ 不能暗号永远对不上结论启动顺序不影响最终连接。谁先谁后无所谓DDS会持续广播直到暗号对上。郭靖“那如果域控启动时摄像头还没启动域控会一直等吗”黄蓉“不会‘傻等’它会持续监听。域控的DataReader创建后DDS底层会定期广播‘我要收这个Topic’。一旦摄像头上线广播‘我要发’域控立刻就能收到并建立连接。不需要人工干预。”二、疑问二DDS的广播和一般UDP广播一样吗郭靖问“DDS底层也是用UDP广播吗那车上几十个ECU都广播网络会不会炸”黄蓉“DDS的‘广播’不是无脑广播而是有策略的。”对比项普通UDP广播DDS的发现广播频率应用想发就发启动时多发稳定后少发范围整个网络同一Domain逻辑隔离内容任意数据只发发现信息暗号不发业务数据业务数据广播发送建立连接后业务数据是单播点对点关键点DDS的广播只用于“发现阶段”。一旦发布者和订阅者匹配成功后续的业务数据走单播不广播。黄蓉画了数据流向┌─────────────────────────────────────────────────────────────────────┐ │ 发现阶段 vs 数据传输阶段 │ ├─────────────────────────────────────────────────────────────────────┤ │ │ │ 【发现阶段】广播 │ │ ┌─────────┐ │ │ │ 摄像头 │ ──广播“我要发/camera/front”──→ 全网 │ │ └─────────┘ │ │ ┌─────────┐ │ │ │ 域控 │ ──广播“我要收/camera/front”──→ 全网 │ │ └─────────┘ │ │ │ │ 【匹配成功后】业务数据走单播 │ │ ┌─────────┐ ┌─────────┐ │ │ │ 摄像头 │ ──单播点对点────→ │ 域控 │ │ │ └─────────┘ └─────────┘ │ │ │ └─────────────────────────────────────────────────────────────────────┘结论发现广播是轻量级的业务数据是单播。不用担心网络被广播风暴淹没。三、疑问三数据是一直发吗有顺序吗郭靖问“摄像头采集到图像就发那是一直在发吗发送的数据有顺序吗会不会后面的数据比前面的先到”黄蓉分三个小问题回答。3.1 数据是一直发吗场景行为说明摄像头30fps每33ms发一帧周期性发送有数据就发刹车指令有刹车动作才发事件触发发送没有就不发温度传感器每秒发一次周期性发送DDS不强制发送频率。发多快、发不发完全由应用决定。DDS只负责“发出去”和“收得到”。3.2 数据有顺序吗黄蓉画了一个例子┌─────────────────────────────────────────────────────────────────────┐ │ 数据的顺序保证 │ ├─────────────────────────────────────────────────────────────────────┤ │ │ │ 摄像头发送顺序 │ │ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ │ │ │帧1 │→│帧2 │→│帧3 │→│帧4 │ ← 按采集顺序发送 │ │ └─────┘ └─────┘ └─────┘ └─────┘ │ │ │ │ │ │ │ │ ▼ ▼ ▼ ▼ │ │ 网络传输可能乱序 │ │ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ │ │ │帧1 │ │帧3 │ │帧2 │ │帧4 │ ← 网络可能让帧3先到 │ │ └─────┘ └─────┘ └─────┘ └─────┘ │ │ │ │ │ │ │ │ ▼ ▼ ▼ ▼ │ │ DDS接收端根据writerSN重排 │ │ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ │ │ │帧1 │→│帧2 │→│帧3 │→│帧4 │ ← DDS按序列号恢复顺序 │ │ └─────┘ └─────┘ └─────┘ └─────┘ │ │ │ └─────────────────────────────────────────────────────────────────────┘DDS保证同一Writer发送的数据按发送顺序到达订阅者。即使网络乱序DDS底层也会根据writerSN序列号重新排序上层应用收到的数据顺序和发送顺序一致。3.3 不同Writer的数据有顺序吗郭靖追问“那如果两个摄像头同时发数据域控收到的顺序有保证吗”黄蓉摇头不同Writer之间的数据没有顺序保证。摄像头A的第5帧和摄像头B的第3帧谁先到谁后到DDS不保证顺序。场景顺序保证同一个Writer同一个摄像头✅ 有保证按发送顺序到达不同Writer两个摄像头❌ 无保证谁先到谁先收四、完整总结三个疑问的答案黄蓉画了一张总结表疑问答案发布订阅有先后顺序吗没有顺序要求。谁先启动都行DDS会持续广播直到暗号对上自动连接广播和普通UDP广播一样吗不一样。只用于发现阶段业务数据走单播不会造成广播风暴数据是一直发吗取决于应用。DDS不强制频率应用想发就发数据有顺序吗同一个Writer有顺序保证按发送顺序到达不同Writer无顺序保证五、黄蓉的小本本郭靖翻开她的笔记本上面写着DDS通信行为要点1. 启动顺序无所谓谁先谁后。DDS持续广播暗号对上自动连。2. 广播策略发现阶段用轻量广播业务数据用单播。不会造成网络风暴。3. 发送频率应用自己决定。周期发送如摄像头30fps或事件触发如刹车指令。4. 顺序保证同一Writer有顺序保证writerSN重排乱序不同Writer无顺序保证一句话发布订阅不挑顺序发现广播点到即止发送频率自己定同源数据不乱序。写在最后郭靖合上笔记本“我明白了。启动顺序不影响连接DDS会持续广播直到暗号对上。发现广播是轻量的业务数据是单播不会把网络搞乱。数据发多快由应用决定同一个摄像头的数据有顺序保证不同摄像头之间没有。”黄蓉咬了口糖葫芦“全明白了”郭靖点头“明白了。发布订阅不挑顺序数据发送自己定。”打完收工886。