I have some basic conceptual questions regarding DDS.
DDS uses a RTPS protocol for data transfer. This complies to the wire standard and uses UDP/IP for discovery and data transfer. Thus it assumes that the packets to be transferred are complete and non-corrupted.
- Since, UDP itself is not a reliable communication as it focusses on best effort, how could it be said that DDS sends the data reliably using UDP/IP if UDP itself in first place is not a reliable means of data transfer ?
- Could it be said that DDS is basically UDP communication but it gives an option of configurability through QoS settings ?
- If there is an option between using DDS and UDP, why should one use DDS ? (the influencing factor being latency)
- What is the exact difference between UDP and Shared Memory ?
- Difference between sending data through multicast and unicast ?
- Where is the data stored temporarily between publishing and subscribing ? RAM ?
Thanks in advance for the help.
Hello,
RTPS can run over udp/ip but it can run on top of other transport protocols (notably tcp / tls).
It's true that there's an assumption of packets being complete and non-corrupted (although I remember it's possible to activate a checksum mechanism to guarantee that).
1. Reliability mechanisms can be impletmented on top of non-reliable communication (For example, a naive option would be to expect a reply to every message you send and if you don't receive one, resend the message). RTI allows users to heavily configure how reliability is set up, giving them the power to make decisions most fitting their use-case (and also allowing some variability between different subscribers and publishers).
2. As mentioned, RTPS itself (which is only a part of DDS) is not tied directly to udp and can be run on top of tcp. RTPS itself comes with a large set of qos related to it (configurability that you've mentioned) but also makes an effort to allow interoperability between different architectures, programming languages, and DDS vendors. In fact, rtps itself offers a lot more than just the configurability. But since you asked about DDS (and not just RTPS), I would say that DDS offers even more by describing the PIM (platform independent model) which, again, helps interoperability, and in its design supports various patterns of communications and various use-cases where RTI thrives (pubsub, querying, low latency / real time / over low bandwidth / etc).
3. Using udp is fine, but in itself it gives you simply best-effort peer to peer communication (that is: system A knows system B and so system A can send system B data in a best-effort manner. data may be lost, or it could be that B won't even be listening to the data and A will be unaware). If you wish to implement some sort of pub/sub or perhaps reliability (and maybe durability?) you may succeed using just udp (perhaps you'd utilize multicast?) but why work hard on getting that to work (and most likely failing to get a good result as you make some common mistakes) when you can use DDS to get these things out of the box (and some other things, too).
4. Using udp/ip means that packets abiding to the user datagram protocol will be sent over the internet using the internet protocol. Using shared memory means that (depending on the operating system) you can utilize memory (RAM) to communicate between participants.
5. In terms of "result" unicast means A sends to B (most likely hopping through some switches, routers, and other network endpoints) while multicast means A sends to group G. In terms of implementation both are a bit complicated to explain over a few lines of answer but to point out some key differences:
a. Multicast can be very efficient in terms of network utilization when compared to unicast
b. Multicast is much less supported (and rightfully so) outside a LAN
c. Unicast requires source to know the destination(s?) while multicast only requires the source to know the igmp server (given that the network supports multicast)
6. Between publishing and subscribing? How do you mean? QoS settings allow users to configure how data is stored by writers and readers.
If we look at how the normal process goes:
User thread calls some write api on a writer (after creating some data object).
Either this data is passed in a synchronous manner to the publisher (which is responsilbe for sending data over the various transports it supports) who synchronously publishes data, or the data is passed into a queue for an async publisher to publish (this is depending on the qos).
The qos can also determine whether or not writers keep data they've sent, how much of it do they keep, and answer why when and how data is replaced or removed.
On the receiving end data is received by a subscriber which passes the data to the relevant reader(s), also triggering some events if the reader/subscriber/participant were set up with listeners.
Once data is in the readers cache (ram), qos as well as api calls made by the user will determine how long it stays there (for example, take should remove data from cache while read will not, and things like history and resource limits will determine how much data is kept).
Hopefully my answers are helpful,
Roy.
I should note that while DDS offers a lot more than UDP/IP does:
a. There are other options that may be better suited for your specific use-case (RTI themselves have an article explaining when and why should you choose RTI Connext DDS)
b. In some simple use-cases UDP/IP is good enough and saves you the learning curve that comes with DDS