Cloud Discovery Service in LAN.

8 posts / 0 new
Last post
Offline
Last seen: 4 years 6 months ago
Joined: 05/09/2019
Posts: 7
Cloud Discovery Service in LAN.

I have two different subnet in my LAN environment, 10.1.1.x & 10.1.2.x.

I run cloud discovery service in one host (10.1.1.184). When I start CDS using

"%NDDSHOME%\bin\rticlouddiscoveryservice.bat" -transport tcpv4_lan:27400 -verbosity 6

Everything is perfect. Publisher & Subscriber in 10.1.1.x & 10.1.2.x can find each others.
One publisher in 10.1.2.199 and one subscriber in 10.1.1.184 and 10.1.1.209.

Here is my QoS profile of DDS application(HelloWorld):

<participant_qos>
<participant_name>
<name>HelloWorldParticipant</name>
<role_name>HelloWorldParticipantRole</role_name>
</participant_name>

<discovery>
<initial_peers>
<element>rtps@tcpv4_lan://10.1.1.184:27400</element>
</initial_peers>
</discovery>

<property>
<value>
<element>
<name>dds.transport.load_plugins</name>
<value>dds.transport.TCPv4.tcp1</value>
</element>
<element>
<name>dds.transport.TCPv4.tcp1.library</name>
<value>nddstransporttcp</value>
</element>
<element>
<name>dds.transport.TCPv4.tcp1.create_function</name>
<value>NDDS_Transport_TCPv4_create</value>
</element>
<element>
<name>dds.transport.TCPv4.tcp1.parent.classid</name>
<value>NDDS_TRANSPORT_CLASSID_TCPV4_LAN</value>
</element>
<element>
<name>dds.transport.TCPv4.tcp1.server_bind_port</name>
<value>27400</value>
</element>
</value>
</property>
</participant_qos>

Now I start CDS using:

"%NDDSHOME%\bin\rticlouddiscoveryservice.bat" -cfgFile MyCDS.xml -cfgName FoyaCSLan -verbosity 6

Here is MyCDS configuration XML file:

<cloud_discovery_service name="FoyaCSLan">
<annotation>
<documentation><![CDATA[
Foya Cloud Service configuration for Lan.
]]>
</documentation>
</annotation>

<domain_list>
<allow_domain_id>DOMAIN_LIST_ALL</allow_domain_id>
</domain_list>

<transport>
<element>
<alias>tcpv4_lan</alias>
<receive_port>27400</receive_port>
<property>
<element>
<name>dds.transport.load_plugins</name>
<value>dds.transport.TCPv4.tcp1</value>
</element>
<element>
<name>dds.transport.TCPv4.tcp1.library</name>
<value>nddstransporttcp</value>
</element>
<element>
<name>dds.transport.TCPv4.tcp1.create_function</name>
<value>NDDS_Transport_TCPv4_create</value>
</element>
<element>
<name>dds.transport.TCPv4.tcp1.parent.classid</name>
<value>NDDS_TRANSPORT_CLASSID_TCPV4_LAN</value>
</element>
<element>
<name>dds.transport.cds.tcp1.public_address</name>
<value>10.1.1.184</value>
</element>
<element>
<name>dds.transport.cds.tcp1.server_bind_port</name>
<value>27400</value>
</element>
</property>
</element>
</transport>
</cloud_discovery_service>

Now 10.1.2.199 & 10.1.1.209 is work normally. But when I start subscriber in the same host that is running CDS (10.1.1.184) I got the error messages:

[D0000|CREATE Participant|D0000|ENABLE] RTIOsapiSocket_bindWithIP:OS bind() failure, error 0X271D: An attempt was made to access a socket in a way forbidden by its access permissions.

[D0000|CREATE Participant|D0000|ENABLE] NDDS_Transport_UDPv4_Socket_bindWithIp:OS bind() failure, error 0X5: AccessDenied.

[D0000|CREATE Participant|D0000|ENABLE] DDS_DomainParticipant_enableI:Automatic participant index failed to initialize. PLEASE VERIFY CONSISTENT TRANSPORT / DISCOVERY CONFIGURATION.
[NOTE: On Windows, verify at least one network interface is enabled.]
[D0000|CREATE Participant] DDS_DomainParticipantFactory_create_participant:ERROR: Failed to auto-enable entity
create_participant error

Why? How can I fix this problem?

Gerardo Pardo's picture
Offline
Last seen: 1 week 1 day ago
Joined: 06/02/2010
Posts: 602

Hi,

It seems you are specifying the same port number (dds.transport.cds.tcp1.server_bind_port  is set to 27400) for both the Cloud Discovery Service (CDS) and the Subscribing applications. Because of this you cannot run them on the same host: Only one process per operating-system instance can bind to a port number.

To avoid this you can change the configuration of the subscribing application to use a different port number when running on the same host as the CDS.

Gerardo

 
Offline
Last seen: 4 years 6 months ago
Joined: 05/09/2019
Posts: 7

Hi Gerardo,

