Key hash PreviousNext
Data Distribution Service (DDS) Forum > DDS Technical Forum >
Message/Author
Next message John Hawkins  posted on Wednesday, January 09, 2008 - 06:16 pm
Hi Folks,

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 ?


many thanks, as always !
John.
Next message Niels Kortstee  posted on Thursday, January 10, 2008 - 09:55 am
Hi John,

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:

instanceGUID = { Data.keyHashPrefix, Data.keyHashSuffix }

If no keyHashPrefix element is sent with the data, the prefix is obtained using the state of the Receiver:

instanceGUID = { Receiver.sourceGuidPrefix, Data.keyHashSuffix }

Best regards,
Niels Kortstee
Next message John Hawkins  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?

many thanks for your help - again !
Next message Niels Kortstee  posted on Thursday, January 10, 2008 - 12:17 pm
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.
Next message Niels Kortstee  posted on Thursday, January 10, 2008 - 01:40 pm
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.
Next message John Hawkins  posted on Thursday, January 10, 2008 - 05:09 pm
Hi Niels,

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?)


many thanks !
John.
Next message Niels Kortstee  posted on Friday, January 11, 2008 - 08:47 am
Hi John,

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.

Best regards, Niels
Next message John Hawkins  posted on Friday, January 11, 2008 - 05:54 pm
Ah - That'll be part of my confusion then !
An InstanceHandle_t is an instance key right?

I can't actually see what a InstanceHandle_t is in the DDS spec - could you point it out to me?

Is an instanceHandle_t supposed to equate to, at least, part of this hashKey issue or is this something else I'm confusing?

Do you happen to know if the major vendors hashkeys are interoperable?

And, while we're on the subject - are the major DDS vendors interoperable period :-)


many thanks,
John.
Next message Niels Kortstee  posted on Monday, January 14, 2008 - 08:57 am
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.

Best regards, Niels
Back to top
Add Your Message Here
Post:
Username: Posting Information:
This is a private posting area. Only registered users and moderators may post messages here.
Password:
Options: Post as "Anonymous"
Enable HTML code in message
Automatically activate URLs in message
Action: