I understand version 4.5f does not provide "deep" or "strong" type check during topic discovery, but local subscriber can access the type code of remote publisher from the builtin listener and compare with its own local type code on the same topic. After receiving the remote type code, can the subscriber just call the DDS_TypeCode::equal() function to check the remote type code agains the local one and achieve "deep" type check? In other words, does the equal() function's comparison recursively reaches down to data members of nested structures?
Hello,
Yes you are correct RTI version 4.5f (and earlier versions) only check the names of the data-types associate with DataWriters and DataReaders. It does not check the "structure" or definition of the datatypes so it is possible that two applications define the types differntly resulting in errors. Note however that the RTI Analyzer tool can be used to detect this kind of configuration problem.
Yes the approach you describe can be used to detect inconsistencies in the type definition. The DDS_TypeCode::equal() indeed does a "deep" check of the type definition. The check performed by the "equal" function recursively navigates into the nested structures so if it returns TRUE they will be identical all the way through.
Note also that the new "Big Pine" release (RTI Connext 5.0.0) which will be available for downloads in a few days (Tuesday September 4) will address this type-checking issue. This is done as part of the support for the recently adopted OMG DDS Extensibe Types Specification (DDS-XTYPES) which defines the set of rules under which two types are compatible in the sense that a subscriber (DataReader) of type T2 can receive dta published by a DataWriter of type T1. This compatibility is not restricted to be exact type definition so that with this new release it is now posible to extend and modify the type definitions without breaking interoperability with systems that use prior definitions of the data types.
Gerardo