DDS 规范要求存在一种 liveliness 机制。RTPS 使用 Writer Liveliness Protocol 满足此需求。WLP 协议定义了如何在两个 Participant 中交换信息以获取 Participant 中 Writers 的存活状态。
所有的实现都必须实现 WLP 协议以满足互操作性。
一般方法
WLP 使用预定义的内置端点。使用内置端点意味着一旦一个 Participant 发现了另一个 Participant，那么它就能假设此 Participant 的内置端点存在并建立连接。
内置端点和应用定义的端点在通信时使用相同的协议。
WLP 使用的内置端点
WLP 使用的内置端点为 BuiltinParticipantMessageWriter 和 BuiltinParticipantMessageReader。其名字反应了其可被用于通用目的。目前这些端点用于 liveliness，但是在未来可用于其它数据。
RTPS 保留以下 EntitiId_t 用于 WLP 的内置端点：
ENTITYID_P2P_BUILTIN_PARTICIPANT_MESSAGE_WRITER
ENTITYID_P2P_BUILTIN_PARTICIPANT_MESSAGE_READER
这些 EntitiId_t 的实际值由 PSM 模块定义。
BuiltinParticipantMessageWriter 和 BuiltinParticipantMessageReader QoS
为了互操作性，BuiltinParticipantMessageWriter 和 BuiltinParticipantMessageReader 需要使用以下 QoS：
durability.kind = TRANSIENT_LOCAL_DURABILITY
history.kind = KEEP_LAST_HISTORY_QOS
history.depth = 1
BuiltinParticipantMessageWriter 将使用 reliability.kind = RELIABLE_RELIABILITY_QOS。
BuiltinParticipantMessageReader 即可以设置为 RELIABLE_RELIABILITY_QOS 也可以设置为 BEST_EFFORT_RELIABILITY_QOS。如果 BuiltinParticipantMessageReader 被配置为 BEST_EFFORT_RELIABILITY_QOS 则 ParticipantProxy::builtinEndpointQos 中的 BEST_EFFORT_PARTICIPANT_MESSAGE_DATA_READER 需要置 1。
如果 ParticipantProxy::builtinEndpointQos 包含于 SPDPdiscoveredParticipantData 则 BuiltinParticipantMessageWriter 在其中作为 BuiltinParticipantMessageReader flags。若 ParticipantProxy::builtinEndpointQos 未包含，则 BuiltinParticipantMessageWriter 认为 BuiltinParticipantMessageReader 配置为 RELIABLE_RELIABILITY_QOS。
WLP 内置端点关联的数据类型
每个 RTPS 端点都有一个 HistoryCache 用于储存同端点关联的数据对象。RTPS 内置端点也不例外。
下面代表了 DCPSParticipantMessage Topic 关联的数据类型：
使用 BuiltinParticipantMessageWriter 和 BuiltinParticipantMessageReader 实现 Writer Liveliness Protocol
属于 Participant 的 Writers 通过向 BuiltinParticipantMessageWriter 中写入 sample 来断言其存活状态。如果 Participant 中含有至少一个 AUTOMATIC_LIVELINESS_QOS 的 writer，则一个 sample 将会被发送，其发送速率至少比所有设置为 AUTOMATIC_LIVELINESS_QOS 的 writer 的最小的 leaseDuration 快。类似地，如果 Participant 包含了至少要给 MANUAL_BY_PARTICIPANT_QOS 的 wrtier，另一个 sample 会被发送，其发送速率至少于同 MANUAL_BY_PARTICIPANT_QOS 的最小 leaseDuration 相同。这两个 instance 是正交的以至于 Participant 能够包含两种不同 QoS 的 Writers。两个 Instance 必须周期性地写入。这个 Instances 通过 DDS key 进行区分，DDS key 由 participantGuidPrefix 和 kind 字段组成。participantGuidPrefix和kind字段。通过该协议处理的两种类型的动态 QoS 中的每一种都会产生一个唯一的 kind 字段，因此在 HistoryCache 中形成两个不同的实例。
两种 liveliness 再 participantGuidPrefix 都包含了 Participant 的 GuidPrefix_t，因而能够用来判断 Writers 的存活状态。
BuiltinParticipantMessageWriter 和 BuiltinParticipantMessageReader 并没有实现 MANUAL_BY_TOPIC_LIVELINESS_QOS，它在 8.7.2.2.3 中有详细的描述。
Liveliness
Liveliness 有三种值：
| kind | 解释 | 影响范围 |
|---|---|---|
DDS_AUTOMATIC_LIVELINESS_QOS | Entity 的 Liveliness 由 BuiltinParticipantMessageWriter 自动维护。因此 BuiltinParticipantMessageWriter 发送消息的间隔必须快于 lease duration 的 writer。 | 若进程存活，则认为所有 Entity 存活 |
DDS_MANUAL_BY_PARTICIPANT_LIVELINESS_QOS | Liveliness 由 DDS_MANUAL_BY_PARTICIPANT_LIVELINESS_QOS 维护。DDS_MANUAL_BY_PARTICIPANT_LIVELINESS_QOS 周期性地检查所有 Writer 是否调用过 | 若 Participant 依然存活，则认为所有 Entity 也存活。 |
DDS_MANUAL_BY_TOPIC_LIVELINESS_QOS | Liveliness 通过发送设置了 liveliness 的 Data 或 HeartBeat 消息维护。如果 Writer 调用了 | Writer 当且仅当自己存活的时候才认为存活。 |
DDS_AUTOMATIC_LIVELINESS_QOS 和 DDS_MANUAL_BY_PARTICIPANT_LIVELINESS_QOS 两者发送两种不同的消息数据以进行区分。
Liveliness 和 Wlp 的关系如下：
对于 Local Writer：
DDS_AUTOMATIC_LIVELINESS_QOS: Wlp 帮助发送 liveliness 消息。
DDS_MANUAL_BY_PARTICIPANT_LIVELINESS_QOS: Writer 自己发送 liveliness 消息。
DDS_MANUAL_BY_TOPIC_LIVELINESS_QOS: Writer 自己发送 liveliness 消息。
对于 Remote Writer：
DDS_AUTOMATIC_LIVELINESS_QOS: 只要对面任一 entity 存活，就认为存活。
DDS_MANUAL_BY_PARTICIPANT_LIVELINESS_QOS: 只要对面任一 entity 存活，就认为存活。
DDS_MANUAL_BY_TOPIC_LIVELINESS_QOS: Datawriter 消息一旦过期就认为失活。