[zeromq-dev] PGM: multiple listener behavior?
CFK
cfkaran2 at gmail.com
Thu Aug 9 21:26:02 CEST 2012
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 <salevy at illinois.edu> 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 <cfkaran2 at gmail.com> 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
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
More information about the zeromq-dev
mailing list