One our very, very most frequently asked questions about PeerChannel takes the following form:

"I like the easy way in which I can send messages to everyone one in the mesh, but sometimes, I just want to send a message to [one person, my neighbor, a subset] in the mesh.  How do I do that?"

PeerChannel is by design a broadcast mesh, and so is built from the ground up with the intent that messages sent by members of the mesh are received by all members of the mesh.  Naturally, this means that PeerChannel is best suited for applications like data broadcast, chat rooms, collaboration, etc.  However, in many applications, there will be an occasional need for more limited communication.  Although there are variety of ways to limit message distribution, PeerChannel has no built-in method to send a message directly to another member of the mesh, but this is very easy to accomplish.  Before we examine options, be sure you ask yourself the following three questions when you discover a scenario in which you need to limit message distribution:

WHO needs to receive this 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? 

With these three questions answered, let us now discuss the different ways to limit message distribution with PeerChannel:

1) MessagePropagationFilter - This method is used at PeerChannel's transport layer to determine whether or not a message should be deliver to the local node and/or propagated throughout the mesh.  See our blog entry for more details.  Typically, this should only be used when propagating the message is determined by the actual content of the message, or other very specific scenarios.

2) HopCount - Attribute used to determine how many times a message should be propagated ("hops") before being dropped.  Once again, see our blog entry for more details.  This is perfect for sending a message to immediate neighbors or neighbors within a few hops.

3) Adding a local filter to the message contract - If the nodes in your mesh each have an individual ID, you can specify a destination ID in the implementation of your message, and have all the nodes ignore messages marked for delivery to another node.  This method is perfect for sending to individual members of the mesh, as long as the messages aren't too big or frequent.  This is because the mesh will still be used to transport the message, which means that you don't suffer the overhead of setting up a new connection.  On the other hand, there will be an efficiency loss as the message is sent many times throughout the entire mesh.  Here is a simple example taken from a Chat scenario: I want to send a message to only one person in the mesh, which we will call "whisper".  I add a Whisper operation to my contact:

[OperationContract(IsOneWay = true)]
void Whisper(string WhisperMember, ChatMessage msg)

I then implement the Whisper function as follows:

public void Chat(string WhisperMember, ChatMessage msg)
{
    if (WhisperMember != this.member)
    {
        Console
.WriteLine("[{0}] {1}", msg.msgSource, msg.msgTxt);
    }
}

4) Setting up a direct connection - You can send connection info over the mesh and then set up a direct connection of your choosing to send/receive messages.  This is preferable for long-lasting, high-bandwidth connections between two nodes. 

So how do you know which one to choose?  It depends on your answers to those three questions.  Let us revisit them and see what our answers tell us about which option to use:

WHO:
Complex subset of mesh: MessagePropagationFilter
Neighbors within a certain vicinity: HopCount 
Individual node: Local Filter or Direction Connection

HOW OFTEN:
Very frequent: Direct Connection, HopCount, MessagePropagationFilter are preferable
Occasional: Local Filter

BANDWIDTH USE:
High: Direct Connection preferred, less advisable to use MessagePropagationFilter or Local Filter
Low: Any, Direct Connect probably not needed.

Of course, many of these questions do not have black-and-white answers, so each specific application and scenario will be unique.  But the concepts remain the same.  I hope this helps a little in helping determine which method is best for you.  Thanks! -Jonathan