RTPS实时发布订阅协议报头及子消息映射 (未更完)

最新推荐文章于 2024-07-23 14:20:29 发布
最新推荐文章于 2024-07-23 14:20:29 发布
阅读量1.7k 收藏 22
点赞数 9
分类专栏： DDS
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_44783314/article/details/109363338
版权

 RTPS报头映射

Header: 
0...2...........8...............16.............24...............32 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|      'R'      |      'T'      |      'P'      |      'S'      | 
+---------------+---------------+---------------+---------------+ 
|    ProtocolVersion  version   |      VendorId   vendorId      | 
+---------------+---------------+---------------+---------------+ 
|                                                               | 
+                                                               + 
|                    GuidPrefix     guidPrefix                  | 
+                                                               + 
|                                                               | 
+---------------+---------------+---------------+---------------+

 GuidPrefix：定义用于出现在消息中的所有GUID的默认前缀

RTPS子消息映射

Submessage头

E = SubmessageHeader.flags& 0 x01

E=0表示大端，E=1表示小端。

struct SubmessageHeader { 
    octet submessageId; 
    octet flags; 
    unsigned short submessageLength; /* octetsToNextHeader */ 
};

SubmessageHeader:
0...2...........8...............16.............24...............32 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|  submessageId |     flags   |E|    ushort octetsToNextHeader  | 
+---------------+---------------+---------------+---------------+ 
|                                                               | 
|                      following are the                        | 
~                    contents of Submessage                     ~ 
|                                                               | 
+---------------+---------------+---------------+---------------+

SubmessageId

enum SubmessageKind { 
    PAD = 0x01, /* Pad */ 
    ACKNACK = 0x06, /* AckNack */ 
    HEARTBEAT = 0x07, /* Heartbeat */ 
    GAP = 0x08, /* Gap */ 
    INFO_TS = 0x09, /* InfoTimestamp */ 
    INFO_SRC = 0x0c, /* InfoSource */ 
    INFO_REPLY_IP4 = 0x0d, /* InfoReplyIp4 */ 
    INFO_DST = 0x0e, /* InfoDestination */ 
    INFO_REPLY = 0x0f, /* InfoReply */ 
    NACK_FRAG = 0x12, /* NackFrag */ 
    HEARTBEAT_FRAG = 0x13, /* HeartbeatFrag */ 
    DATA = 0x15, /* Data */ 
    DATA_FRAG = 0x16, /* DataFrag */ 
};

octetsToNextHeader

标识当前子消息除去子消息头的大小

如果octetsToNextHeader> 0，则它是从Submessage内容的第一个八位位组到下一个Submessage的标头的第一个八位位组之间的八位组数（如果Submessage不是消息中的最后一个Submessage），或者消息中剩余的八位字节数（如果Submessage是消息中的最后一个Submessage）。消息的解释器可以区分这两种情况，因为它知道消息的总长度。

如果octetsToNextHeader == 0且Submessage的类型不是NOT PAD或INFO_TS，则Submessage是消息中的最后一个Submessage，并一直扩展到消息的末尾。如果它们是消息中的最后一个子消息，则可以发送大于64k（可以存储在octetsToNextHeader字段中的大小）的子消息。

如果octetsToNextHeader == 0并且Submessage的类型是PAD或INFO_TS，则下一个Submessage标头在当前Submessage标头之后立即开始，或者PAD或INFO_TS是消息中的最后一个Submessage。

AckNack Submessage

0...2...........7...............15.............23...............31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     ACKNACK   |X|X|X|X|X|X|F|E|      octetsToNextHeader       |
+---------------+---------------+---------------+---------------+
|           EntityId             readerId                       |
+---------------+---------------+---------------+---------------+
|           EntityId             writerId                       |
+---------------+---------------+---------------+---------------+
|                                                               |
~              SequenceNumberSet  readerSNState                 ~
|                                                               |
+---------------+---------------+---------------+---------------+
|              Count             count                          |
+---------------+---------------+---------------+---------------+

 

Flags

F = SubmessageHeader.flags & 0x02

F=1   表示读取器不需要写入器的响应。

F=0   意味着写入器必须响应AckNack消息。

