[zeromq-dev] epgm protocol question
taurel at esrf.fr
Tue Apr 13 14:41:08 CEST 2010
Thank's very much for your answer.
I don't think the sender uses the whole bandwidth available. My 2 hosts
are linked with a 100 Mbit link.
On both publisher and subscribers, I have limited the rate (using the
ZMQ_RATE socket option) to
This is confirmed by the wireshark IO Graph
On 13/04/2010 14:04, Martin Sustrik wrote:
> Emmanuel TAUREL wrote:
>> Hello all,
>> I am using zmq 2.0.6 on Ubuntu 9.04 boxes.
>> I am using PUB/SUB with the epgm protocol. I have one publisher on host
>> A and 2 subscribers on host B.
>> The ZMQ_RATE is set to 20000 on both publishers and subscribers. I do
>> not filter anything on the subscribers side. On the publisher side, I have
>> a ZMQ_HWM set to 100 and ZMQ_LWM set to 50.
>> I am sending 4 kbytes messages. The first byte within each message is a
>> counter which allows me to check that I haven't lost any message.
>> My problem is that I am loosing messages!
>> I have wireshark on both sides (Host A and Host B). I have studied a
>> little bit what happened during my transmission.
>> On Host B (the receiver), I notice a hole in the ODATA sequence number
>> sent by Host A. Then, Host B send a NAK packet requesting the missing
>> Host A reply to this NAK packet by a NCF packet which according to what
>> I have read in RFC 3208 is correct. But I do not see any RDATA packet
>> sent by the source (Host A) and therefore my subscribers loose the
>> concerned messages!!
>> I agree that the wireshark on host A (the sender) tells me that the
>> datagram missing on Host B (the receiver) have been sent but I guess
>> these packets have been lost by the
>> switch between the 2 hosts. But as far as I have understood PGM, it is a
>> reliable protocol and this case should be covered by some
>> re-transmission which apparently in my case is only half-done.
>> Are you aware of some similar cases?
> One scenario I can think of is that the sender uses whole bandwidth
> available (ZMQ_RATE socket option) for sending new data. Thus there's no
> bandwidth available for retransmissions.
> If that's the case the behaviour is OK and everything works as expected.
> The rationale is that a single slow consumer should not slow down the
> sender and thus all the well-behaved consumers that may be listening to
> the same feed.
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
More information about the zeromq-dev