Thanks for your reply. I have two way to start the Cloud Discovery Service. One way is "%NDDSHOME%\bin\rticlouddiscoveryservice.bat" -transport tcpv4_lan:27400 -verbosity 6. Another way is "%NDDSHOME%\bin\rticlouddiscoveryservice.bat" -cfgFile MyCDS.xml -cfgName FoyaCSLan -verbosity 6.

My Pub/Sub application always use the same configuration. But I got error when I start CDS by configuration XML file but work fine when I start CDS by command line. Do you know why?

Offline
Last seen: 4 years 6 months ago
Joined: 05/09/2019
Posts: 7

Hi Gerardo, 

FYI,

Here is CDS information when I start CDS by command line (-transport tcpv4_lan:27400):

[CDS DETECTOR] listening for announcements on:
tcp4_lan://0000:0000:0000:0000:FFFF:6B08:0A01:01B8:27400,
tcp4_lan://0000:0000:0000:0000:FFFF:6B08:A9FE:8F1A:27400

Information when I start CDS by configuration file:

[CDS DETECTOR] listening for announcements on:
udpv4://10.1.1.184:7400, udpv4://169.254.143.26:7400,
tcp4_lan://0000:0000:0000:0000:FFFF:1CE8:0A01:01B8:27400,
tcp4_lan://0000:0000:0000:0000:FFFF:1CE8:A9FE:8F1A:27400,
tcp4_lan://0000:0000:0000:0000:FFFF:6B08:0A01:01B8:27400,
tcp4_lan://0000:0000:0000:0000:FFFF:6B08:A9FE:8F1A:27400

 

Gerardo Pardo's picture
Offline
Last seen: 1 week 1 day ago
Joined: 06/02/2010
Posts: 602

Hi Arthur,

Could you try removing the following element from the XML configuration of the CDS?

<element>
  <name>dds.transport.cds.tcp1.public_address</name>
  <value>10.1.1.184</value>
</element>

Normally the public_address is needed when you are behind a NAT which does not seem to be your case. I wonder if that setting is confusing the CDS.

Gerardo

Offline
Last seen: 4 years 6 months ago
Joined: 05/09/2019
Posts: 7

Hi, Gerardo,

I removed the public_address and got the same result.

[CDS DETECTOR] listening for announcements on:
udpv4://10.1.1.184:7400, udpv4://169.254.143.26:7400, tcp4_lan://0000:0000:0000:0000:FFFF:1CE8:0A01:01B8:27400, tcp4_lan://0000:0000:0000:0000:FFFF:1CE8:A9FE:8F1A:27400, tcp4_lan://0000:0000:0000:0000:FFFF:6B08:0A01:01B8:27400, tcp4_lan://0000:0000:0000:0000:FFFF:6B08:A9FE:8F1A:27400

CDS DETECTOR bind the network interface automatically.

asanchez's picture
Offline
Last seen: 4 years 5 months ago
Joined: 11/16/2011
Posts: 50

Hi Arthur,

Note that in your configuration you are registering another instance of the TCP transport, with name TCPv4. This is causing the additional TCP receive resources you see in the logs. The only setting you need in your configuration is the following:

  <transport>

    <element>

       <alias>tcpv4_lan</alias>
        <receive_port>27400</receive_port>
        <property>
            <element>
                 <name>dds.transport.cds.tcp1.public_address</name>
                 <value>10.1.1.184</value>
            </element>
        </property>
    </element>
</transport>
 

With that configuration you should see:

[CDS DETECTOR] listening for announcements on: udpv4://10.1.1.184:7400, udpv4://169.254.143.26:7400, tcp4_lan://0000:0000:0000:0000:FFFF:6B08:C0A8:0144:27400, tcp4_lan://0000:0000:0000:0000:FFFF:6B08:0A32:022E:27400

 The difference you observe when you run with the command-line option -transport is because this option overrides all the settings from the configuration. By default CDS, will always use the UDP plus any additional transports specified in the <transport>  element.
 
- Antonio

 

Offline
Last seen: 4 years 6 months ago
Joined: 05/09/2019
Posts: 7

Hi Antonio,

Thank you for your reply. I modified my configuration as your description. The DDS applications still get the error messages. 

I had compared the CDS debug information between command line and XML configuration file.

Command line: 

[CDS DETECTOR] listening for announcements on:
tcp4_lan://0000:0000:0000:0000:FFFF:6B08:0A01:01B8:27400, tcp4_lan://0000:0000:0000:0000:FFFF:6B08:A9FE:8F1A:27400

XML file:

[CDS DETECTOR] listening for announcements on:
udpv4://10.1.1.184:7400, udpv4://169.254.143.26:7400, tcp4_lan://0000:0000:0000:0000:FFFF:6B08:0A01:01B8:27400, tcp4_lan://0000:0000:0000:0000:FFFF:6B08:A9FE:8F1A:27400

 

I found the difference is the UDP port 7400 was bind when I start CDS using configuration file but command line didn't. So how can I run DDS applications and CDS in the same host?

Thanks.

Kind regards,

 

-Arthur.