I have a configuration where 3 applications run on 3 different Virtual Machine's and they must communicate via DDS i.e. RTPS protocol.
The configuration is as follows :
ROS2 based ADAS functions
Simulation Tool
Python/Tensorflow based machine learning functions
All 3 need to be on different VMs.
It is not possible at our end to allow multicasting for the MS AZURE VM and our network.
Here are some questions :
Is it still possible to communicate via DDS ?
If yes, through UNICAST i.e. peer to peer connection ?
Is using DDS communication beneficial in this case if i already have the option of basic UDP socket programming ?
Could you think of any restrictions/ further problems in using DDS for such a configuration ?
Is it still possible to communicate via DDS ?
Yes, it is. Out of the box, DDS Participants only use multicast for discovering other DDS Participants, at startup. This discovery mechanism can be configured in several ways. For a an explanation on how to achieve that, see this RTI Community Knowledge Base article: Configure RTI Connext DDS to not use Multicast.
If yes, through UNICAST i.e. peer to peer connection ?
Yes, with the no-multicast setup, all communications are done over UDP unicast, peer to peer, connectionless.
Is using DDS communication beneficial in this case if i already have the option of basic UDP socket programming ?
Not being able to use multicast does not remove any of the DDS advantages when comparing it to UDP. When using DDS, the transport/discovery configuration is typically invisible to the application and all Publish/Subscribe concepts remain unchanged.
If you are asking about the advantages of using DDS versus UDP, I think that warrants a new question on itself. The answer will be quite extensive :-)
Could you think of any restrictions/ further problems in using DDS for such a configuration ?
With this configuration, your configuration settings will be dependent on the network that you are running on. This means that migration to a different network might need reconfiguration, for example providing different host names or IP addresses. This is inconvenient, but not hard.
Since your environment is restricting the use of multicast, I would not be surprised if there are more restrictions that you have not mentioned or discovered. For example, do you know anything about firewalls or network bandwidth restrictions? Again, DDS can be configured to deal with such things, but you need to be aware of them first.
Related
I'm newbie to DDS/Fast-RTPS.
Based on my understanding, the discovery is LAN-based. It failed to discover a node which is not in the same LAN. is it correct?
I'm wondering if we can use fast-rtps to communication across networks?
ps. let's ignore NAT/Firewall issues. Assuming we have a IP/TCP full reachable network environment.
DDS uses Multicast UDP. If your switches and other network infrastructure is set to swallow Multicast packets, or if the TTL is set too low, then the default discovery implementation of DDS will not complete/be seen.
You can up the TTL on your infrastructure, or you can tell the DDS libraries to target specific addresses (see the documentation for your provider's libraries).
For example, setting the remote{} configuration, does that also set the transport that is used internally for cluster communication, for example, the heartbeat messages.
I am not asking for any use case purpose I am asking so I better understand what's happening behind the scenes.
At the moment (Akka.NET 1.3) uses its own protocol for remote communication on top of TCP connection - only a single connection is used by every node-to-node connection. This video discusses it in greater detail.
In future, it will probably change to match JVM version of akka - two major ideas are:
"lanes": multiple connections for each pair of nodes, to avoid head-of-line blocking, that is inherent problem of TCP.
Add support for other protocols, such as Aeron, which is also supported by akka on JVM.
What is the most simple and straightforward approach for serverless P2P UDP chat in Boost Asio? The chat will work across the internet. There are ready UDP examples but they all maintain client-server approach!
I'm assuming that by serverless you mean a P2P network without a central control server.
IMO your question has little to do with boost-asio. asio is a cross-platform network library. You seem to be asking more of a network engineering type question and asio is just one of the tools you can use for implementation.
The examples are client-server in that the example applications possibly fall under the client-server architecture. However the socket code (or asio usage) used to send and receive messages will look the same irrespective of client-server or P2P applications i.e. you send a message to an address and you receive messages on a specified port. The differences will come in at the protocol layer, but this has nothing to do with asio per se.
The following may or may not be of interest to you: there is no simple way IMO: users located behind firewalls and NAT means that you need to use techniques such as STUN, TURN and ICE to resolve addresses or in the worst case relay data. All these designs require a server.
Can anyone tell be where to use the UDP protocol except live streaming of music/video? What are default usecases for UDP?
UDP is also good for broadcast, such as service discovery - finding that newly plugged in printer.
Also of note is that broadcast is anonymous, you don't need to specify target hosts, as such it can form the foundation of a convenient plug-and-play or high-availability network.
UDP is stateless and is good for applications that have large numbers of clients connecting to a server such as time servers or DNS. The fact that no connection has to established and maintained reduces the memory required by the server. There is no handshaking involved and so this reduces the traffic on the network. On the downside, if the information transferred requires multiple packets there is no transmission control to ensure that all packets arrive and in the correct order - but in games packets lost are probably better than late or disordered.
Anything else where you need performance but can survive if a packet gets lost along the way. Multiplayer games come to mind, for example.
A very common use case is DNS, since the overhead of creating a TCP connection would by far outweight the actual payload.
Additional use cases are NTP (network time service) and most video games.
I use UDP to add chat capabilities to our applications. No need to create a server. It is also useful to dispatch events to all users of our applications.
I'm trying to implement peer-to-peer messaging and file sharing utility within LAN, So does WCF supports p2p? Does any one tried file sharing trough WCF?
Yes, it does. Please see How To Design State Sharing In A Peer Network:
When researching the various ways in
which an election scenario might be
implemented, I discovered that there
is an attribute in WCF that allows you
to indicate the maximum number of hops
that a particular message will travel.
After seeing this, it became obvious
that there was a means for sharing
state in a peer network that not only
required no central server, but was
resilient to node drop-off and did not
require election. I call it Nearest
Peer Synchronization.
Yes. Check out the NetPeerTCPBinding.