Using DDS for one-way publishing

5 posts / 0 new
Last post
Last seen: 9 years 12 months ago
Joined: 04/26/2013
Posts: 3
Using DDS for one-way publishing

Is it possible to configure DDS to publish topics through a one-way transport? It would not know # participants, readers on same domain nor support certain QoS properties (Realiability, etc), heartbeat, etc.


No inbound traffic is allowed so this participant would simply broadcast topics, nothing else.

Gerardo Pardo's picture
Last seen: 1 week 2 days ago
Joined: 06/02/2010
Posts: 601


I think this may be possible but it would require the use of the "static discovery" plugin to configure the DomainParticipant to know where to send the messages. Also as you mentioned this would only support best-efforts communications as it would not be possible to get ACKs/NACKs back.

Note that the "static discovery" plugin is an optional component of the product so you many not have it in your bundle. In addition I am not sure if this is a configuration that has been run before so I do not know if the "static discovery" plugin supports this configuration or some changes would be required.  If it is possible for you to contact RTI support or services I would recommend that as they could do some deeper digging...


jmorales's picture
Last seen: 3 months 4 days ago
Joined: 08/28/2013
Posts: 60


I have performed some tests using the Low Bandwidth Plugin and Static Discovery. I created an scenario simulating a one-way network (using firewall rules) and I've been successful sending information in the allowed direction without the need of receive anything in the forbidden one. 

Therefore I think Low Bandwidth Plugin and Static Discovery could work as a solution for a unidirectional network environment. 


Last seen: 8 years 9 months ago
Joined: 08/19/2015
Posts: 1

Apologies for dragging up an old thread but I came across this and am also very interested in doing the same. Am I right in assuming the term "static discovery plugin" above refers to the combination of the "Limited Bandwidth Participant Discovery Plugin" and "Limited Bandwidth EndPoint Discovery Plugin"? The former has the following sentence in its documentation:

The LBPD plug-in reduces, but does not eliminate, the network traffic required to exchange participant information. It does this by allowing you to define some of the remote participant data, such as the product version and the RTPS protocol version, in an XML file.

This and the term "quasi-static discovery" used elsewhere is just slightly worrying me as the data diode will only allow traffic flow from A=>B not B=>A so there will potentially be problems if any data needs to be "exchanged" rather than just sent. Javier - would be interested in any further information you may be able to provide on how the environment was set up to get this working (assuming you still work at RTI and can remember.. :-)).

Last seen: 8 years 9 months ago
Joined: 10/17/2011
Posts: 2
This is possible, but it requires a bit more work than using the LB plugins directly. This is because the participants still expect to receive an announcement from remote participants that contains GUID and locators (among other) information. Fortunately, a participant doesn't care *how* it receives this announcement, so if we craft an RTPS packet with the right fields we can send it from any machine -- it doesn't need to be from the actual remote participant. When the spoofed announcement is received, it triggers the participant to load the endpoint data from the LBED configuration files as usual.