Use cases which do not require ordering should be happy with order preserving connections, too. Question now is: does the benefit of un-ordered implementations (simplier, smaller footprint) justify an attribute on API level?
In my opinion yes.
Or are there use cases which require non-ordered delivery for other reasons?
Andrei
Cheers, Andre.
Quoting [Andrei Hutanu] (Jan 18 2007):
Hi,
2) I see ordering is enforced, could that be an option?
I think ordering is *not* enforced, but I do wonder if it should be an option or a channel property (certainly semireliable will likely result in some reording whereas a TCP channel would enforce ordering of the messages for instance).
This is a controversial topic in the HPC message passing community (whether msg. ordering is a good or bad-thing to enforce in at the hardware level).
I was thinking the same (no strong feelings for either option or property) but the text tells otherwise : In 2.1 introduction : In contrast, this message API extension guarantees that message blocks of arbitrary size are delivered in order, and intact, without the need for additional application level coordination or synchronization. and
then in 2.1.7 reliability corectness and ordering The order of sent messages MUST be preserved by the implementation. Global ordering is, however, not guaranteed to be preserved:
Assume three endpoints A, B and C, all connected to each other. If A sends two messages [a1, a2], in this order, it is guaranteed that both B and C receive the messages in this order [a1, a2]. If, however, A sends a message [a1] and then B sends a message [b1], C may receive the messages in either order, [a1, b1] or [b1, a1].
Andrei