I'm in the throws of converting one of our data transports to ZeroMQ. It occurred to me that I could let our end-user clients connect to this to tap into the stream directly rather than the manual re-forwarding that we do now.
But we don't want them randomly creating their own clients that connect to it. (Our product is an online game, http://www.battlegroundeurope.com/) A little bit of searching seems to indicate ZMQ doesn't have anything like this ... yet. Because ZMQ abstracts the connections, it seems a little more involved than the ordinary connection authentication, but I can see solutions to almost all cases except PUB/SUB (which, dangit, is the one I want to use at the moment ;-P) Off-the-cuff what I imagine is an extension of regular pub/sub, where the pub-end doesn't add incoming connections to the multicast list until they have auth'd: ps = ctx.socket(ZMQ_AUTHPUB) ps.setsockopt(ZMQ_AUTHAGENT, "inproc://authentication-threads") When this socket is connected, ZMQ quietly opens a ZMQ_REQ socket to "inproc://authentication-threads". [ s.authSocket = s.context.socket(ZMQ_REQ) ] The client would then do: cs = ctx.socket(ZMQ_AUTHSUB) cs.setsockopt(ZMQ_AUTHTOKENS, "user=fred,pass=password", strlen(that)) The auth-tokens are opaque to zmq, it's just going to forward them. When this client connects to the PUB, ZMQ automatically sends the auth token. On receiving an auth token, the pub listener forwards the received auth-tokens along with, perhaps, the originating IP address in dotted-decimal notation, to the authenticator... ps.authSocket.send(printf("%s:%s", inet_ntoa(sourceIP), incomingTokens)) The authenticator - which is a user supplied piece of code - checks if this connection is permitted to go onto the actual multi-cast list and sends back approval. _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
