Re: [boost] 0MQ messaging in Boost

Subject: Re: [boost] 0MQ messaging in Boost
From: Yigong Liu (yigongliu_at_[hidden])
Date: 2009-07-31 00:01:21

> 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#mozTocId84795
).
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#mozTocId182536
).
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#mozTocId891206
)

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#mozTocId836556
).

Regards
Yigong