[SAGA-RG] SAGA Message API Extension

[Andrei Hutanu]

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