[zeromq-dev] Confirm authentication and retrieve metadata?

[Stephen Eley]

Hi all,

I'm trying to build a Ruby wrapper with simple support for some of 0mq's newer features, including encryption and authentication. I believe I have a pretty good handle on the socket options and how the ZAP authentication handler needs to work. However, I've been conceptually hung up on how to detect and pass failures back to the user application, and scouring Google and the source code hasn't helped. 

My questions:

1. The RFCs all say that server sockets are to disconnect in the event of a CURVE key or ZAP authentication failure. But the zmq_connect call doesn't appear to wait for any of that, and even with ZMQ_IMMEDIATE set it doesn't seem to have any relevant error codes. Short of setting up a zmq_socket_monitor and listening for disconnect events in a dedicated thread, is there any way I can figure out on the client end that a connection never cleared security?

2. If I did take the zmq_socket_monitor route, is there any way to tell the difference between a ZMQ_EVENT_DISCONNECTED that happened because of a CURVE or ZAP failure and one that happened for any other reason?

3. The ZAP protocol defines a frame for a user ID "for use by applications." There's another one for metadata with similar intent. However, I can't figure out how the application is supposed to get ahold of that data. I see that 0mq 4.1 has a zmq_msg_gets function for metadata on every message, but that doesn't help current production users, and querying on received messages seems like an odd place to get connection-level information that's given exactly once. If that future functionality is the only way, how does one go about getting metadata on a send-only socket?

Apologies if these are dumb questions and I missed something obvious. And thanks in advance for any tips or pointers to example code. 


Have Fun,
Steve Eley

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20150408/f106ecaa/attachment.htm>