Single Routing Service Asymmetric TCP

3 posts / 0 new
Last post
Offline
Last seen: 1 year 6 months ago
Joined: 04/25/2017
Posts: 3
Single Routing Service Asymmetric TCP

Hello,

In my application, I need to establish communication between:

On one side: A network of Raspberry Pis, each on a different network.

On the other: A DDS application on a LAN.

To do this, I am trying to implement option number 3 in the post (Is it possible to RTI Routing Service on a Raspberry Pi | https://community.rti.com/forum-topic/it-possible-rti-routing-service-raspberry-pi), which explains how to deploy a single routing service for asymmetric TCP Transport.

For now, I am using the shapes demo of RTI Connext Launcher 5.2.3 on a Linux Desktop in a LAN (Paris side), and a Linux Laptop on a different network.

 

On the Paris LAN:

My router public address: 131.94.xxx.xx

My computer's (on which my DDS application runs) private address on the Paris LAN: 192.168.xx.xx 

Port forwarding:

On my router, I do port forwarding: 8600 → 192.168.xx.xx:8001.

Routing Service:

I attached the files for the routing service script and its configuration file.

In the Routing Service script:

I specify the initial peers as the public IP address of the Linux laptop on which my end DDS applications will run: 131.94.xxx.xx

In the configuration file:

The routing service DomainParticipant 1 (on the Paris WAN) is configured with the TCP WAN Transport.

Configuring my end-user DDS application for UDP, Shared Memory:

I configure my DDS application for UDP, Shared Memory by configuring my Shapes Demo to use the profile DefaultLibrary::HighThroughputfrom QoS profile file USER_QOS_PROFILES_ParisLAN.xml(in the zip file attached in this post).

I then publish to domain 0.

 

On the London side:

I configure my DDS application for TCP by configuring my Shapes Demo to use the profile “User_RTI_Shapes_Lib::Asymmetric_TCP_Cloud_Client” from QoS profile file “USER_RTI_SHAPES_DEMO_QOS_PROFILES_London.xml” (in the zip file attached in this post).

I then subscribe to the shape I published on the Paris LAN (on domain 0).

 

With those settings, the communication is not established. Any advice is appreciated on which configuration settings I am missing or I am specifying wrongly.

Fernando Garcia's picture
Offline
Last seen: 1 day 20 hours ago
Joined: 05/18/2011
Posts: 197

Hi,

From your example it looks like the bind port of Routing Service should be 8001 instead of the "external" port 8600. That is:

...
<element>
   <name>dds.transport.TCPv4.tcp1.public_address</name>
   <value>131.95.xxx.xx:8001</value>
</element>
<element>
    <name>dds.transport.TCPv4.tcp1.server_bind_port</name>
    <value>8001</value>
</element>
...

The London side looks alright, because you are adding your "external" port to the discovery peers: tcpv4_wan://131.94.xxx.xx:8600.

I realize you are reusing the  Asymmetric_TCP_Cloud_Client QosProfile example on USER_RTI_SHAPES_DEMO_QOS_PROFILES.xml. We created that example to communicate with a Routing Service counterpart that runs on a server on Amazon EC2. Did you check out the  AsymmetricTCPCloudServer configuration in USER_ROUTING_SERVICE.xml?

Let me know if this helps.

Fernando.

Offline
Last seen: 1 year 6 months ago
Joined: 04/25/2017
Posts: 3

Hello and thanks for your reply.

On the Paris Side:

With respect to your suggestion to use the internal port instead of the external, all the following guides show that the external port is to be used:

  1. Figure 7.5 in RTI_Routing_Service_UsersManual (5.2.3) https://community.rti.com/static/documentation/connext-dds/5.2.3/doc/manuals/routing_service/RTI_Routing_Service_UsersManual.pdf
  2. Script in Section 7.2.2 in RTI_Routing_Service_UsersManual (5.2.3) https://community.rti.com/static/documentation/connext-dds/5.2.3/doc/manuals/routing_service/RTI_Routing_Service_UsersManual.pdf
  3. Table 35.1 [Properties for NDDS_Transport_TCPv4_Property_t] in the RTI_ConnextDDS_CoreLibraries_UsersManual. (5.2.3) https://community.rti.com/static/documentation/connext-dds/5.2.3/doc/manuals/connext_dds/RTI_ConnextDDS_CoreLibraries_UsersManual.pdf                   It says that: “The address is the public address of the IP router that provides access to the WAN. The port is the IP router port that is used to reach the private server_bind_port inside the LAN from the outside.”
  4. Also instructed in https://community.rti.com/forum-topic/it-possible-rti-routing-service-raspberry-pi , which I used in the first place to setup my single routing service two-way communication.

Despite this, I still did some trials, changing the port to 8001, but it did not help.
 
As for the suggestion to use the AsymmetricTCPCloudServer routing service configuration in USER_ROUTING_SERVICE.xml :
I attach the Routing Service Configuration File that I have used this time (with the AsymmetricTCPCloudServer Configuration).
Unfortunately, shifting to this configuration did not help too.
 
Furthermore, I have made the NDDS_DISCOVERY_PEERS variable empty in the routing service script, as advised in https://community.rti.com/forum-topic/it-possible-rti-routing-service-raspberry-pi.
 
On the London Side (no Routing Service), I have not changed anything:

I configure my DDS application for TCP by configuring my Shapes Demo to use the profile “User_RTI_Shapes_Lib::Asymmetric_TCP_Cloud_Client” from QoS profile file “USER_RTI_SHAPES_DEMO_QOS_PROFILES_London.xml” (in the zip file attached in this post).

 

I still can't point out the thing I am doing wrong in the whole setup configuration.