How to set DDS publish and subscribe with different IP

17 posts / 0 new
Last post
Offline
Last seen: 1 week 5 days ago
Joined: 08/11/2019
Posts: 19
How to set DDS publish and subscribe with different IP

Hello,

when I  want to use DDS publish and subscribe with different IP, I find  DISCOVERY mode in the document, but actually I still have no idea to deal with it.

  • First question:  porblem.png  how to use this? Does "Data Structures" part, I just put in .idl file? 

             --> https://community.rti.com/static/documentation/connext-dds/6.0.0/doc/api/connext_dds/tcp_transport/group__NDDS__Transport__TCPv4__Plugin.html

  • Second question: how to use DDS publish in IP#1 and subscribe in IP#2?

             I found this document, it says

                          "3. On another machine, run the subscriber: 

                          UNIX-based Systems
 
                          export NDDS_DISCOVERY_PEERS=tcpv4_wan://<publisher_public_ip:port>./objs/<arch>/Hello sub -a <public_ip:port> -p <bind_port>"
             but I don't know how to set port, any suggestion?

             --> https://community.rti.com/static/documentation/connext-dds/6.0.0/doc/api/connext_dds/tcp_transport/group__TRANSPORTTCPCExampleModule.html

Thanks, I will very grateful for your help.

AttachmentSize
Image icon porblem.png103.06 KB
Keywords:
Howard's picture
Offline
Last seen: 2 weeks 17 hours ago
Joined: 11/29/2012
Posts: 22

Hi Kay,

Do you need to use TCP to connect your applications?  Can you use UDP between your two computers?

Are your two computers on the same network, subnet?  Or are they not on the same network but connected through a WAN?

If you need to use TCP, you can read about the TCP transport in Chapters 37 and 38 of the Connext DDS Users Manual,

https://community.rti.com/static/documentation/connext-dds/6.0.0/doc/manuals/connext_dds/html_files/RTI_ConnextDDS_CoreLibraries_UsersManual/index.htm#UsersManual/PartTCP.htm#parttcp_3522674191_920452%3FTocPath%3DPart%25208%253A%2520RTI%2520TCP%25C2%25A0Transport%7C_____0

To use TCP, you must use the QOS settings to tell DDS to load and use the TCP transport plugin as well as set the NDDS_DISCOVERY_PEERS environment variable.

There are examples that Connext DDS provides in the installation:

/home/<user>/rti_workspace/5.3.1/examples/connext_dds/c/hello_world_tcp

or on Windows

C:\User\<user>\Documents\rti_workspace\5.3.1\examples\connext_dds\c\hello_world_tcp

There are also examples on our community website (just enter "TCP" into the search)

https://community.rti.com/kb/xml-qos-example-using-rti-connext-dds-tcp-transport

If you can use UDP but cannot use multicast between your two machines, then you can use

export NDDS_DISCOVERY_PEERS=192.168.1.1,192.16.2.1,<etc>

just replace the two addresses above with the addresses of your computers and add more addresses as necessary.

Hope this helps.

Offline
Last seen: 1 week 5 days ago
Joined: 08/11/2019
Posts: 19

Hi Howard,

Thank you for your reply, 

I want to use TCP to transfer sensor data because I can't let the data be lost.

Also, I will use WAN,

I want to use several public IP (IPv4) to build a "central star topology" which is one center to become a subscriber (database), all others are publishers (IoT node).

May I ask one more question, does UDP + QoS can make sure data reliability?

Thank you very much.

Kay

Howard's picture
Offline
Last seen: 2 weeks 17 hours ago
Joined: 11/29/2012
Posts: 22

Hi Kay,

DDS can send data reliably over UDP if you set the QOS correctly.  Please search for Reliability in the community web site to find lots of information about this, for example:

https://community.rti.com/kb/configuring-qos-built-profiles

Also, Chapter 10 of the Connext DDS Users Manual offers a full discussion of DDS Reliability

