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.
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
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.
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
Great!
Couldyou tell me how to set the property? I have the same issue.