Why is a new RabbitMq plugin required when Confirms numbers messages?

[ngbrown]

I understand that SignalR expects a sequence number on receive, but this is already built into RabbitMq with Confirms:

Once a channel is in confirm mode, both the broker and the client count messages (counting starts at 1 on the first confirm.select). The broker then confirms messages as it handles them by sending a basic.ack on the same channel. The delivery-tag field contains the sequence number of the confirmed message.

The new plugin nor the old way described in UniqueMessageIdentifierGenerator.cs does not describe why the non-native sequence numbers are being generated.

So why all the trouble to have a new RabbitMq plugin when we could use Confirms?

[mdevilliers]

This looks very interesting.

If I have read the page correctly each channel would have its own consistent incrementing number.

If my understanding is correct - my question is - would this lead to different channels having their own identifier?

If the answer is no and the identifier given is a global across all channels - this looks good, really good.

If the answer is yes we would loose the consistency for message ordering across server farms. This would manifest itself when signalr connections switch from server to server and the messages will be served from different machines each with their own channel (each with their own identifier). This would lead to missed messages and weirdness.

Using the plugin was the only way I could find that would guarantee message ordering.

I am open to other approaches if they offer the properties that we need - especially if they lead to a simpler solution.

Mark