[zeromq-dev] Does ZMQ "Over Send" Using OpenPGM

Steven McCoy steven.mccoy at miru.hk
Wed Oct 20 11:46:35 CEST 2010

On 20 October 2010 17:34, Martin Sustrik <sustrik at 250bpm.com> wrote:

> Steven,
>  That's a lot of groups.  Most hardware and operating systems only
>> support 20, plus there is a common problem with groups on the same port.
> Ok. So what you are saying the problem happens only if you subscribe to
> more than 20 multicast groups, right?

More than 20 groups can hit a performance problem of filtering moving from
hardware to software.

The group/port issue requires only two sockets.

>   I would follow TIBCO's recommendation and only use unique ports, i.e.
>> <>,
>> <>, etc.
> Ok. We have a workaround. However, it would be nice to limit the user in
> such a way he can't possibly get it wrong. Say using a single hard-coded
> multicast group?

>From TIBCO support I found most administrators hate enforced group/port

Group specification should be as flexible as possible to give control to the
administrator.  If you don't specify a group it already defaults to or ff08::1.

>  The problem stems because the receiver listens to the port, and then
>> adds the multicast group.  Anything received on that port is processed,
>> including broadcast traffic.  Whilst on Linux you can bind to a
>> multicast group you cannot on other platforms and more importantly for
>> PGM you cannot receive unicast traffic and so reliability is not possible.
> So AFAIU you get even packets that you haven't subscribed to from the raw
> OS socket.
> Would it be a problem to drop the non-matching packets on OpenPGM or 0MQ
> level?

OpenPGM already does that filtering but the ZeroMQ wrapper is using the user
provided port for both UDP encapslation and data-destination.  Ideally there
should be a means to specify UDP encapsulation port and data-destination
port separately and then Bob can use the same port across multiple groups.

I'm not sure the best way of adding this to the URI specification, I've seen
some other software add options like this:


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20101020/468f48ea/attachment.htm>

More information about the zeromq-dev mailing list