Overview
Modules
Development
This page tries to explain what is implemented and what is not. This server two purposes; One is for the users of jRTPS, they should be able to see what to expect. Other is for developers, they should be able to see what needs to be implemented. Idea is not to provide very detailed view of the implementation status.
Following submessages are implemented and should work as expected: ACKNACK, DATA, HEARTBEAT, INFODESTINATION, INFOSOURCE, INFOTIMESTAMP, GAP. In normal case, RTPS entities use these submessages to exchange data with each other. Each jRTPS participant handles only messages destined to entities it has created. This means that if INFODESTINATION refers to some other participant, all the submessages other than INFO* are discarded.
Following submessages are not implemented: INFOREPLY, INFOREPLYIP4.
Following submessages are not handled in any way: DATAFRAG, HEARTBEATFRAG, NACKFRAG These messages are used with large data. I.e. Data messages that are bigger than 64k, which is the maximum size of Data to be sent over the network. Data fragmentation is an optional, as explained in chapter 8.4.14 of the RTPS v2.1 specification.
From the writer point of view, all kinds of Liveliness QoS are supported; AUTOMATIC, MANUAL_BY_PARTICIPANT, MANUAL_BY_TOPIC. From the reader point of view, if writers liveliness is lost, or restored, application is notified through WriterLivelinessListener of this fact.
After reader detects writers liveliness is lost, it may be restored later on if writer continues to send any messages. Note, that liveliness protocol is only needed if writer does not send messages regularly.
If reader requests inline QoS to be sent with every Data submessages, jRTPS writer will do just that. This is determined during discovery; if subscription data received contains PID_EXPECTS_INLINE_QOS(0x0043), reader is marked as needing inline QoS to be sent.
In Addition, following inlineable parameters are recognised and handled by jRTPS: PID_COHERENT_SET(0x0056), PID_DIRECTED_WRITE(0x0057), PID_KEYHASH(0x0070), PID_STATUS_INFO(0x0071), PID_CONTENT_FILTER_INFO(0x0055)
For the Coherent sets, udds supports writing of collections coherently. For access scope GROUP, RTPS specification says that "the extensions required for access scope GROUP are not yet defined", and thus jRTPS does not support access scope GROUP. jRTPS writers does not support directed writes, but readers handle them correctly(not tested).
For the Content filtering, uDDS readers send ContentFilterProperty to writers, so that writers may do writer side filtering. ContentFilterProperty will be sent if an application registers a ContentFilter to DataReader. Writer side content filtering is supported by registering a ContentFilter to writer. Note, that DDSSQL is not parsed. Rather, one can register a ContentFilter that implements corresponding DDSSQL.
Following inlineable parameters are not handled by jRTPS: PID_PROPERTY_LIST(0x0059), PID_ORIGINAL_WRITER_INFO(0x0061)
Even while interoperability is not about being compliant to anything, if two independent implementations can communicate with each other, there is at least some level of compliance to specification. With both implementations.
jRTPS is known to be interoperable with OpenDDS 3.5. Within jRTPS sources, there are publisher and subscriber (examples.opendds.messenger) that talk to OpenDDS example DevGuideExamples/DCPS/Messenger counterparts. RTI Connext 5.1.0 is also working. examples.rti.hello provides publisher and subscriber which talks to example/JAVA/Hello_simple.