Participant Discovery not behaving as expected.

4 posts / 0 new
Last post
Offline
Last seen: 6 years 6 months ago
Joined: 06/10/2014
Posts: 49
Participant Discovery not behaving as expected.

Hi,

I have a client-server type configuration.  I have many client machines that do not need to communicate with each other.  They only need to communicate with the Server.  I'm using the participant discovery qos in my USER_QOS_PROFILES.xml in the client and server machines to try and configure this.  (The USER_QOS_PROFILES.xml location is set with NDDS_QOS_PROFILES).

I am removing multicast from the client's initial_peers. My server ip address is assigned with a dhcp server so I don't want to configure an ip address in the client's initial peers so I set the clients to only discover peers on the locallhost but I do set the multicast_receive_addresses. The client also has "accept_unknown_peers" set to true.  I am using multicast discovery on the server.  What I was hoping is that clients would only discover participants local to its machine but will receive the server's discovery and accept participants on the server.  This works but all my client machines are also discovering each other - which is what I was trying to avoid.

The client machines have the following QOS:

<participant_qos>

  <discovery>

    <initial_peers>

        <element>builtin.shmem://</element>

       <element>builtin.udpv4://127.0.0.1</element>

    </initial_peers>

   <multicast_receive_addresses>
         <element>239.255.0.1</element>
    </multicast_receive_addresses>

  <accept_unknown_peers>true</accept_unknown_peers>

</participant_qos>

The server has the following QOS:

<participant_qos>

  <discovery>

    <initial_peers>

       <element>239.255.0.1</element>

       <element>builtin.shmem://</element>

       <element>builtin.udpv4://127.0.0.1</element>

    </initial_peers>

    <multicast_receive_addresses>
         <element>239.255.0.1</element>
    </multicast_receive_addresses>

    <accept_unknown_peers>true</accept_unknown_peers>

</participant_qos>

I'm wondering why the client machines are discovering each other if they only have shmem & local host in their initial_peers list.

Thanks,

Anne Fiore

Organization:
Offline
Last seen: 6 years 6 months ago
Joined: 06/10/2014
Posts: 49

I have a little more information on this:

I used wireshark to capture the rtps data. What I found is that my client machine is publishing to destination 239.255.0.1.  What I don't understand is why the client is sending to the multicast address if I removed multicast from the initial_peers list?  I thought the client would only use shared memory and 127.0.0.1 since these are the only values in initial_peers list?

 

Offline
Last seen: 8 months 3 days ago
Joined: 05/23/2013
Posts: 64

Hi Anne,

Yes. Your client machine shouldn't announce itself first via multicast as it does not have the multicast address in the initial_peers list. However, if you can see that it is annoucning itself via 239.255.0.1 in Wireshark, I guess it would be happened because your client machine is still set to receive discovery messages via 239.255.0.1 (multicast_receive_addresses) so that it answers back to the server via multicast when it receives a discovery mssage from the server. Of couse, the answering message is meant to be delivered only to the server, but other clients could get it as they all use the same multicast address. This is just my guess. To verify this, you can test it out that clients are still sending discovery messages via 239.255.0.1 when the server is not running in the same network.

So if you don't want client machines to communicate each other, It would like to suggest to make the multicast_receive_addresses empty and add the IP address of the server machine in the initial_peers list of client machines.  

Thanks,
Kyoungho

Offline
Last seen: 6 years 6 months ago
Joined: 06/10/2014
Posts: 49

Hi Kyoungho,

The problem must be with the multicast_receive_address.  If I clear that and put the ip address of the server in the client then the clients do not discover each other. Thanks for your help.

Anne