https://community.rti.com/static/documentation/connext-dds/6.0.0/doc/manuals/connext_dds/html_files/RTI_ConnextDDS_CoreLibraries_UsersManual/index.htm#UsersManual/reliable.htm

Thus you do not have to use TCP to get reliable data connections.

HOWEVER, if you are tyring to connect DDS over a public WAN, it's likely that TCP may be a better way to connect than UDP.   The main drawback in using TCP is scalability.  Depending on the number of IoT sensor nodes you have, the server node subscribing to the data would have to open up lots and lots of TCP sockets to make all of the connections.  So depending on the # of sensor nodes, TCP may use up too many resources.

But if you're only doing tests with a few IoT nodes, then TCP should work fine.  And the information that I provide in my first post along with the documentation and examples on our website should help you get that to work.

--Howard

Offline
Last seen: 1 week 5 days ago
Joined: 08/11/2019
Posts: 19

Hi Howard,

I can use hello_world_tcp and it can work by

Publisher:
UNIX-based Systems:
export NDDS_DISCOVERY_PEERS=tcpv4_lan://140.118.121.79:7401
./objs/<arch>/HelloWorld_publisher -p 7400

Subscriber:
UNIX-based Systems:
export NDDS_DISCOVERY_PEERS=tcpv4_lan://140.118.121.79:7400
./objs/<arch>/HelloWorld_subscriber -p 7401

but when I change lan to wan, and change env variable to 

"NDDS_DISCOVERY_PEERS=tcpv4_wan://..."

also add QoS in .xml, it can not work.

may I ask what is the problem or what I ignored?
File Attachments: 
Howard's picture
Offline
Last seen: 2 weeks 17 hours ago
Joined: 11/29/2012
Posts: 22

Hi Kay,

So, why are you trying to use the TCP transport plugin in WAN mode?  It was designed to work when your host machines are trying to connect through NAT'ed routers.  Is that the case?  Please see...

https://community.rti.com/static/documentation/connext-dds/6.0.0/doc/manuals/connext_dds/html_files/RTI_ConnextDDS_CoreLibraries_UsersManual/index.htm#UsersManual/Symmetric_Communication_Across_NATs.htm#37.2_Symmetric_Communication_Across_NATs%3FTocPath%3DPart%25208%253A%2520RTI%2520TCP%25C2%25A0Transport%7C37.%2520TCP%2520Communication%2520Scenarios%7C_____2

If so, you should read through that part of the manual.  I think that you will need to set the public_address property for the TCP transport plugin.  Also, your NAT'ed routers need to be setup to forward external ports to your internal hosts correctly.

Regards,

--Howard

 

 

 

Offline
Last seen: 1 week 5 days ago
Joined: 08/11/2019
Posts: 19

Hi Howard,

I am sorry that I did not mention the overall architecture.

The picture is what I want to implement in the IoT system,

due to this reason, I want to try both TCP & UDP protocol in DDS and compare the efficiency.

Is there any wrong step in this implement the method?

 

First of all, I want to try different IP

Publisher:
UNIX-based Systems:
export NDDS_DISCOVERY_PEERS=tcpv4_lan://140.118.121.79:7400
./objs/<arch>/HelloWorld_publisher  -a 140.118.121.92 -p 7400

Subscriber:
UNIX-based Systems:
export NDDS_DISCOVERY_PEERS=tcpv4_lan://140.118.121.92:7400
./objs/<arch>/HelloWorld_subscriber -a 140.118.121.79 -p 7400

I will not use WAN, could you give me some suggestion?

File Attachments: 
Howard's picture
Offline
Last seen: 2 weeks 17 hours ago
Joined: 11/29/2012
Posts: 22

Can your server ping the 140.118.XX.XX addresses of your PI modules?  On your PI modules can you ping the 140.118.AA.AA address of your server?  If not, then using those 140.181.?.? address in DDS won't work since DDS cannot communicate with a machine by sending packets to those addresses.

When you show the "internet".  Is that the public internet?  How are your PI modules and Servers connected to the internet? 

