On Tue, Jul 27, 2010 at 3:46 PM, Oliver Smith <[email protected]> wrote: > > I sort of stole my own thunder with the Why ZeroMQ thing... > > Anyone any ideas on this?
Perhaps I'm misunderstanding your email. Sorry, if that's the case. It seems a fairly common conundrum. Since 0MQ connections are hidden in the pattern, you can't address them explicitly. This means specifically: * You don't know when they start * You don't know when they end * You cannot close them explicitly at the server side * You cannot send messages to them explicitly The first three restrictions make it impossible to use 0MQ for servers that need to manage per-connection resources that sit above 0MQ. You can do a lot using REQ-XREP sockets and identities, but you still don't have access to or control over the connection's lifecycle, meaning your server will run out of resources if you try to use identities for e.g. context. For example it is impossible to extend the multithreaded server example on the blog with a SASL-style challenge-response authentication. However, Martin is right that this stateless pattern is more scalable. It's how HTTP works. Every request is complete in itself. If something is missing (e.g. authentication), the server returns an error and the client resends the whole request. What's missing for me is user-space routing, to implement patterns other than those built-in to the code. So we have topic routing. How about regexp routing, or XML content based routing, etc.? Now to your problem of authenticating subscribers. I imagine you're not actually using multicast but TCP unicast, right? A ZMQ_PUB socket can connect to a ZMQ_SUB socket. So imagine that subscribers connect to the publisher via REQ-REP and provide their endpoint along with authentication credentials. The publisher verifies that and if it matches, connects through to their endpoint. The publisher does not bind(), so has no endpoint for unauthorized subscribers to connect to. If you want authentication over PGM multicast, you would need something similar except the publisher responds with a key that unlocks the multicast group, which must be encrypted in some way. -Pieter _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
