Boost logo

Boost Users :

Subject: Re: [Boost-users] [ASIO]: Best solution for Publisher/Subscriber pattern
From: Robert Ramey (ramey_at_[hidden])
Date: 2012-05-28 16:51:20


Ingo Maindorfer wrote:
> Hi All,
>
> currently we do some research in how we can do implement the
> classical Publisher/Subscriber pattern using ASIO. We had one thread
> that produces some kind of a message and like to send it out to 1 to
> n subscribers via TCP, where n is < 5. Message rate will be up to 800
> Hz. My first idea is that the producer thread puts the message in a
> blocking queue. On the other end a consumer thread waits, takes the
> message and send it to the subscribers via synchronous or
> asynchronous send. One requirement is, when one connection blocks
> (because their client is buggy/hangs) it's ok to drop messages for
> that connection, but we should deliver to the other subscribers. It's
> also a one way communication from publisher to subscriber.
>
> Can someone provide some hints for best practices / design patterns /
> comments please?

Hmm - I don't know if it's best practice but what worked for me was to:

a) The signals library implements the publish/subscribe pattern
b) use ASIO to generate async events.
c) use boost circular buffer and boost thread to create a
"bounded buffer" - this is an example in circular buffer.
d) use the bounded buffer to send events from the asio to
signals OR use signals to send messages to bounded buffers
corresponding to other tasks.

Note that in this scenario, nothing is blocked more than the time
it takes to append/remove a message from the bounded buffer.

This seems a little non obvious, but once you spend some time
with these three libraries, it all comes together in a very natural way.

Robert Ramey

>
> If I show up with some other lib like ZeroMQ my colleagues will fry
> me, so it's the easiest to use boost also for that task..
>
> Best,
>
> Ingo
>


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net