3.1.1 Abstract Data Model

This section describes a conceptual model of a possible data organization that an implementation maintains to participate in this protocol. The described organization is provided to facilitate the explanation of how the protocol behaves. This document does not mandate that implementations adhere to this model as long as their external behavior is consistent with what is described in this document.

The receiving node MUST store the following information:

  • Endpoint Information: Network information that the Peer Channel Protocol uses when it determines the need to establish neighbor connections. This information SHOULD be stored as a PeerNodeAddress. The node MUST store its listening endpoint addresses in the discovery service under the mesh name corresponding to the mesh name used in the application. The listening endpoint addresses MUST be published as a PeerNodeAddress. For more information about a possible discovery service, see [MC-PRCR] section 1.3.

  • Mesh name: The node MUST store locally the string value of the mesh name for use in interacting with the resolver service.

  • NodeId: This is an 8-byte unsigned number that is randomly generated on creation of the node itself.

  • MessageId cache: Each node MUST maintain a cache of previously seen MessageIds. This is used to detect duplicate messages. A node SHOULD cache MessageIds for at least 5 minutes.

  • Referral cache: Each node MUST maintain a cache of previously received Referrals from messages it receives, including Welcome, Refuse, and Disconnect messages. The Referral cache is used in maintenance to supply additional neighbors when the neighbor count is less than the IdealNeighborCount.

  • LinkUtilityIndex: Each node MUST maintain a value indicating the usefulness of the connection.

  • ConnectionState: Each node MUST maintain the current state of each connection. The ConnectionState MUST be one of the following values: {Created, Authenticated, or Connected}.

  • Channel type information: The following information MUST be stored for each channel type supported by the receiving node:

    •  ChannelType URI: The URI to which the channel type corresponds. This value MUST match the PeerVia header in the incoming message.

    •  MessageValidator callback: The callback that is invoked to verify the incoming message signature if the particular channel type supports message authentication.

    •  MessageDispatcher callback: The callback that accepts incoming messages for processing. Local processing of this message is handed off to this callback by the node.

  • (Optional) X.509 Certificate for Transport Security: An X.509 certificate for the key that is used to establish TLS over TCP connections. Required only if certificates are used to secure mesh connections.

  • (Optional) X.509 Certificate for Message Signing: An X.509 certificate for the key that is used to sign messages. Needed only if message authentication is enabled on mesh messages.

  • (Optional) password: A password that is used in security handshakes. See the RequestSecurityToken message. Needed only if passwords are used to secure the mesh.

  • Discovery service information: Information used to connect to the discovery service. This MUST include the service location, port number, transport, and any applicable security settings.

  • IdealNeighborCount: The optimal number of neighbor connections for a node to maintain. This value SHOULD be set to 3.

  • MaxNeighborCount: The maximum number of neighbor connections for each node. This value SHOULD be set to 7.

  • MinNeighborCount: The minimum number of neighbor connections for each node. This value SHOULD be set to 2.

  • LinkUtility timer: Exists for each neighbor connection where the ConnectionState data element is set to the Connected value. It is used to send a LinkUtility message at regular intervals. The period of this timer SHOULD be 1 minute.

  • Connect Handshake timer: Exists for each neighbor connection where the ConnectionState data element is set to the Authenticated value. It is used to close the connection if the remote neighbor does not send a timely response. The period of this timer SHOULD be 1 minute.

  • Security Handshake timer: Used to close the connection if the remote neighbor does not send a timely response during the authentication protocol. The period of this timer SHOULD be 1 minute.

  • Referral Sharing mode: a Boolean value indicating whether the Peer Channel protocol client will use referrals to discover new neighbors.

  • MessageID Cache timer: A periodic timer used to initiate MessageId cache maintenance. The period of this timer SHOULD be 1 minute.

    Note This removes previously seen MessageIds to maintain a reasonable cache size.

  • Maintenance timer: Used to regularly run the maintenance cycle, which examines the neighbor connection set and tunes it for optimal throughput. The period of this timer SHOULD be set as specified in section 3.1.2.