Export (0) Print
Expand All
This topic has not yet been rated - Rate this topic

4.1.2 Cache Synchronization

Having successfully opened a cloud, the PNRP node must first synchronize its cache before initiating Peer Name resolution.

The Resolver sends a SOLICIT message to another node within the cloud (the "Discovered Node"). The two nodes then use PNRP IDs to negotiate which route entries to exchange. The Discovered Node returns a Route Entry for each node that the Resolver is interested in.

A synchronization conversation includes SOLICIT, ADVERTISE, REQUEST, ACK, and FLOOD messages. The following figure shows the sequence of messages sent between the Resolver and the Discovered Node.

473c7bc4-cbc4-4e86-8b88-3c075a716202

Figure 4: Node communication with Discovered Node

Note  The FLOOD messages in this conversation are not synchronous; the Discovered Node may 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 PNRP ID, if any.

  2. The Discovered Node responds with an ADVERTISE message that contains an array of node PNRP IDs 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 PNRP IDs in the ADVERTISE message and selects the ones that it wants to include in its own cache. Say it selects all of them. Thus, it returns a REQUEST message to specify which PNRP IDs 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 PNRP ID that was 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.

 
Did you find this helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft. All rights reserved.