Thanks, i see, so DEALER <--> ROUTER doing kind of handshake at the beginning. If all good - identity is stored somewhere on the broker side for message routing.
Yeah, that's good question how to force disconnect offending peer. Are they consuming resources if nothing if routed to them but they are connected? On Sat, Dec 28, 2013 at 11:20 PM, Bruno D. Rodrigues < [email protected]> wrote: > peer A = dealer, connect, multiple peers (the “clients”) > peer B = router, bind, single peer (the “server”) > > peer A calls setIdentity with user+”:”+hash > peer A sends a message (empty is ok) > > peer B receives a message, which being a router, gets prefixed with the > identity > peer B validates the hash and accepts or rejects the connection > > if accept, store a hash map so replies can go back to the originator > > now the problem > if the connection is to be rejected, how to disconnect it? > > > On Dec 28, 2013, at 16:48, Dmitriy Vsekhvalnov <[email protected]> > wrote: > > Bruno, can you extend your thought. How can i track identity or peer? > > > On Sat, Dec 28, 2013 at 7:38 PM, Bruno D. Rodrigues < > [email protected]> wrote: > >> Use the identity for routing and a first message from your own for >> authentication. Now if the auth fails, I have no idea how to “disconnect” >> that peer :( but you can keep your own hash and never reply back to such >> peer. >> >> On Dec 28, 2013, at 15:17, Dmitriy Vsekhvalnov <[email protected]> >> wrote: >> >> Hi Pieter, well that's what i'm concerned about. Events (tasks) contains >> sensitive information and they shouldn't be routed to workers which are not >> authorized to view it. >> >> If worker (maliciously or by mistake) specify empty filter "" - it will >> get all messages, right? >> >> But i'm looking for authentication + filtering based on authenticated >> identity. I don't know, like maintaining hash map of authenticated workers. >> >> >> On Sat, Dec 28, 2013 at 11:49 AM, Pieter Hintjens <[email protected]> wrote: >> >>> On Sat, Dec 28, 2013 at 7:57 AM, Dmitriy Vsekhvalnov >>> <[email protected]> wrote: >>> > I probably didn't specify my concerns about filtering clear enough. If >>> > filter set to empty - sub will receive all events? That's not >>> acceptable, >>> > workers should never receive events that are not dedicated to it. >>> > >>> > Also I don't think pub/sub will work, because pub broadcasts messages >>> to all >>> > subs. And again this is not what we need, event should be processed >>> not more >>> > than once. >>> >>> You should perhaps start by reading the Guide and learning the basics. >>> Pub-sub uses a prefix match. If you make no subscriptions, you get >>> nothing. If you subscribe to "A" you get all messages starting with >>> "A". If you subscribe to "", you get all messages. >>> >>> -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 >> >> >> >> _______________________________________________ >> 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 > > > > _______________________________________________ > 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
