3.1.4.4 Resolving a Key
In a resolution operation, three inputs are provided by the application or higher-layer protocol:
A key to resolve
A ResolveCriteria corresponding to the OpCode values specified in section 2.2.2.8
A PickBestMatchFromLocalIds flag indicating whether to consider locally registered keys
If the cloud has not been opened, the node MUST fail the request.
If there are no addresses in the Local Endpoint List abstract data model (ADM) element, the node MUST fail the request.
All nodes taking part in DRT will carry out the resolve process from time to time. Resolve-only nodes use the resolve process to handle requests from higher level applications to resolve a key. The process is also used in cache maintenance operations. Publishers use the resolve operation to advertise published keys to the rest of the cloud. Publishers also use the resolve operation to attempt to detect splits in the cloud.
The following parameters MUST be supplied to the resolving logic:
Target Key, which is mapped to the key provided by the application or higher-layer protocol as specified in section 2.2.2.8.
ResolveCriteria, which maps to the ResolveCriteria provided by the application or higher-layer protocol as specified in section 2.2.2.8.
PickBestMatchFromLocalIds, which maps to the PickBestMatchFromLocalIds provided by the application or higher-layer protocol as specified in section 3.1.4.4.
ResolveReasonCode, which MUST be set to REASON_APP_REQUEST when the resolve operation is initiated by the application or higher-layer protocol.
and optionally
InitialBestMatchRouteEntry, which is a ROUTE_ENTRY structure used by the protocol during key registration. See section 3.2.4.1 for details.
InitialNextHopRouteEntry, which is a ROUTE_ENTRY structure used by the protocol during maintenance. See section 3.2.6.2 for details.
A Resolver MUST then perform the following steps:
Attempt to create a new entry in the Outstanding Resolves Table element, and fail the request if one cannot be created. If one is created, initialize the fields as follows.
Initialize SuspiciousCount element and TotalUsefulHops element to 0.
The resolve entry's ResolvePath MUST be initialized to contain any one of the endpoints in the Local Endpoint List element.
Save the supplied Target Key and ResolveReasonCode in the corresponding fields of the resolve entry.
If an InitialNextHopRouteEntry is supplied, push it onto the NextHopStack element. Otherwise select the route entry from the cache for the key numerically closest to the Target Key and push it onto the resolve entry's NextHopStack element. In both cases the UseCount element for the entry on the stack MUST be set to zero.
If an InitialBestMatchRouteEntry is supplied, push it onto the resolve entry's BestMatchStack element. If an InitialBestMatchRouteEntry is not supplied, leave BestMatchStack element empty.
If the resolve entry's CurrentBestMatch element is not empty and the key of the most recently pushed entry in the BestMatchStack element is sufficiently close (per the ResolveCriteria) match to the Target Key, then:
Create an INQUIRE message with the following fields:
Validate Key field set to the key of the CurrentBestMatch element.
Request CPA, Certificate Chain, Classifier, and Extended Payload flags set.
FieldId3 set to 0x0093 (NONCE).
Set LastSentMessageID to the MessageID of the INQUIRE message. If the protocol is executing in membership or confidential security mode, call upon the SecurityModule element to provide the Credential, Signature, and KeyIdentifier fields of the message. Then choose an address from the CurrentBestMatch element route entry's address list by using the algorithm as specified in [RFC3484] section 6, and send the INQUIRE message to that address. Finally, put the INQUIRE message in the Pending List element, set its Retry Count to 2, and start its Message Retransmission Timer.
Otherwise (for example, if the resolve entry's CurrentBestMatch element is empty or not sufficiently close to the Target Key), continue processing as follows:
Attempt to pop a route entry off of the NextHopStack element and store this route entry in the resolve entry's CurrentNextHop element. If the CurrentNextHop element is empty or SuspiciousCount element is greater than 6 or TotalUsefulHops element is greater than 22, the Resolver MUST do the following:
If the resolve entry's CurrentBestMatch element is not empty, determine whether it meets the minimal match conditions as specified in the ResolveCriteria. If it does not, or the CurrentBestMatch element is empty, return no results to the caller because no adequate match is found. The Resolve operation is now complete. Otherwise, send an INQUIRE message as in step 7 above.
If the NextHopStack element is not empty, SuspiciousCount element is less than or equal to 6, and TotalUsefulHops element is less than or equal to 22, continue processing as follows:
Prepare a LOOKUP message with the Validate Key field set to the key from the route entry in the CurrentNextHop element, and the FlaggedPath field filled with the entries from the ResolvePath. If the number of entries in the cache is less than 8, the Resolver SHOULD set the A flag in the LOOKUP message. If the protocol is executing in membership or confidential security mode, call upon the SecurityModule element to provide the Credential, Signature, and KeyIdentifier fields of the message.
Choose an address from the list of addresses in the route entry in the CurrentNextHop element state, using the algorithm as specified in [RFC3484] section 6, send the LOOKUP message to it, and increment the UseCount in the CurrentNextHop element state. Set LastSentMessageID to the MessageID of the LOOKUP message. Put the LOOKUP message in the Pending List element, set its Retry Count to 2, and start its Message Retransmission Timer.