[zeromq-dev] epgm protocol question

Martin Sustrik sustrik at 250bpm.com
Tue Apr 13 14:04:52 CEST 2010


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 
> datagram.
> 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.

Martin



More information about the zeromq-dev mailing list