I opened issue https://github.com/zeromq/libzmq/issues/802.
Maybe it would be possible to write an API like this: /**Upon successful completion, returns the public key used for the message, if available, or else the null pointer. */ char *zmq_msg_who (zmq_msg_t *msg); On Jan 1, 2014, at 3:24 PM, Pieter Hintjens <[email protected]> wrote: > Hmm... this isn't going to be that easy. The connection doesn't have > an identity until after it's authenticated. This means the only > plausible solution is to provide authentication metadata to the > zmq_msg API. > > On Wed, Jan 1, 2014 at 10:19 PM, Pieter Hintjens <[email protected]> wrote: >> There's no issue open for this. Feel free to create one (we use the >> github issue tracker now). I'll start by changing ZAP to provide the >> client id. >> >> On Wed, Jan 1, 2014 at 9:04 PM, Drew Crawford <[email protected]> >> wrote: >>> Ok. Is there an issue open for this? >>> >>> I'd be happy to take a run at it if that will help get it in the next >>> release, although I can see from this thread that I'm probably not >>> qualified to get it right the first time. >>> >>> Drew >>> >>>> On Jan 1, 2014, at 8:18 AM, Pieter Hintjens <[email protected]> wrote: >>>> >>>> On Wed, Jan 1, 2014 at 1:12 PM, Drew Crawford <[email protected]> >>>> wrote: >>>> >>>>>> 2. we publish all ZAP replies to a secondary inproc:// socket (PUB-SUB) >>>>> >>>>> This also seems curious. I’m wondering if you’re envisioning a more >>>>> complicated ZAP handler in some faraway module as “typical” than the one >>>>> I plan on writing. Basically my entire interest in ZAP is in using it to >>>>> solve this “who is sending me / are they allowed to send me this message” >>>>> problem. If ZAP isn’t the right way to do that, it’s probably worth me >>>>> learning what ZAP is actually for, as that means my mental model isn’t >>>>> right. >>>> >>>> Maybe it's curious, yes. I'm thinking the ZAP handler has all the >>>> information we need to correlate client IDs (the first frame on the >>>> ROUTER message) with metadata and can provide this to apps in some >>>> way. >>>> >>>> Either it's via libzmq, or it's via another inproc:// path to apps. >>>> There are a few plausible patterns for that. >>>> >>>> Passing the client ID back out in replies is probably silly, yes. >>>> >>>> -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
