I have a Publisher which is running on a computer with an IP address 10.10.1.136. The Subscriber runs on another computer with an IP address 10.10.1.130.
I would like to block out the Publisher's IP address, however the code that I written below can't seem to block it.
Is there any way to block out this specific IP address?
*I'm using the USER_QOS_PROFILES.xml from the DDS examples.
code:
</participant_qos> <property> <value> <element> <name>dds.transport.UDPv4.builtin.parent.deny_interfaces_list</name> <value>10.10.1.136 </value> </element> </value> </property> </participant_qos>Thanks.
What you are doing there is just deny the interface, this means that the subscriber will never listen to an interface which ip address is "10.10.1.136", since that interface does not exist in the subscriber, this will not work. (See https://community.rti.com/kb/how-do-i-restrict-rti-connext-use-only-subset-interfaces for more info about this).
Now, even before trying to answer your question, I am wondering about your design: Why would you like to block the communication between these 2 applications? I mean, if this is by design, you have the option of using different partitions, and dinamically join or leave the partitions. Domains are also interesting in that sense and I can think of other options, like CFTs. Denying a specific ip does not seem like a good solution when talking about DDS designs.
Answering specifically your question, I would think you could play with the initial peers, not allowing to send to peers that are not in the initial list.
But again, I would try to go in another direction, read about the domains and partitions within a domain, I think your answer will be there.
Hope this helps!
Regards,
Javi
Hi Javi,
Thanks for the reply. I'm currently exploring on a project which consist of many publishers and 1 subscriber. I'm trying to test out if I'm able to block out certain IP address (each publisher on a different IP address) on the subsciber's side.
What I'm trying to simulate from the above project is that the subsciber able to deny IP addresses to prevent receiving unwanted data.
Hope the explaination clarify in what I'm hoping to achieve :)
If you know all the ips implied in the communication, you could do something like:
- Allow_unknow_peers set to false in your subscriber
- Only add the ips from the publishers that you allow to communicate.
This option is less than optimal, therefore I still suggest you explore the option of CFTs: Use CFTs and set a field in your idl structure identifying the ID of the publisher.
Would that work for you?
Hi Javier,
I'm pretty interested in this Allow_unknow_peers. Could you teach me in how to set it up?
I'm currently just learning on DDS so I may not know how to set it up properly. Meanwhile, I will read up on the CFTs and understand more about it.
Thanks in advance!
I will use the documentation words that surely will explain it better than me:
8.5.2.6 Controlling Acceptance of Unknown Peers
The accpet_unknown_peers field controls whether or not a DomainParticipant is allowed to communicate with other DomainParticipants found via unicast transport that are not in its peers list (which is the combination of the initial_peers list and any peers added with the add_peer() operation described in 8.5.2.3 Adding and Removing Peers List Entries).
Suppose Participant A is included in Participant B’s initial peers list, but Participant B is not in Participant A’s list. When Participant B contacts Participant A by sending it a unicast discovery packet, then Participant A has a choice:
Note that Participants do not exchange peer lists. So if Participant A knows about Participant B, and Participant B knows about Participant C, Participant A will not discover Participant C.
Note: If accept_unknown_peers is false and shared memory is disabled, applications on the same node will not communicate if only ‘localhost’ is specified in the peer list. If shared memory is disabled or ‘shmem://’ is not specified in the peer list, if you want to communicate with other applications on the same node through the loopback interface, you must put the actual node address or hostname in NDDS_DISCOVERY_PEERS.
=======================
So, basically, you set the initial peers (here is an example, try the XML form, it is the easiest one) on your subscriber side, and you specify all the ips of the publisher nodes.
If you just do this, the subscriber will announce itself only with those locators in the initial peers list, however, the blocked publisher will announce itself to the default initial peers (multicast, shared memory and localhost), and the discovery announcement to multicast will reach the subscriber. Now, if the "accept_unknow_peers" is set to true, then you will add that peer and start receiving from it, if you, instead, set the "accept_unknow_peers" to false, the subscriber will discard that peer and not receive from it.
Allow me to warn you about this: This is less than an ideal solution, since you lose escalability, and you tight you design to IP concepts. Thinks like a new node or ip changes would cripple your implementation, so, I would study other more escalable designs
Hi Javier,
I would like to ask u another question. Is it possible to use my own self-signed certificate with the C# hello_security?
I would like to make use of the certificate to allow/deny other users from publishing data onto my subscriber. The scenario is the same as previous but with the addition of using certificate to give permission to certain users.
Is this idea feasible and how should I add my self-signed certificate onto the USER_QOS_PROFILE for usage?
Thanks. Do let me know if you need more information.
Cheers