ZMQ_MCAST_LOOP semantics

[jcable]

Hi,
just had a play with 0MQ. Translated the Hello World example to use pgm where the client and server both use a pair of PUB/SUB sockets on the same multicast group. It works fine if the SUB sockets filter - the server filters on "H" and the client filters on "W". But I hoped that if I turned off ZMQ_MCAST_LOOP I could filter on "". But the client receives its own messages. I guess this is because the ZMQ_MCAST_LOOP applies to the socket, not to the transport. Since I'm only allowed to use PUB and SUB sockets with pgm, and PUB sockets aren't allowed to call recv, I'm not sure what the point of setting ZMQ_MCAST_LOOP on a PUB socket is. If the purpose of ZMQ_MCAST_LOOP is to set IP_MULTICAST_LOOP on the underlying dgram socket then 0MQ must be looping the messages back higher up the stack, in which case ZMQ_MCAST_LOOP is confusing - I would expect a socket option to affect the behaviour of the socket layer I send it too.

Julian

[jcable]

Hm ..

I tried using two separate multicast groups and I tried using two ports on the same multicast group.

Two ports on the same group gives an error:

Assertion failed: status == PGM_IO_STATUS_NORMAL (pgm_socket.cpp:490)

I guess this is to do with trying to join the group twice, but its perfectly standard to use different ports on the same group for different styles of communication (e.g. RTP and RTCP).

Using 2 groups with the same port results in message loopback. It looks like the dgram socket is only binding/connecting to the port with in_addr_any rather than binding to the group/port tuple as it should.

[jcable]

I also get the Assertion failed: status == PGM_IO_STATUS_NORMAL (pgm_socket.cpp:490) error with two groups on different ports:

sub_socket.connect("pgm://eth0;233.11.2.2:5556");
pub_socket.connect("pgm://eth0;233.11.2.1:5555");

[steve-o]

Windows requires ZMQ_MCAST_LOOP on the publisher, POSIX requires it on the subscriber.

[steve-o]

Line 490 isn't from master, the released versions of 0MQ only supported one PGM transport per process, this issue has already been resolved.

[jcable]

I'll try the unreleased version but I don't understand why there should be a platform dependency - arn't you designing an API with known semantics?

[steve-o]

To be platform agnostic it means that ZMQ_MCAST_LOOP should be set on both PUB and SUB.

Note that enabling multicast loop breaks reliability so it is not recommended for production use, only for test and development.

[sustrik]

Ok, no traffic for several months, i assume this issue is answered. Closing it.