Edit

Limiting Message Distribution

  • Article

Peer Channel is by design a broadcast mesh. Its basic flooding model involves distributing each message sent by any member of a mesh to all other members of that mesh. This is ideal in situations where every message generated by a member is relevant and useful to all other members (for example, a chat room). However, many applications have an occasional need for limiting message distribution. For example, if a new member joins a mesh and wants to retrieve the last message sent through the mesh, this request does not need to be flooded to every member of the mesh. The request could be limited to near neighbors, or locally generated messages can be filtered out. Messages can also be sent to an individual node on the mesh. This topic discusses using Hop Count, a Message Propagation Filter, a local filter, or a direct connection to control how messages are forwarded throughout the mesh, and provides general guidelines for choosing an approach.

Hop Counts

The concept of PeerHopCount is similar to TTL (Time-To-Live) used in IP protocol. The value of PeerHopCount is tied to a message instance, and it specifies how many times a message should be forwarded before being dropped. Each time a message is received by a Peer Channel client, the client examines the message to see if PeerHopCount is specified. If it is specified, then the client decrements the hop count value by one before forwarding the message to neighboring nodes. When a client receives a message with a hop count value of zero, the client processes the message, but does not forward the message to neighbors.

Hop count may be added to a message by adding PeerHopCount as an attribute to the applicable property or field in the implementation of the message class. You can set this to a specific value before sending the message to the mesh. In this manner, you can use hop count to limit distribution of messages throughout the mesh when necessary, potentially avoiding unnecessary message duplication. This is useful in cases where the mesh contains a high amount of redundant data, or for sending a message to immediate neighbors, or neighbors within a few hops.

Message Propagation Filter

MessagePropagationFilter can be used for customized control of message flooding, especially when the content of the message or other specific scenarios determine propagation. The filter makes propagation decisions for every message that passes through the node. This is true for messages that originated elsewhere in the mesh that your node has received as well as messages created by your application. The filter has access to both the message and its origination, so decisions about forwarding or dropping the message can be based on the full information available.

PeerMessagePropagationFilter is a base abstract class with a single function, ShouldMessagePropagate. The first argument of the method call passes in a full copy of the message. Any changes made to the message do not affect the actual message. The last argument of the method call identifies the origin of the message (PeerMessageOrigination.Local or PeerMessageOrigination.Remote). Concrete implementations of this method must return a constant from the PeerMessagePropagation enumeration indicating that the message is to be forwarded to the local application (Local), forwarded to remote clients (Remote), both (LocalAndRemote), or neither (None). This filter can be applied by accessing the corresponding PeerNode object and specifying an instance of the derived propagation filter class in the PeerNode.MessagePropagationFilter property. Ensure that the propagation filter is attached before opening the Peer Channel.

Contacting an Individual Node in the Mesh

An individual node in a mesh can be contacted by setting up a local filter, or by setting up a direct connection.

If the nodes in a mesh each have an individual ID, a destination ID can be specified in the implementation of your message. A local filter can be set up by writing a function in your message contract that will only display the message to the current node if its ID matches the destination ID you specified. The mesh transports the message, so the overhead of setting up a new connection does not have to be incurred. However, there is a loss of efficiency since the message is sent many times throughout the mesh. This works well for sending messages to individual members of a mesh as long as the messages are neither too big nor too frequent.

For long-lasting, high-bandwidth connections, direct connections are preferable. You can send connection information over the mesh, and then set up a direct connection of your choosing to send/receive messages.

Choosing an Approach for Limiting Message Distribution

When you discover a scenario in which you need to limit message distribution, ask yourself the following questions:

  • Who needs to receive the message? Just one neighbor node? A node somewhere else in the mesh? Half the mesh?

  • How often will this message be sent?

  • What kind of bandwidth will this message use?

The answers to these questions can help you determine whether to use Hop Count, a Message Propagation Filter, a local filter, or a direct connection. Consider the following general guidelines:

  • Who

    • Individual node: Local filter or direct connection.

    • Neighbors within a certain vicinity: PeerHopCount.

    • Complex subset of the mesh: MessagePropagationFilter.

  • How often

    • Very frequent: Direct connection, PeerHopCount, MessagePropagationFilter.

    • Occasional: Local filter.

  • Bandwidth use

    • High: Direct connection, less advisable to use MessagePropagationFilter or local filter.

    • Low: Any, direct connection probably not needed.

See also