Pub / sub messaging is a broad area, so there’s quite a bit of possible discussion.
 
>> 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.
 
Keep in mind the overall architecture / design. If you are mapping a TCP connection to each subscriber, from each publisher, the number of connections is (N –1) ** 2, which (obviously) grows large very fast. In other words, a connection “mesh” is only good for small numbers of participants. If you have a daemon / broker in the middle, or are using some form of multicast or broadcast, then there are also growth issues, but different kinds (they definitely scale much better).
 
>> 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.
 
I’m not sure why you need a blocking queue. You could have outgoing queues and fire off async writes for all outgoing connections. In particular, queue up a ref counted buffer (which you usually need for Asio anyway), fire off async writes for all connections, then the entry is automatically removed when all writes complete.
 
>> 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.
 
If you make everything async, there are no blocking issues. However, you might have an issue of an outgoing queue filling up, since the receiver is slow (buggy / hangs), and you might want to consider callbacks or policies that handle this situation.

>> Can someone provide some hints for best practices / design patterns / comments please?

 

You are just scratching the surface. I wrote a small pub / sub library designed for (mostly) static configs / connections, with “mesh” connections, with static (startup) topic discovery (currently no “dynamic” topic discovery), which is working well. But it’s a limited library, and has drawbacks for general use.

 

I just mentioned “topics” – most pub / sub messaging has the concept of topics, which provide the “glue” between the publishers and subscribers.

 

Check out the OMG DDS specs (http://en.wikipedia.org/wiki/Data_distribution_service), and you might want to also check out a proposed Boost library named Channel (http://channel.sourceforge.net/).

 

There’s also many other possibilities in the pub / sub space.

 

Cliff