Are you using an Internet Service Provider?  In that case, you probably have Routers doing NAT (Network Address Translation), then you have to find out the public address used by the Router on your PI network and the public addressed used by the Router on your server network.

With the public address, you have to follow the instructions in the users manual that I referred to you in my last message:

https://community.rti.com/static/documentation/connext-dds/6.0.0/doc/manuals/connext_dds/html_files/RTI_ConnextDDS_CoreLibraries_UsersManual/index.htm#UsersManual/Symmetric_Communication_Across_NATs.htm#37.2_Symmetric_Communication_Across_NATs%3FTocPath%3DPart%25208%253A%2520RTI%2520TCP%25C2%25A0Transport%7C37.%2520TCP%2520Communication%2520Scenarios%7C_____2

Did you read through that?

--Howard

 

 

Offline
Last seen: 1 week 5 days ago
Joined: 08/11/2019
Posts: 19

Hello Howard,

yes,

our PI can ping each other and server, internet part I set a static IP in Ethernet, it means each PI have their own IP which is LAN : 140.118.x.x. provided by school.

in this case, should I set anything else?

thank you very much.

-- Kay

Howard's picture
Offline
Last seen: 2 weeks 17 hours ago
Joined: 11/29/2012
Posts: 22

Which OS are you using on your Server?

Can you connect from one PI to another PI with TCP?

Are the firewalls enabled on your PI and Server nodes?  If so, you should disable all firewalls.

If after you disable your firewalls, and using just tcpv4_lan, and it still doesn't work.  Then please use wireshark to capture the packets on your server, and then start your server app, start your PI app, then save the captured packets and send the file to me.  You don't need to capture more than 30 seconds of data...  You should see TCP packets from your PI to your Server as well as TCP packets from your server to the PI module to port 7400.

 

Offline
Last seen: 1 week 5 days ago
Joined: 08/11/2019
Posts: 19

I use linux, and I disable the firewall already,

sudo ufw disable

and I try again transfer data, I can not see tcp to my destination in wireshark.

does it mean my QoS xml file wrong?

File Attachments: 
Howard's picture
Offline
Last seen: 2 weeks 17 hours ago
Joined: 11/29/2012
Posts: 22

Well, in wireshark, you should definitely see your application try to send data to the address that you provided in Initial Peers for discovery. If you don't, do you see RTPS packets being sent to 239.255.0.1?

Perhaps your application is not reading the XML qos file.  How are telling your application to load "user_qos_profiles_1.xml"?  It won't automatically load a file with that name...

If you send me the wireshark trace, I can understand more.  Let me know on which machine (address) that you did the wireshark capture.  Also, if you are running the pub or sub side.

 

Offline
Last seen: 1 week 5 days ago
Joined: 08/11/2019
Posts: 19

Hello Howard,

I think that it seems not to find user_qos_profiles.xml,

the reason why I say that is because I change the initial Peers to different IP in user_qos_profiles.xml, like user_qos_profiles_1.xml,

and test localhost data transfer it still works.

If it finds the QoS file, the localhost test won't work, right?

Now, the publisher is 140.118.121.79:7400, and the subscriber is  140.118.122.107:7400

the publisher is linux, and the subscriber is raspberry PI.

I use Wireshark to test it. ntust_kay_test.pcapng 

 

P.S.

for the raspberry PI,  I use rtiddsgen in linux,

I make hello_world_tcp with armv6vfphLinux3.xgcc4.7.2

and change

DEFINES = -fpic -DRTI_UNIX -DRTI_LINUX -march=armv6 -mfpu=vfp -mfloat-abi=hard -mlong-calls

to

DEFINES = -fpic -DRTI_UNIX -DRTI_LINUX -marm -mfpu=vfp -mfloat-abi=hard -mlong-calls

for wireshark I follow:

https://community.rti.com/downloads/rti-wireshark

Howard's picture
Offline
Last seen: 2 weeks 17 hours ago
Joined: 11/29/2012
Posts: 22

Hi Kay,

