Monitoring events of type 'EVENT_ACCEPTED' do not set the value field

[mariusspan]

According to the documentation of 'org.zeromq.ZMQ.EVENT_ACCEPTED' the 'value is the FD of the accepted socket.', however the value field is not being set for 'EVENT_ACCEPTED' events. The bellow sample shows this:

public static void main(final String[] args) {
        Context remoteSideCtx = ZMQ.context(1);
        Context localSideCtx = ZMQ.context(1);
        final CyclicBarrier barrier = new CyclicBarrier(2);

        new Thread(() -> {
            Socket localSocket = localSideCtx.socket(ZMQ.REP);
            localSocket.bind("tcp://127.0.0.1:9559");

            localSocket.monitor("inproc://monitor.pairsocket", ZMQ.EVENT_ACCEPTED);
            final Socket monitor = localSideCtx.socket(ZMQ.PAIR);
            monitor.connect("inproc://monitor.pairsocket");

            try { barrier.await(); } catch (Exception e) {}

            Event event = ZMQ.Event.recv(monitor, 0);
            System.out.println("event value was: " + event.getValue());
        }).start();


        new Thread(() -> {
            try { barrier.await(); } catch (Exception e) {}
            Socket remoteSocket = remoteSideCtx.socket(ZMQ.REQ);
            remoteSocket.connect("tcp://127.0.0.1:9559");
        }).start();
    }

[mariusspan]

Trying to troubleshoot this I've reached the point where monitoring events are being written to the monitoring socket: zmq.ZMQ.Event::write . In contrast to the documentation, it seems that only Events that have the 'flag' member set with 'VALUE_INTEGER' will get a value for the 'value' member.

Any ideea why the 'VALUE_CHANNEL' values are left out?

[fredoboulo]

Events are sent via messages on a socket, and there is currently no solution to write a channel in a ZMQ message. C++ implementation does that by sending a pointer, which works for that technology. Java does not offer that possibility.

[mariusspan]

Actually I'm looking for the IP (optionally the port) of the remote peer which connected to the socket. This kind of information is already available when writing the monitoring event into the monitoring socket and it could be easily written into the socket.

I do understand that the IP is something that characterizes TCP based transports and makes no sense for other types of transports. I wonder if there is anything that characterizes the remote peers when using other types of transports and if such data could be included into the bytes being written to the socket. If not, sending the byte[] array representation of the remote IP for the TCP transports and leaving it null for the other transports (as currently is) be a suitable option?

BTW: I got into this issue because this was the only way I could find the IP of the remote peers connecting to a socket. If there is any other option for achieving this I'm open for any suggestions.

[sigiesec]

This sounds good to me. Maybe transfer the remote address as a string, not in binary form. Then it is easier to also use for transports other than TCP/IP.

I think at the moment JeroMQ uses the monitoring protocol also used by libzmq. This is required for exchangeability/compatibility with jzmq, but not for interoperability with libzmq etc., since monitoring only happens locally via inproc sockets. I think the kind of monitoring information that can be given is quite implementation-specific, so attempting exchangeability/compatibility with jzmq does not sound like the best idea.

The current monitoring of libzmq is quite limited, there are several points where more information would make sense.

If you use a ZAP handler, the ZAP message contains the remote address.

[fredoboulo]

If you want to investigate around the ZAP solution, a new component named ZAuth may be of interest to you. It basically handles ZAP requests and replies, and provides a way to collect ZAP authorization replies together with remote address info (when PR #475 is merged). It is still in early draft and not published, so feel free to play with it, suggest modifications, and so on...

The identity of the socket peers may be also a point of interest to you.

[mariusspan]

@sigiesec @fredoboulo thanks for your replies and suggestions. I do feel that adding auth to my case would be overkill for solving the initial issue (simple tracking of peers connection and disconnecting). I did some testing with a local build and sending the IP as part of the Event seams to do the trick, at least for my case.

I was planning to refine this into a merge-request but unfortunately I got stuck upgrading my app to the latest version (from 0.3.6). I'm planning to get back to this as soon as I manage to have a stable build of my application running on top of 0.4.3-SNAPSHOT.

[daveyarwood]

@mariusspan Any updates?