On 01/11/2019 12:21 pm, Alan Conway wrote:
Would sending the messages pre-settled solve this problem?
It would prevent looping, but by dropping all queued messages which would again mean there was little in point in having the waypoint there (and if there was no waypoint there would be no looping anyway).
I'm not quite clear on the value of using a waypoint on a multicast address anyway, but sending presettled would negate whatever value there might be.
That would allow the router to drop them for other reasons (inter-router congestion) but I always found the notion of wanting settlement of a multicast message to be a bit strange (what if there's nobody, what if they give different outcomes, what if somebody is slow etc. etc.) To me multicast pretty much requires unreliable delivery to make sense.
To be completely reliable it requires distinct transfer to each of a set of known, named, subscribers.
However I personally think the new acknowledged behaviour *is* useful. A delivery is released if it could not be delivered to any consumer or modified if no consumer acknowledged it, otherwise if at least one consumer accepted it, it is accepted. That to me gives useful hints to the sender of the message. It does not mean that every subscriber is guaranteed to see the message of course, but I don't think that is the purpose. In fact the main reason for transmitting unsettled is actually to get end to end flow control.
Now you have two distinct behaviours for multicast, based on whether you send presettled or unsettled. The latter is *not* 'reliable pub-sub', but is a good alternative to e.g. a broker with non-durable subscribers. (The former is I think best for very time sensitive data, though even there I think it could be tweaked to have better characteristics).
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
