I'm interested in Stuart's question as well, but I'm also interested in the addresses you showed (e.g., "epgm://192.168.1.11;239.168.1.10,239.168.1.12,239.168.1.13,239.168.1.11:5000"). Where is that addressing form documented? I looked at both the 2.2 and 3.3 documentation and I didn't see it.
Thanks, Cem Karan On Thu, Aug 9, 2012 at 1:20 PM, Stuart Levy <[email protected]> wrote: > Question below - don't we still run into the multiple-listener problem? > > > On 8/9/12 11:20 AM, Steven McCoy wrote: > > On 9 August 2012 11:33, CFK <[email protected]> wrote: > [...] > >> can you >> connect multiple multicast addresses to the same interface in ZMQ? My >> thought is to make a pseudo-bus, where each member of a smallish set >> (10-15 nodes) publishes on its own address, but subscribes to all >> addresses in the set. > > > This is certainly supported: it is called asymmetric multicast. > >> >> Is it possible to connect the same interface to >> multiple multicast addresses, without causing any problems? If so, is >> the following acceptable code? >> [...] >> >> context = zmq.Context() >> >> publisher = context.socket(zmq.PUB) >> publisher.setsockopt(zmq.LINGER, 0) # discard unsent messages on close >> publisher.setsockopt(zmq.IDENTITY, "Producer - 192.168.1.10") >> publisher.connect("epgm://192.168.1.10;239.168.1.10:5000") >> >> subscriber = context.socket(zmq.SUB) >> subscriber.setsockopt(zmq.SUBSCRIBE, '') >> subscriber.setsockopt(zmq.IDENTITY, 'Consumer - 192.168.1.10') >> subscriber.connect("epgm://192.168.1.10;239.168.1.11:5000") >> subscriber.connect("epgm://192.168.1.10;239.168.1.12:5000") >> >> >> > Using the same port will multiply the received messages on Linux due to how > socket routing is implemented. > > The alternative form is using a single PGM socket: > > subscriber.connect("epgm://192.168.1.10;239.168.1.11,239.168.1.12,239.168.1.13,239.168.1.10:5000") > > This receives on .11, .12, .13 and sends on .10. > > subscriber.connect("epgm://192.168.1.11;239.168.1.10,239.168.1.12,239.168.1.13,239.168.1.11:5000") > subscriber.connect("epgm://192.168.1.12;239.168.1.10,239.168.1.11,239.168.1.13,239.168.1.12:5000") > subscriber.connect("epgm://192.168.1.13;239.168.1.10,239.168.1.12,239.168.1.11,239.168.1.12:5000") > > This looks great -- I'd be delighted to do it this way. (But, doesn't > someone need to bind()? Or can everyone connect() in this multicast > situation?) > > However... does it run the same risk? When I did, on a single linux host in > a single zeromq process, the C equivalent of > > publisher.bind("epgm://192.168.1.10;239.168.1.10:5000") > subscriber.connect("epgm://192.168.1.10;239.168.1.10:5000") > > ... then netstat -nau showed two UDP sockets bound to 0.0.0.0:5000. This > looked like the sort of trouble you were describing earlier, Steven, so I > assumed it wouldn't work reliably - one of those 0.0.0.0:5000 sockets was > listening for NAKs to the publisher, and depending on the order the two > sockets had been opened, the unicast NAKs might all go to the wrong listener > and get tossed. Am I misunderstanding this? > > _______________________________________________ > 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
