4.1.2 Cache Synchronization

  • Article

Having successfully opened a cloud, the DRT node first synchronizes its cache before initiating key resolution.

The Resolver sends a SOLICIT message to another node within the cloud (the discovered node). The two nodes then use keys to negotiate which route entries to exchange. The discovered node returns a Route Entry for each node of interest to the Resolver.

A synchronization conversation includes SOLICIT, ADVERTISE, REQUEST, ACK, and FLOOD messages. The following illustration shows the sequence of messages sent between the Resolver and the discovered node.

Node Communication with Discovered Node

Figure 1: Node Communication with Discovered Node

Note The FLOOD messages in this conversation are not synchronous; the discovered node can send a second or third FLOOD message before it has received an ACK message for a previous FLOOD message.

The following is an example of what happens during a sample synchronization conversation:

  1. The Resolver sends a SOLICIT message to the discovered node to initiate the conversation. The SOLICIT message contains the following data:

    • Hashed nonce used to identify the conversation.

    • Route Entry for a locally registered key, if any.

  2. The discovered node responds with an ADVERTISE message that contains an array of node keys that it selected from its own cache.

    The discovered node keeps track of the hashed nonce that identifies the conversation.

    The discovered node also adds the Route Entry from the SOLICIT message to its own cache.

  3. When the Resolver receives the ADVERTISE message, it uses the Acked Message ID and the hashed nonce in the message to verify that it sent a corresponding SOLICIT message.

    The Resolver then goes through the array of keys in the ADVERTISE message and selects the ones to include in its own cache. If it selects all of them, for example, it returns a REQUEST message to specify which keys it would like to obtain.

    After the REQUEST message is sent, any state or context information held for the conversation is released.

  4. When the REQUEST message is received, the discovered node immediately returns an ACK message to indicate receipt and to avoid retransmission of the REQUEST message by the Resolver.

  5. The discovered node attempts to verify that the nonce in the REQUEST message is valid. This is done by hashing the nonce and comparing it with the state information saved from the SOLICIT message (see step 2). Because they match, the nonce is valid and the receiving node sends a FLOOD message for each key that is listed in the REQUEST message.

  6. The Resolver inspects each FLOOD message as it is received. If the D bit is clear (as specified in section 2.2.2.4) the Resolver returns an ACK message to indicate that it has received the FLOOD message. The Resolver then adds to its cache the ROUTE_ENTRY in the message.