On 7 August 2012 09:01, Pierre Ynard wrote:
> For information, my personal transfer rate should be minimal enough, so
> I'm inclined to spare myself extra TCP or IPC sockets for the loopback
> case; that wouldn't fix the multiple sender issue anyway.
>
I've been thinking of implementing one of t
> Redundancy on the same host is retarded you are wasting resources to
> catch less 0.01% error scenarios that don't bring down the entire host
> or network;scaling sounds like a bad design: split the channel up into
> many separate PGM sessions with rate limited senders and your data
> stream load
On 6 August 2012 08:19, Pierre Ynard wrote:
>
>
> > It's been removed because of discussions like this
>
> This is now a discussion about the underlying issues of the PGM
> transport, not limited to ZMQ_MCAST_LOOP. Removing the option that made
> the issue most visible so that people don't compl
> It's been removed because of discussions like this
This is now a discussion about the underlying issues of the PGM
transport, not limited to ZMQ_MCAST_LOOP. Removing the option that made
the issue most visible so that people don't complain about it is just
sweeping under the rug.
> 0MQ makes
On 2 August 2012 07:20, Pierre Ynard wrote:
> 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
> 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 b
On 27 July 2012 11:27, Pierre Ynard wrote:
> > It can work well in a restricted environment, the disruptor team have
> > shown great performance with Java and multicast loop but with the PGM
> > protocol specifically there are problems and limitations that can
> > break reliability.
>
> Problems
> It can work well in a restricted environment, the disruptor team have
> shown great performance with Java and multicast loop but with the PGM
> protocol specifically there are problems and limitations that can
> break reliability.
Problems such as...?
I tried really hard but I couldn't figure o
On 26 July 2012 11:35, Ian Barber wrote:
> On Thu, Jul 26, 2012 at 4:27 PM, Pierre Ynard wrote:
>
> >
> > Anyway, is it safe to enable this option if I don't mind about
> > reliability?
> >
>
> I'm sure Steve can give a better answer, but basically multicast
> loopback just doesn't work very wel
On Thu, Jul 26, 2012 at 4:27 PM, Pierre Ynard wrote:
>
> Anyway, is it safe to enable this option if I don't mind about
> reliability?
>
I'm sure Steve can give a better answer, but basically multicast
loopback just doesn't work very well at all, and causes a lot of
confusion among people trying
Hello,
I took notice of https://zeromq.jira.com/browse/LIBZMQ-104
and of the removal of this option, but I have
trouble understanding the issue. Even after reading
http://lists.zeromq.org/pipermail/zeromq-dev/2010-June/004133.html
I don't get it.
> unicast packets are not broadcast to all listeni
11 matches
Mail list logo