It doesn't seem that you are creating your applications to use the QOS Profiles defined in your file.

Your code needs to create the participant using one of the profiles defined in the XML.

For example,

    participant = DDS_DomainParticipantFactory_create_participant_with_profile(
        DDS_TheParticipantFactory, domainId, "TCP_Library", "TCP_Subscriber",
        NULL /* listener */, DDS_STATUS_MASK_NONE);

For the subscriber application, and use "TCP_Publisher" for the publisher application.

Now you should see an error if the application couldn't create the participant because it can't find the QOS profile definition because it didn't load the file.

The file must be named "USER_QOS_PROFILES.xml" and located in the current working directory when you start the application.

Offline
Last seen: 1 week 5 days ago
Joined: 08/11/2019
Posts: 19

Hello Howard,

I follow your suggetion then it seems can work in Publisher, ntust_kay_test_2.pcapng 

First question is : I have published about 10 data already, but why it only show one or two data from 7400 port. (due to RST ACK? If so, why is it still transmitting a small amount of data?)

Second : when I use subscriber, it show following error, how can I fix it?

[D0000|Sub(80000009)|T=Example HelloWorld|CREATE Reader] PRESPsService_enableLocalEndpointWithCursor:!get non-zero serialized sample max size
[D0000|Sub(80000009)|T=Example HelloWorld|CREATE Reader] PRESPsService_enableLocalEndpoint:!enable local endpoint
[D0000|Sub(80000009)|T=Example HelloWorld|CREATE Reader] DDS_Subscriber_create_datareader:ERROR: Failed to auto-enable entity
create_datareader error

I apologize for the inconvenience.
 
--Kay

 

Howard's picture
Offline
Last seen: 2 weeks 17 hours ago
Joined: 11/29/2012
Posts: 22

Hi,

Where did the helloworld_xxx.c files come from?  Did you create using rtiddsgen on an IDL file or is it an RTI example?  If IDL generated, please attach the IDL.

I see that you modified the USER_QOS_PROFILES.xml from the one that you sent earlier.

This modification is wrong.

              <name>dds.transport.TCPv4.tcp1.parent.allow_interfaces</name>
              <value>All available interfaces are used</value>

<value> should be the IP address of the local NIC that you want TCP to use.  "All avaliable interfaces are used" is not a valid value

Why did you set these QOS?

          <wire_protocol>
              <rtps_auto_id_kind>RTPS_AUTO_ID_FROM_UUID</rtps_auto_id_kind>
              <participant_id>0</participant_id>
          </wire_protocol>

it's generally NOT needed.

First question is : I have published about 10 data already, but why it only show one or two data from 7400 port. (due to RST ACK? If so, why is it still transmitting a small amount of data?)

The Wireshark file that you sent shows that your publisher application is trying to connect to the subscriber node but it also shows that the DDS discovery between the 2 applications does not go beyond the initial packet.

That packet to port 7400 is NOT user data.  DDS needs to send many packets between the pub and sub apps to establish a connection (under our discovery protocol) before any user data is actually sent.

That process is not being completed and the reason is because of

[D0000|Sub(80000009)|T=Example HelloWorld|CREATE Reader] PRESPsService_enableLocalEndpointWithCursor:!get non-zero serialized sample max size
[D0000|Sub(80000009)|T=Example HelloWorld|CREATE Reader] PRESPsService_enableLocalEndpoint:!enable local endpoint
[D0000|Sub(80000009)|T=Example HelloWorld|CREATE Reader] DDS_Subscriber_create_datareader:ERROR: Failed to auto-enable entity
create_datareader error

which shows that your sub application found an error and then quit.  It's hard to complete a connection to an application that has quit.

However, I don't know why the error message is being printed.

Please give me all of the source files and build files that you are using.  You can zip the directory and attach as a single file.

Offline
Last seen: 1 week 5 days ago
Joined: 08/11/2019
Posts: 19

Hello Howard,

I use rtiddsgen on an IDL file.

And I email your source file to you.

--Kay