DDS Publisher Running Remotely connecting DDS Subscriber service running inside kubernetes cluster node

6 posts / 0 new
Last post
Offline
Last seen: 5 years 4 days ago
Joined: 06/01/2017
Posts: 4
DDS Publisher Running Remotely connecting DDS Subscriber service running inside kubernetes cluster node

Experiment : DDS Publisher Running Remotely connecting DDS Subscriber service running inside kubernetes cluster node. 

DDS Publisher:- 
DDS Publisher Running in VM - IP 10.177.214.207 (Outside kubernetes). 
DDS Publisher Application Configured QOS file initial_peers=10.177.214.220 which is master node ip exposed outside kubernetes. 

DDS Subscriber:- 
DDS Subscriber running as service in kubernetes in one of the node/minion clusterIP 10.233.56.218 - (where Master Node IP : 10.177.214.220 exposed to outside world). 
DDS Subsriber Application Configured QOS file initial_peers=10.177.214.207 which is DDS Publisher VM IP address. 
DDS Subscriber yaml file running as service type NodePort & all the ports needed for DDS communication (both discovery, user ports 10410 to 10419 which is for domain=12 communication) are exposed for targetPort, containerPort, NodePort (10410 to 10419) all are same. 
After service running successfully able to verify ports are exposed (netstat -an | grep udp) confirmed all the ports needed for DDS communication in domain 12 are UDP listening. 

Issue : DDS Communication/Discovery Not Established 
After running both DDS Publisher (remotely outside kubernetes) & DDS Subscriber service inside kubernetes observed DDS discovery never established. 
wireshark trace confirms RTPS packet sending continuously 
10.177.214.207 to 10.177.214.220 INFO_TS, DATA(p) 
10.177.214.220 to 10.177.214.207 ICMP Destination port unreachable) 
Referred : https://community.rti.com/forum-topic/why-does-dds-produce-icmp-destination-unreachable-messages which says "DDS may send packets to UDP ports on other hosts that do not have applications attached" 
Above URL i understood/agree actually DDS Subscriber application running inside kubernetes cluster not on the master node 10.177.214.220 which is exposed outside world). 
In kubernetes somekind of NATing rules ensures data forwarding happens. 


Above experiments i did with "simple udp sender running outside kubernetes remotely in VM" and "simple udp receiver running in kuberentes clusterIP". 
"simple udp sender" sending data to "simple udp receiver" via master node ip 10.177.214.220 but the data is able to recieve successfully in "simple udp receiver" running as service inside kubernetes. 

My question is when such experiments work in simple udp sender/receiver application what actually im missing in DDS publisher/subscriber application. 
What configurations im missing DDS application. Any thing specific NATing ? please suggest us. 

Note : I can able to do successful experiments "DDS Publisher" & "DDS Subscriber" both running inside kuberenetes as service communicate via clusterIP service type. It works ! 

Additiona Note : Im very much new on learning kubernetes.

Offline
Last seen: 7 months 6 days ago
Joined: 05/23/2013
Posts: 64

Hi,

This might happen if the subscriber domain participant announces its own IP address than the master node IP address (10.177.214.220) by NATing. UDP transport property called "dds.transport.UDPv4.builtin.public_address" might help with your issue. Can you try to set the cluster IP address for the property in your subscriber app? 

Please take a look at the slides 15 and 16 in the following slide deck.

https://www.slideshare.net/RealTimeInnovations/connext-dds-510-overview

Offline
Last seen: 7 months 6 days ago
Joined: 05/23/2013
Posts: 64

Is your subscriber node's IP address reachable by the publisher? If so, another thing you can try is using the subscriber's node IP address directly instead of the cluster IP because you are using NodePort. 

Offline
Last seen: 5 years 4 days ago
Joined: 06/01/2017
Posts: 4

Thanks Kyoungho.

I tried this QOS configuration "dds.transport.UDPv4.builtin.public_address" seems to be working

Its resolved DDS Discovery communication via NAT working. Will do some more tests update more on the same.

https://community.rti.com/static/documentation/connext-dds/5.3.0/doc/api/connext_dds/api_dotnet/group__UDPv4Transport__Property__t__public__address.html

Offline
Last seen: 7 months 6 days ago
Joined: 05/23/2013
Posts: 64

Great!

Offline
Last seen: 4 years 1 month ago
Joined: 01/31/2020
Posts: 1

Couldyou tell me how to set the property? I have the same issue.