Using DDS for one-way publishing

5 posts / 0 new
Log in or register to post comments
Last post
Mon, 10/07/2013 - 18:26
#1
dwinchester
Offline
Last seen: 10 years 5 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.

Keywords:
Top
Tue, 10/08/2013 - 00:05
Gerardo Pardo
Gerardo Pardo's picture
Offline
Last seen: 1 week 1 day ago
Joined: 06/02/2010
Posts: 602

Hello,

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...

Gerardo

Top
Fri, 10/11/2013 - 01:46
jmorales
jmorales's picture
Offline
Last seen: 8 months 2 weeks ago
Joined: 08/28/2013
Posts: 60

Hi,

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. 

Regards, 
Javier.

Top
Wed, 08/19/2015 - 07:14
stec00
Offline
Last seen: 9 years 2 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.. :-)).

Top
Mon, 08/24/2015 - 14:44
shaun.foley
Offline
Last seen: 9 years 2 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.
Top