[zeromq-dev] ZMQ_MCAST_LOOP with PGM

[Pierre Ynard]

> The OS only forwards packets to the first open socket.

> Check the RFC's on PGM and PGMCC for details of the protocols in
> question,
>
> http://www.ietf.org/rfc/rfc3208.txt
> http://www.ietf.org/proceedings/57/I-D/draft-ietf-rmt-bb-pgmcc-02.txt

To be clear, if I understand correctly, OpenPGM binds a UDP socket
to the port given with the multicast address, using SO_REUSEADDR.
Then it uses this socket to both receive the multicast stream (hence
SO_REUSEADDR) and the unicast NAKs. This is why if a sender and a
receiver run on the same host, the socket of only one of them will
receive unicast NAKs, breaking it for the other one. Right?

So NAKs are sent back upstream with the same destination port as packets
flowing downstream (the multicasting port). To an outsider like me, this
feels confusing and counter-intuitive, and looks like a weird quirk.
I tried to gather the reason from the RFC but I got very confused by
§8.3: is this really what is described there? Keeping in mind that the
UDP encapsulation mode is not described by the RFC? Anyway, I don't
grasp the whole implications of this in the protocol, but it would make
more sense to me if the NAKs were sent back to the source address and
port of the sender, back from an address they came from. Also it might
avoid this problem in the first place.

But more importantly for ZeroMQ; if that's what it is, the problem
is not really related to multicast loopback, just to running several
instances on the same host. Then, running several senders (to the same
group-port) on the same host is a problem too as it breaks reliability
for all but one of them. And that wasn't solved by removing the
ZMQ_MCAST_LOOP option. To be thorough, there would also be some kind of
security issue on multi-user hosts: a malicious user could open a UDP
socket on that same port, and would at best DoS the ZeroMQ application
without it noticing, or at worst spy on leaked information about the PGM
network topology.

Isn't the problem a bit more complicated than just removing the loopback
option because it shouldn't be used? This option fits my use case so of
course I'd welcome its return :) But I'm worried by the rest too because
regardless of receivers and loopback, I plan on running several senders
in parallel on the same host.

Best regards,

-- 
Pierre Ynard
"Une âme dans un corps, c'est comme un dessin sur une feuille de papier."