The following section from the Channel documentation doesn't do much for me.

- containers (sequence, assoc) <=> name spaces (linear/hier/assoc) - elements in container <=> names (unit/element in name space) - iterator_range (target of algorithms) <=> name binding set (sender->receiver(s), receiver->sender(s)) target of dispatchers - algorithms <=> dispatchers

Hello Brian, Channel is a name-space based framework to help create asynchronous, distributed message passing systems. So it has the following characteristics: 1> Message senders and receivers bind to "names" in name-space to send/recv messages. Each "name" contains: id (could be integers in linear name space, string pathnames in hierarchical name-space...), membership (local/remote peer), send/recv scope(local/remote/global), etc. More details can be found at this section of design doc ( http://channel.sourceforge.net/boost_channel/libs/channel/doc/design.html#mo... ). 2> binding-matching rules will decide which senders will pass messages to which receivers - the so called binding-set which can be 1-1, 1-M, M-1, M-N. More details can be found at here ( http://channel.sourceforge.net/boost_channel/libs/channel/doc/design.html#mo... ). 3> The reason i am comparing Channel with STL is that in STL algorithms are independent from containers, defined in terms of iterator-range [first,last); algorithms can be applied to a container as long as it provides the required iterator. In Channel, dispatchers (dispatching algorithms) (push/pull, broadcast, roundrobin...) are defined on top of binding-set. So various dispatchers can be applied to diff name-spaces (linear/hier/assoc). In fact, Channel uses a policy based design; name-spaces and dispatchers are two template parameters of Channel template, so that each messaging application can choose/combine proper name-space and dispatchers types to generate a channel type which is best-fit for its messaging requirements. 4> When 2 channels are connected (thru shared memory or sockets), their name-spaces are "merged" - connected channels exchanges their names/ids with peer channels based on "names" attributes (membership, scope, etc), so threads/procs can talk to remote peers "transparently" as if they are local. This name-space "merging" protocol has the following properties: 4.1> since both connected channels exchange ids, it is a peer-peer messaging (both peers behave as client and server at the same time); not client/server where only server expose it capabilities 4.2> this transparent remoteness is the base on which we can build other applications such as high availability. More details about name-space merging can be found here: ( http://channel.sourceforge.net/boost_channel/libs/channel/doc/design.html#mo... ) There are several samples coming with the code, among which you may find this interesting "3.7 distributed chat thru a central server" ( http://channel.sourceforge.net/boost_channel/libs/channel/doc/design.html#mo... ). Regards Yigong