Hello,
I am wanting to understand the distinguishing characteristics of data coming across the wire on DDS and Non-DDS.
I an an extreme newbe trying to get my mind around what the traffic itself looks like.
All I can find in documentation is about the API & subsequent IDLs. I think that picture is getting clearer.
I guess what I want to know is how does the middleware see the traffic and say - hey this is DDS stuff lets get busy. As opposed to this is not DDS ignore.
Sorry if my need to know is below the application and use level, but it would help me greatly.
Thanks James
Hello lostokie,
RTI Connext DDS uses RTPS as its standardized wire protocol. The wire protocol standard is documented on the OMG website.
To answer your question, though:
All RTPS messages must start with a standardized header, and the first piece of the header is a constant PROTOCOL_RTPS. The first four octets of the header map to the ASCII characters 'R' 'T' 'P' 'S', as described in section 9.4.4 of the standard.
Thank you,
Rose
Ms. Rose,
I may have some follow-ups on complete interoperability across all DDS of things soon to come.
But I did want to say Thanks while I compose those thoughts.
James
Hello again, I was hoping others would jump in to evolve the discussion without me asking what may be simpleton questions.
What about DDS version 1.2 handling beyond the R T P S magic word and Version number. Is there a decent wire protocol(s) to get my mind around the data on the wire?
I am finding the OMG formal for 1.2, but doesn't RTI middleware handle it and if so is there another reference? What does it do with full IPv6 full addressing?--- just thought i would ask those two (2) questions.
Now to my real question - This is the one I really am hoping for some insight.
What about TCP/IP traffic? If so does it handle version 1.2 and 2.1? I am finding little to get my old mind around there.
Sorry for the simplistic questions that have big answers.
but any direction would help, regards
Hello lostokie,
The spec for the wire protocol is here: RTPS version 2.1 document. (Section 9.4.4, "Mapping of the RTPS Header" talks about what must be in the header).
As for TCP: RTPS can be run over TCP, but there is no standard for how to do it (for example, there is no standard for how to map the ports that are used). RTI provides a TCP transport that allows you to run on top of TCP.
Also, I don't quite understand your second question, can you rephrase it?
Thank you!
Rose
"TCP transport that allows you to run on top of TCP" i guess i am having a hard time getting my mind around that - sorry i am a very visual person and maybe a tad obtuse :-)
So basically the payload looks like speced out in 9.4.4
sorry for reasking.
To rephrase, In reading the various OMG specs its easy to confuse DDS at large and DDS-RTPS. Maybe I am confused still. :-)
but it seems to me that there is a fork off 1.1 in documentation so that you have 1.2 as one flavor and 2.1 as the other flavor.
I get pretty much 2.1, but 1.2 it seems is very loosly defined and I am working on that.concept. Does RTI handle/deal with 1.2?
Thanks & be patient I am getting there :-)
James
Hello James,
This diagram may help a little bit. The DDS 1.2 standard provides the logical concepts of DDS Entities such as DataWriters, DataReaders, etc. The standard also provides the concept of discovery, the concept of QoS, and of data instances.
The DDS RTPS Wire Protocol standard, version 2.1 defines a wire protocol for discovery, writing data, reading data, QoS such as reliability, etc. This protocol can act on top of UDP, shared memory, TCP, or other transports.
One interesting point about the RTPS protocol: It defines its own mechanism for deterministic, tunable reliability. It does not rely on the underlying transport being reliable. So, it can provide reliability over an unreliable transport such as UDP. If you wanted to, you could also enable reliability over RTPS on top of TCP, and there are a few use cases for using a reliable protocol over another reliable protocol.
The logical objects of DDS do not require the RTPS protocol, but it is an efficient protocol that was designed for publish/subscribe data.
Thank you,
Rose