[SAGA-RG] SAGA Message API Extension

[Andre Merzky]

Hi John, Andrei, 

you are right: getting some feedback from the transport
level folx is certainly a good idea.  The API draft won't go
into public comment for another month or so (at least), and
then it will stay in public comment for another 2 months or
longer - that should give us enough time to contact them.

About ordering: the text Andrei cited is in the spec because
ordering is, as of now, not an attribute of the connection
or endpoint - so the spec tries to nail it down.  It says
"MUST be ordered, but no global ordering is required"
because I thought that this covers the majority of use
cases.

I don't think there are use cases which require global
ordering - or at least not enough to justify a requirement
for global ordering.  What is your opinion?  Also, thats
really difficult to implement in Grids IMHO. 

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?  Or are there
use cases which require non-ordered delivery for other
reasons?

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



-- 
"So much time, so little to do..."  -- Garfield