hello, there seem to be many problems with below scheme, most serious being its ambiguity. e.g. what are "authentication credentials"? are you sending username/password as cleartext?
also, what concern are you trying to address? integrity? confidentiality? (i'm not sure what a game would need) are you doing any sort of logging somewhere? if so, do you log messages as cleartext? if not, will they be decipherable 10 years from now? where would you store the keys? ======== i see two ways to add security to pub/sub model: 1) let anybody subscribe to any stream, but distribute decryption keys to only authenticated people (using 0mq or not). many key distribution schemes that address various needs exist. this will work without any change to the zeromq protocol. (same has here: http://lists.zeromq.org/pipermail/zeromq-dev/2010-July/004670.html just don't invent your own key distribution scheme) 2) if you're not comfortable publishing the ciphertext, or have other concerns like resource usage, the 0mq protocol must be extended to support (preferably pluggable) authentication / authorization mechanism. authentication for "who gets the messages" and authorization for "this guy gets which messages". the task of designing a protocol that'll satisfy everyone's needs is daunting at best :) best, burak On 07/27/10 20:28, Pieter Hintjens wrote: > Here is, I think, how to build an authenticated pubsub service using > 0MQ. The design handles authentication, arbitrary routing criteria, > and flushing of dead client connections. > > You will use ZMQ_XREQ at the client side and ZMQ_XREP at the service > side. There is a simple protocol between client and server that is > loosely modelled on HTTP: > > * Client sends messages containing: identity (0MQ adds this > automatically), authentication credentials, and subscription criteria. > * Server sends messages containing: identity (automatic), > error/success code, and content. > > The server has two main data structures: > > * A connection table that stores authenticated identities and > timestamps. Each identity corresponds to a client connection. > * A routing table that maps message keys (e.g. topic value) to > identities. There are techniques for doing > [http://www.zeromq.org/whitepapers:message-matching high speed message > matching]. > > The client has a single thread that polls on its ZMQ_XREQ socket. At > regular time intervals it (re)sends its authentication and > subscription message. This acts as a keep-alive. > > The server has a two threads, one that polls on its ZMQ_XREP socket > and one that receives outgoing messages and passes them to the polling > thread via inproc sockets. The polling thread processes any incoming > client requests and updates its data structures. It processes any > outgoing messages by looking up the message key in its routing table > and then sending the message (one to one) to all matching identities. > As it does this it deletes any expired identities. > > That's it. Sorry if I got some things wrong here, it's theory and not > based on running code. > > -Pieter > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