EntityId_t

EntityId_t唯一标识参与者端点

PSM将EntityId_t映射到以下结构：


typedef octet OctetArray3[3];

struct {

    OctetArray3 entityKey;

    octet entityKind;

};

EntityId_t内的entityKind字段编码实体类型（参与者、Writer、Reader)，以及实体是否是内置实体(由协议完全预定义，自动实例化），用户定义的实体（由协议定义，但用户仅根据应用程序的需要实例化）或特定于供应商的实体(由Protoc的特定于供应商的扩展定义 因此，可以被另一个供应商的实现忽略)。

当未预先定义（见下文）时，EntityId_t 内的实体密钥字段可以由中间件实现任意选择，只要所产生的EntityId_t在参与者中是唯一的。

关于对象是内置实体、特定于供应商的实体或用户定义实体的信息被编码在实体种类的两个最重要的比特。 这两个位设置为：

  1. 用户定义实体的 00
  2. 内置实体的 11
  3. 供应商特定实体的 01
  • 实体EntityId_t的八进制

实体种类

用户定义实体

内置实体 

unknown

0x00

0xc0

Participant

N/A

0xc1

Writer (with Key)

0x02

0xc2

Writer (no Key)

0x03

0xc3

Reader (no Key)

0x04

0xc4

Reader (with Key)

 0x07

0xc7

  • RTPS协议完全预定义的EntityId_t值

实体对应的值entityId_t (NAME = value)

Participant

ENTITYID_PARTICIPANT = {{00,00,01},c1}

SEDPbuiltinTopicWriter

ENTITYID_SEDP_BUILTIN_TOPIC_WRITER = {{00,00,02},c2}

SEDPbuiltinTopicReader

ENTITYID_SEDP_BUILTIN_TOPIC_READER = {{00,00,02},c7}

SEDPbuiltinPublicationsWriter

ENTITYID_SEDP_BUILTIN_PUBLICATIONS_WRITER = {{00,00,03},c2}

SEDPbuiltinPublicationsReader

ENTITYID_SEDP_BUILTIN_PUBLICATIONS_READER = {{00,00,03},c7}

SEDPbuiltinSubscriptionsWriter

ENTITYID_SEDP_BUILTIN_SUBSCRIPTIONS_WRITER = {{00,00,04},c2}

SEDPbuiltinSubscriptionsReader

ENTITYID_SEDP_BUILTIN_SUBSCRIPTIONS_READER = {{00,00,04},c7}

SPDPbuiltinParticipantWriter

ENTITYID_SPDP_BUILTIN_PARTICIPANT_WRITER = {{00,01,00},c2}

SPDPbuiltinSdpParticipantReader

ENTITYID_SPDP_BUILTIN_PARTICIPANT_READER = {{00,01,00},c7}

BuiltinParticipantMessageWriter

ENTITYID_P2P_BUILTIN_PARTICIPANT_MESSAGE_WRITER = {{00,02,00},c2}

BuiltinParticipantMessageReader

ENTITYID_P2P_BUILTIN_PARTICIPANT_MESSAGE_READER = {{00,02,00},c7}

 

Data Submessage

0...2...........8...............16.............24...............32 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|   DATA        |X|X|X|X|X|D|Q|E|      octetsToNextHeader       | 
+---------------+---------------+---------------+---------------+ 
|   Flags        extraFlags     |      octetsToInlineQos        | 
+---------------+---------------+---------------+---------------+ 
|           EntityId             readerId                       | 
+---------------+---------------+---------------+---------------+ 
|           EntityId             writerId                       | 
+---------------+---------------+---------------+---------------+ 
+           SequenceNumber       writerSN                       + 
+---------------+---------------+---------------+---------------+ 
~           ParameterList        inlineQos       [only if Q==1] ~ 
+---------------+---------------+---------------+---------------+ 
~  SerializedPayload  serializedPayload  [only if D==1 || K==1] ~ 
+---------------+---------------+---------------+---------------+

 

Submessage Header中的Flags

Q = SubmessageHeader.flags & 0x02

D = SubmessageHeader.flags & 0x04 

K = SubmessageHeader.flags & 0x08

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

D=0和K=0表示没有序列化有效负载子messageelement。

D=1和K=0表示serializedPayload子messageelement包含序列化的数据。

D=0和K=1表示serializedPayload子messageelement包含序列化的键。

D=1和K=1在本协议中是一个无效的组合

 extraFlags

为了支持协议的演进，而不会影响向后兼容性。当前应全部置0

DataFrag Submessage

0...2...........8...............16.............24...............32 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| DATA_FRAG     |X|X|X|X|X|K|Q|E|     octetsToNextHeader        | 
+---------------+---------------+---------------+---------------+ 
|   Flags        extraFlags     |     octetsToInlineQos         | 
+---------------+---------------+---------------+---------------+ 
|           EntityId              readerId                      | 
+---------------+---------------+---------------+---------------+ 
|           EntityId              writerId                      | 
+---------------+---------------+---------------+---------------+ 
+           SequenceNumber        writerSN                      + 
+---------------+---------------+---------------+---------------+ 
|           FragmentNumber       fragmentStartingNum            | 
+---------------+---------------+---------------+---------------+ 
| ushort fragmentsInSubmessage  |     ushort   fragmentSize     | 
+---------------+---------------+---------------+---------------+ 
|           unsigned long            sampleSize                 | 
+---------------+---------------+---------------+---------------+ 
~           ParameterList          inlineQos [only if Q==1]     ~ 
+---------------+---------------+---------------+---------------+ 
~          SerializedPayload           serializedPayload        ~ 
+---------------+---------------+---------------+---------------+

 

Gap Submessage

0...2...........7...............15.............23...............31 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|   GAP         |X|X|X|X|X|X|X|E|      octetsToNextHeader       | 
+---------------+---------------+---------------+---------------+ 
|           EntityId               readerId                     | 
+---------------+---------------+---------------+---------------+ 
|           EntityId               writerId                     | 
+---------------+---------------+---------------+---------------+ 
|                                                               | 
+           SequenceNumber         gapStart                     + 
|                                                               | 
+---------------+---------------+---------------+---------------+ 
|                                                               | 
~           SequenceNumberSet      gapList                      ~ 
|                                                               | 
+---------------+---------------+---------------+---------------+

HeartBeat Submessage

0...2...........7...............15.............23...............31 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|    HEARTBEAT  |X|X|X|X|X|L|F|E|      octetsToNextHeader       | 
+---------------+---------------+---------------+---------------+ 
|           EntityId              readerId                      | 
+---------------+---------------+---------------+---------------+ 
|           EntityId              writerId                      | 
+---------------+---------------+---------------+---------------+ 
|                                                               | 
+           SequenceNumber        firstSN                       + 
|                                                               | 
+---------------+---------------+---------------+---------------+ 
|                                                               | 
+           SequenceNumber        lastSN                        + 
|                                                               | 
+---------------+---------------+---------------+---------------+ 
|           Count                 count                         | 
+---------------+---------------+---------------+---------------+

HeartBeatFrag Submessage

0...2...........8...............16.............24...............32 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| HEARTBEAT_FRAG|X|X|X|X|X|X|X|E|       octetsToNextHeader      | 
+---------------+---------------+---------------+---------------+ 
|           EntityId              readerId                      | 
+---------------+---------------+---------------+---------------+ 
|           EntityId              writerId                      | 
+---------------+---------------+---------------+---------------+ 
|                                                               | 
+           SequenceNumber        writerSN                      + 
|                                                               | 
+---------------+---------------+---------------+---------------+ 
|           FragmentNumber l      astFragmentNum                | 
+---------------+---------------+---------------+---------------+ 
|            Count                count                         | 
+---------------+---------------+---------------+---------------+

 

InfoDestination Submessage

0...2...........8...............16.............24...............32 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|   INFO_DST    |X|X|X|X|X|X|X|E|       octetsToNextHeader      | 
+---------------+---------------+---------------+---------------+ 
|                                                               | 
+                                                               + 
|                   GuidPrefix      guidPrefix                  | 
+                                                               + 
|                                                               | 
+---------------+---------------+---------------+---------------+

InfoReply Submessage

0...2...........8...............16.............24...............32 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|  INFO_REPLY   |X|X|X|X|X|X|M|E|       octetsToNextHeader      | 
+---------------+---------------+---------------+---------------+ 
|                                                               | 
~         LocatorList   unicastLocatorList                      ~ 
|                                                               | 
+---------------+---------------+---------------+---------------+ 
|                                                               | 
~         LocatorList   multicastLocatorList [ only if M==1 ]   ~ 
|                                                               | 
+---------------+---------------+---------------+---------------+

 

InfoSource Submessage

0...2...........8...............16.............24...............32 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|   INFO_SRC    |X|X|X|X|X|X|X|E|       octetsToNextHeader      | 
+---------------+---------------+---------------+---------------+ 
|            long                 unused                        | 
+---------------+---------------+---------------+---------------+ 
|     ProtocolVersion version   |      VendorId vendorId        | 
+---------------+---------------+---------------+---------------+ 
|                                                               | 
+                                                               + 
|                   GuidPrefix     guidPrefix                   | 
+                                                               + 
|                                                               | 
+---------------+---------------+---------------+---------------+

 

InfoTimestamp Submessage

0...2...........8...............16.............24...............32 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|    INFO_TS    |X|X|X|X|X|X|I|E|       octetsToNextHeader      | 
+---------------+---------------+---------------+---------------+ 
|                                                               | 
+               Timestamp timestamp [ only if I==0 ]            + 
|                                                               | 
+---------------+---------------+---------------+---------------+

Pad Submessage

0...2...........8...............16.............24...............32 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|      PAD      |X|X|X|X|X|X|X|E|        octetsToNextHeader     | 
+---------------+---------------+---------------+---------------+

 

NackFrag Submessage

0...2...........8...............16.............24...............32 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|   NACK_FRAG   |X|X|X|X|X|X|X|E|        octetsToNextHeader     | 
+---------------+---------------+---------------+---------------+ 
|           EntityId               readerId                     | 
+---------------+---------------+---------------+---------------+ 
|           EntityId               writerId                     | 
+---------------+---------------+---------------+---------------+ 
|                                                               | 
+           SequenceNumber         writerSN                     + 
|                                                               | 
+---------------+---------------+---------------+---------------+ 
|                                                               | 
~           FragmentNumberSet      fragmentNumberState          ~ 
|                                                               | 
+---------------+---------------+---------------+---------------+ 
|           Count                  count                        | 
+---------------+---------------+---------------+---------------+

 

InfoReplyIp4 Submessage(PSM specific)

0...2...........8...............16.............24...............32 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| INFO_REPLY_IP4|X|X|X|X|X|X|M|E|      octetsToNextHeader       | 
+---------------+---------------+---------------+---------------+ 
|                                                               | 
+            LocatorUDPv4   unicastLocator                      + 
|                                                               | 
+---------------+---------------+---------------+---------------+ 
|                                                               | 
+            LocatorUDPv4   multicastLocator [ only if M==1 ]   + 
|                                                               | 
+---------------+---------------+---------------+---------------+

 

酱香巧克粒
关注
专栏目录
RTPS协议
天赐好车的博客
01-28 803
RTPS 协议通常与 DDS（Data Distribution Service）一起使用，DDS 是一种基于 RTPS 协议的中间件，用于实现分布式实时系统的构建和管理。DDS 提供了更高级的功能，如数据过滤、数据缓存和主题管理等，使得应用程序可以更方便地使用 RTPS 协议进行数据分发和通信。定义主题和数据类型：主题是用于数据分发的通道，您需要定义主题和数据类型以匹配您要分发的数据。发布数据：发布者将数据发布到指定的主题中。可靠性：RTPS 协议支持数据的可靠性传输，可以保证数据的完整性和一致性。
实时发布订阅协议（RTPS）DDS互操作网络协议规范-中文翻译
pony12的专栏
04-01 2899
翻译 实时发布订阅协议（RTPS）DDS互操作网络协议规范-中文翻译_005 关键字：OMG，RTPS，DDS The Real-time Publish-Subscribe Protocol (RTPS) DDS Interoperability Wire Protocol Specification，Version 2.2，September 2014 8.2.5. RTPS 参与者（P...
RTPS协议概述
CHALLENG_EVERYTHING的专栏
04-06 1365
RTPS协议主要由四个部分组成：​ 发现模块是定义了RTPS的参与者（Participant）获取其他RTPS的参与者（Participant），端点（Endpoint）的协议，使得每个参与者（Participant）能够了解到整个网络中其他参与者的存在并且相互匹配。​ metatraffic通信使得RTPS的参与者（Participant）可以获取到所有Participant，Reader以及Writer的快照并且让本地Reader和远端Writer以及本地Writer和远端Reader之间通信。​ RT
RTPS协议之Messages Module子消息
最新发布
u010378559的博客
07-23 869
这个子消息允许Reader通知Writer它接收到的序列号和它仍然缺少的序列号。既可以用于正向确认，也可以用于负向确认（正面确认代表Reader成功接收到了某一序列号的数据，负面确认则表示Reader没有接收到某一序列号的数据，需要Writer重新发送。简单来说，正面确认就是“我收到了你的数据”，而负面确认就是“我没收到你的数据，需要你重新发送”。可能的变化包括数据对象的值的变化以及数据对象生命周期的变化。Reader通过发送AckNack消息给Writer，来表示其对Writer使用的序列号的状态。
RTPS协议简介
qq_29207197的博客
03-14 6167
RTPS协议简介 Domain（域）：定义了一个独立的通信平面，多个域是同时独立存在的。域包含了多个Participant和发送接收数据的元素。 Participant（参与者）：包含多个Reader端点和Writer端点 Reader：接收数据端点 Writer：发送数据端点 Topic（主题）：通信是围绕着Topic进行的，所以，Topic定义了要通信的数据内容，Topic不属于任何...
rtps协议——综述
setary0301的博客
06-06 234
7.4 RTPS平台依赖模块（PIM）7.5 RTPS平台特殊模块（PSM）7.2 DDS有线协议的需求。7.3 RTPS有线协议。7.6 RTPS传输模块。
深入分析 RTPS协议
道
06-03 9937
在我们上网时难免会因为这样那样的问题对通信产生疑问。当我们产生了疑问之后，这里推荐使用wireshark进行抓包分析。不是吹牛，wireshark真的是一款实用有效的必备“良药”。 wireshark是最流行的网络嗅探器之一，能在多种平台上抓取和分析网络包，windows/Linux/Mac等，拥有非常友好的界面。 追溯大学期间的《计算机网络》，就是下面这本书。全靠死记硬背才把OSI七层模型，TCP/IP五层模型（也有说是四层模型，没关系）记下来，考完试然后就又忘记了。这时候又要介绍“大哥”了，如果我当
DDS-RTPS实时发布订阅协议
01-09
这个版本提供了关于如何构建和实现DDS-RTPS协议的详细规范，以便于开发人员理解和实现DDS-RTPS兼容的系统。标准文档的官方URL为http://www.omg.org/spec/DDSI-RTPS/2.3，同时提供了机器可读的文件供开发者下载和使用...
DDS-RTPS 实时发布订阅协议 DDS互操作协议规范(Version 2.1)
01-30
实时发布订阅（RTPS）协议源于工业自动化，并得到了作为实时工业以太网套件IEC-PAS-62030的一部分的IEC。这是一项经现场验证的技术，目前部署在全球数千个工业设备中。 本规范定义了消息格式、解释和使用场景，这些...
数据分发服务DDS及实时发布订阅协议RTPS-DDS互操作协议规范下载
DDS技术交流推广大本营
02-22 1765
数据分发服务（DDS） Data Distribution Service (DDS)V1.4 实时发布订阅协议（RTPS） The Real-time Publish-Subscribe Protocol (RTPS) DDS Interoperability Wire Protocol SpecificationV2.2 DDS及RTPS规范下载 提取码：9b27 自主知识产权BLUE D...
RTPS_v2_1协议以太网报文，版本v2.1，可以用wireshark软件打开
10-10
RTPS协议以太网报文，版本v2.1，可以用wireshark软件打开，适用于学习RTPSv2报文解析，学习各种工业以太网协议可参考本人其他下载文件
用于嵌入式设备的 RTPS/DDS 协议的可移植实现_C++_代码_相关文件_下载
07-07
嵌入式RTPS 该存储库包含 EmbeddedRTPS 的源代码，嵌入式系统的实时发布订阅协议 (RTPS) 的可移植和开源 C++ 实现。RTPS 基于发布-订阅机制，是数据分发服务 (DDS) 的核心。DDS 用于机器人操作系统 2 (ROS2) 中的许多其他应用程序，也是 AUTOSAR 自适应平台的一部分。EmbeddedRTPS 允许将具有以太网功能的微控制器作为一流的参与者集成到基于 DDS 的系统中。 EmbeddedRTPS 是可移植的，因为它只使用可用于大量嵌入式系统的轻量级 IP 和 FreeRTOS API。一旦构建了可能的端点，嵌入式RTPS 就避免了动态内存分配。请注意，embeddedRTPS 仅实施基本的服务质量 (QoS) 策略，远非完整的 RTPS 实施。 特征 Discovery实现了简单参与者发现协议 (SPDP) 以及简单端点发现协议 (SEDP)。 互操作性我们已经成功测试了与FastDDS 2.3.1的互操作性 QoS 策略实现了可靠和尽力而为的端点。 更多详情、使用方法，请下载后阅读README.md文件
RTPS_v1_3协议以太网报文，版本V1.3，可以用wireshark软件打开
10-10
RTPS协议以太网报文，版本v1.3，和版本2x的不太一样，可以用wireshark软件打开，适用于学习RTPSv1报文解析，学习各种工业以太网协议可参考本人其他下载文件
RTPS技术规范（DDS）
10-18
RTPS技术规范介绍The Real-Time Publish-Subscribe Wire Protocol DDS Interoperability™ Wire Protocol Specification, V2.0／２.１／２.２内容；
RTPS协议数据结构（V2.1）
Alive的博客
10-11 3994
参考 ： 主要为 https://community.rti.com/static/documentation/connext-dds/5.2.3/doc/manuals/wireshark/RTPS_Protocol_v2.1.pdf 其余包括 http://www.eprosima.com/docs/fast-rtps/1.6.0/html/index.html https://i...
OMG--RTPS（Real Time Publish Subscribe Protocol）
天道酬勤
06-11 2077
RTPS（Real Time Publish Subscribe Protocol）实时发布订阅协议。
车载通信与DDS标准解读系列（4）：DDSI-RTPS协议
经纬恒润的官方博客
04-03 1293
在DDS协议中，主要描述了实现数据分发服务的DCPS模型和QoS策略，但是我们还不清楚数据怎样在网络中传输，想要了解这些内容，就需要请出咱们的数据搬运工——RTPS。
实时发布订阅协议（RTPS）DDS互操作网络协议规范-中文翻译_002
DDS技术交流推广大本营
03-18 5770
实时发布订阅协议（RTPS）DDS互操作网络协议规范-中文翻译_002 关键字：OMG，RTPS，DDS The Real-time Publish-Subscribe Protocol (RTPS) DDS Interoperability Wire Protocol Specification，Version 2.2，September 2014 7 概述 7.4 RTPS平台无关模型（PIM...
实时发布订阅协议（RTPS）DDS互操作网络协议规范-中文翻译_003
DDS技术交流推广大本营
03-18 3654
关键字：OMG，RTPS，DDS The Real-time Publish-Subscribe Protocol (RTPS) DDS Interoperability Wire Protocol Specification，Version 2.2，September 2014 8.平台无关模型（PIM） 8.1 引言 本节定义了RTPS协议的平台无关模型（PIM）。后续小节将PIM映射到各种平...
"DDS-RTPS实时发布订阅协议版本2.3详解与规范解读
DDS-RTPS协议提供了一种基于发布和订阅模型的通信机制。通过该协议，数据生产者可以将实时数据发布到一个或多个特定的话题（Topic），而数据消费者则可以通过订阅这些话题来接收和处理这些实时数据。DDS-RTPS协议...
评论 4
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值