posted on Wednesday, January 09, 2008 - 06:16 pm
I'm now intrigued and confused by exactly how the key hashing works?
I understand that the provider created readers and writers are the only entities that "understand" the serialised (wire-format) of the message. I also think I know that they supply the key-hash.
However, I'm then confused when I read the RTPS spec about the two halves of the keyhash (prefix and suffix) and how the prefix may be missing and therefore the read or writer prefix should be assumed - can someone explain this clearer for me please ?
An RTPS Message contains a set of submessages. The interpretation and meaning of a Submessage within a Message may depend on the previous Submessages contained within that same Message. Therefore, the receiver of a Message must maintain state from previously deserialized Submessages in the same Message.
An RTPS Writer sends the Data Submessage to the RTPS Reader to communicate changes to the data-objects within the writer. If the KeyHashFlag is set, the keyHashPrefix element contains a valid prefix. In that case, the instance is uniquely identified using:
posted on Thursday, January 10, 2008 - 10:28 am
AH, Thankyou I forgot about submessages - it makes a little more sense but still unclear as to how to figure out what makes the instance unique.
So - does a message ALWAYS have to have at least one sub message (assume the top message) with the data.keyHashPrefix set? In which case I can then understand how later submessages are pertaining to the same instance by association with the same writer in the same set of sub messages.
I get lost if there is never any Data.keyHashPrefix - does this ever happen or does the above rule apply?
Only the Header and the Submessages InfoSource, InfoReply, InfoDestination and InfoTimestamp change the state of the Receiver. Each Message at least contains a Header in order to be valid.
The Header of a new Message affects the state of the Receiver: Receiver.sourceGuidPrefix = Header.guidPrefix Receiver.sourceVersion = Header.version Receiver.sourceVendorId = Header.vendorId Receiver.haveTimestamp = false
So if there is no keyHashPrefix in any of the SubMessages in the Message, the Header.guidPrefix is selected as the keyHashPrefix.
Furthermore, what makes the instance unique is the value of the key fields in the data itself. The introduction of a hash (keyHashSuffix) for this value at the the writer side makes it easier to look up the instance at the reader side and allows finding it without interpreting the data.
posted on Thursday, January 10, 2008 - 05:09 pm
Thanks for you replies... They both helped to confuse me slightly :-)
re the key fields actually being the unique identifier - I had understood this but then you say "makes it easier" do you mean that a hash doesn't necessarily have to be present at all? I think your statement combined with the RTPS statement confuse memore -
keyHashPrefix & Suffix: "Provide a hint for the key that uniquely identifies the data - object that is being changed within the set of objects that have been registered by the RTPS Writer."
This all makes me think that there's something I've missed here. I get the impression that the keyhash is not showing uniqueness across all instances on the topic but just uniqueness on the instances that the writer has registered interest in. If this is true (And I'm really not sure if it is) then my next paragraph puts forward the confusing scenario for me....
What I think confuses me is:
If two writers both publish changes to the same instance they must both have set what as the prefix and where so that the reader can identify the instance? Because, I'm assuming that just setting the hash suffix isn't enough to identify instance uniqueness?
There's another way I can ask this question - will both messages, when they arrive at the reader, have the same hashkey suffix? (I don't think they'll have the same prefix - right?)
The instances are actually distinguished using their DDS key (see DDS spec). RTPS does not state how this is translated to a keyHashPrefix and keyHashSuffix. This must be specified in the future in order to ensure interoperability between different DDS implementations.
The DDS specification states: "In case a set of instances is gathered under the same topic, different instances must be distinguishable. This is achieved by means of the values of some data fields that form the key to that data set. The key description (i.e., the list of data fields whose value forms the key) has to be indicated to the middleware. The rule is simple: different data values with the same key value represent successive values for the same instance, while different data values with different key values represent different instances. If no key is provided, the data set associated with the Topic is restricted to a single instance."
An InstanceHandle_t is a handle to such an instance.
Multiple vendors are currently working on RTPS implementations to become interoperable.