Hello list! I need to do broadcasts to (transient) groups of clients, so the PUB/SUB seems the clear solution. However, since my clients are connecting from the internet (so TCP unicast) I essentially can't trust their subscriptions to be trustworthy. I've seen several authenticated PUB/SUB suggestions on the mailing list suggesting server side encryption of PUB and using an out-of-band REQ/REP for key exchange.
This works, but is inconvenient when group membership is transient (requires rekey-ing all subscribers after one client leaves the group). So after some thinking I started considering handling subscription server side too. Have a broker with a ROUTER and PULL socket, clients connect to the ROUTER and for every client I start a lightweight thread with a SUB and PUSH (connected to the broker's PULL) socket, the threads read from the SUB and write to the PUSH. The broker then simply forwards every message from the PULL socket to the ROUTER. As far as I can tell the pros and cons are: Cons: - 2 extra sockets per client (SUB and PUSH) - Needs extra plumbing for client threads to be told to subscribe/unsubscribe - Extra overhead from broker logic and client threads Pros: - Rest of infrastructure can be simple PUB/SUB/XPUB/XSUB without worrying about authentication - inproc sockets should keep extra overhead fairly low Does this type of design make sense? Would anyone approach this differently? Kind regards, Merijn _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
