From: Vince Deters

I’m working on a rudimentary pub/sub mechanism using Asio, with the requirement that the publisher be notified when a new subscriber appears. Using multicast, this would correspond to a subscriber joining the multicast group. But it appears there’s no way for the publisher to know this, correct?

AFAIK, that's correct.

If so, is the only alternative to dedicate a socket to each pub/sub pair?

I'm not sure what you mean. If you mean each entity (client) pair, you're talking a combinatorial explosion (i.e. you will need O(N*N) sockets), which doesn't scale very well. And I'm not sure what you mean by dedicating a socket to the pair. I'm pretty familiar with various pub/sub architectures and implementations, and there are multiple ways to design them, depending on your requirements. For example, many use a "broker in the middle" (e.g. Spread, which is freely available). Some use a dedicated daemon process to handle discovery and topic coordination, but don't use a "broker in the middle" for data delivery (or use a combination, depending on the reliability level). If you're designing anything at all non-trivial, you're talking about a pretty big project. I assume you also realize that UDP multicast is unreliable and you will have dropped datagrams. All pub / sub (or similar) libraries / implementations that I know of using UDP multicast (usually for better performance) also layer their own reliable protocol on top to handle this aspect. There are some publicly available reliable UDP multicast protocols (some may even be standardized - it's been a while since I checked). When you do a bit of research into it, you will find that there's not "one way", but multiple approaches, each with a set of tradeoffs. Cliff