首先我们来说说什么是Discovery?
Discovery是RTI Connext DDS Micro的幕后用来发现彼此对方的DomainParticipant, DataWriters, DataReaders的过程。 每个Participants维护一个关于当前一个DDS Domain的DataReaders / DataWriters的数据库。 这个数据库就是让DW和DR能够沟通的桥梁，为了创建和刷新这个数据库，每个应用程序都需要follow对应的discovery process. 在这里用的叫Simple Discovery Protocol(SDP),他包含了两个阶段:
- Simple Participant Discovery - 先查找Participants
- Simple Endpoint Discovery - 再查找DW / DR
这两个阶段的目的都是为了帮每个participants构建他peers list所对应的remote pariticipants的数据库。 peers_list是participants可以交流的node list,他从initial_peers list开始（通过QoS）,然后根据你是否设置accept_unknown_peers flag来选择是否支持其他node,不然就是除了initial_peers以外需要手动通过add_peer()来添加
Discovery process会自动开始，你不需要使用任何特殊的代码来启动，下面我们来简单赘述下SDP的各个阶段：
Simple Participant Discovery(SPDP)
这个阶段是让DomainParticipants来学会知道彼此的阶段。通过发送Participant Declaration Message(Participant DATA submessage)在同一个DDS domain里，他包括了DomainParticipant的unique id(GUID), transport locators(地址和端口号), QoS.这段消息会保持一个周期性的发送并且采用的是best-effort的沟通方式。Participants DATAs通过周期性的发送来保持DomainParticipant的liveliness.他们也用来沟通关于DomainParticipant's QoS的概念。只有当DomainParticipant内部的QoS变化才会被传播。
当收到Remote Participant的discover information, RTI Connext DDS会去判断是否local participants会去match这个远端。只有当本地和远端的participant拥有相同的Domain ID以及Domain Tag的情况下，才会出现local和remote的'match'标志。整个match process会在你local participant接收到discovery information的时候就开始，当没有任何macth的时候，DATA会被忽略，最终的结果就是remote participant(他所有对应的entities)不会被发现。
当DomainParticipant被删除的时候，一个participant DATA(delete) submessage连同DomainParticipant的GUID会被遗弃发送。GUID对于某个entity来说都是唯一的，他由GUID前缀和Entity ID来决定，默认来输GUID是通过计算ID address和process ID来生成的，entityID是可以直接通过应用程序来设置的。
当一对remote participant和local participant发现了彼此之后，他们就会移向第二个阶段 - 即Endpoint Discovery Phase,这个阶段就是让DataWriters / DataReaders发现彼此的阶段
Simple Endpoint Discovery(SEDP)
这个阶段是DW和DR发现彼此的阶段。关于你应用程序DataReaders / DataWriters的GUID, QoS等会通过发送publication/subscription declarations在DATA messages(publiccation DATAs / subscription DATAs)来进行交流，整个Endpoint Discovery Phase是建立在reliable的通信方式上，这个和第一阶段的Best Effort不同。
这些DATA message会知道DomainParticipant拥有关于他们peers list和其他entrties的完整数据库的前提下才会去交换。交换之后整个discovery process就完成并且系统会转入到steady state. 在Steady(稳定) State下， participants DATAs仍然会周期性发送来保证他们之间的liveness。跟上面提到的类似，如果此时有关于DP QoS的改变或者DP的删除，也会发送对应的DATAs.
当远端的DW / DR被发现的时候，Connext DDS Micro会去判断你是否当前本地的程序有对应的DR和DW会match. 只有当DR和DW拥有相同的Topic, 相同的数据类型，Compatible(兼容) QosPolicies的时候，才会有对应的local / remote的match flag. 此外，当DP设置可以忽略特定的DW和DR的时候，这些entities在matching process的时候不会被考虑进去。
matching process会在一旦remote entity被发现的时候就开始执行，即使整个database还没有构建好也没有关系（此时的应用程序仍然在发现其他的remote entities）. DW / DR只有在彼此的应用程序都hook up对方并且认为是matching的前提下才能交流。也就是说两端必须都要统一连接才可以。