[SAGA-RG] SAGA Message API Extension

[Andre Merzky]

Hi John, 

attached is an updated version with some changes addressing
your comments.  The respective parts in the intro are marked
as ***NEW***.  The changes in the IDL and 'Details' section
affect the endpoint constructor and the serve() method only.

Would these changes address your points?  

Thanks, Andre.


Quoting [Andre Merzky] (Jan 17 2007):
> From: Andre Merzky <andre at merzky.net>
> To: John Shalf <jshalf at lbl.gov>
> Cc: Andre Merzky <andre at merzky.net>, SAGA RG <saga-rg at ogf.org>,
> 	Andrei Hutanu <ahutanu at cct.lsu.edu>, Werner Benger <benger at zib.de>,
> 	Gregor von Laszewski <gregor at mcs.anl.gov>
> Subject: Re: SAGA Message API Extension
> 
> Hi John!
> 
> Quoting [John Shalf] (Jan 16 2007):
> > 
> > 
> > Hi Andre,
> > In Chapter 2, the paragraphs explaining the message transfer  
> > requirements are a bit confusing.
> > 	1) it says it supports multicast (which is inherently unreliable).   
> > I'm sure you mean to say a "message bus" (sort of like the Linux DBus  
> > concept), which would not specifically call out a particular network  
> > standard (multicast is more specific than a "message bus").
> 
> You are right: using 'multicast' here is probably
> misleading.  Thilo made a similar comment, so I'll change it
> to "message bus" or so.
> 
> 
> > 	2) It says the message must be received completely and correctly, or 
> > not at all.  This leaves some aspects of the reliability uncertain.   
> > For instance
> > 		a) does this mean it must guarantee delivery of a message?  
> > 		Or only  that a delivered message does not contain errors?
> 
> It probably needs a more verbose explanation.  Tyhe current
> idea is:
> 
>   - the implementation MUST ensure that the messages are
>     complete and error free
> 
>   - if message delivery is guaranteed or not is up to the
>     implementation, and up to the used protocol.  The
>     implementation MUST document that aspect, and the URL
>     (scheme...) allows to choose between different
>     reliability modes.
> 
> I wanted to avoid a 'reliability' attribute on the endpoint,
> as I don't see a reasonable easy way to switch reliability
> in mid stream.  It is most likely that changes in
> reliability policy would require different protocols (only
> few protocols will be able to serve both ends), and would
> hence need a new connection setup anyway.  Not sure if that
> is reasonable though.
> 
> Anyway, that would leave us with specification of
> reliability on connection setup (i.e. endpoint construction)
> - right now that is done via the scheme part of the URL.
> Would a flag be more appropriate/explicit?  Probably...
> 
> 
> > 		b) what about if the message arrives more than once? (eg. 
> > 		redundant  copies of messages can occur in practice for a number of 
> > unreliable  or semi-reliable messaging protocols).
> 
> Good point.  IMHO we should specify that messages arrive 'AT
> MOST ONCE' (unreliable) or EXACTLY ONCE (reliable).  I don't
> think that we need to support additional modes, nor the
> complete spectrum of (un/)reliable transmission modes.  Or?
> 
> 
> > 		c) It says this document will not address things at a 
> > 		protocol  level, but I think these issues are semantic and therefore must 
> > be  addressed by the API.
> 
> IC, good point.  Well, flags on the endpoint construction
> would solve that.
> 
> > 		d) I think there are a number of attributes that users 
> > 		should be  able to supply or query when opening a message service 
> > connnection.   Like the JMS (Java Message Service), we should be able to 
> > specify  whether this is a point-to-point (message queue) or a publish- 
> > subscribe (message bus) like interface.  The API should not require  
> > any work to support both since point-to-point is a sub-category of  
> > the message-bus, but it should be an attribute of the message  
> > interface that a user can force/specify in the opening of the  
> > connection. 
> 
> Hmm, point to point could be simply established on
> application level, by just setting up a single connection.  
> 
> Uhm, problem: serve() can only be started, not stopped.  An
> int argument to serve(), giving the number of clients to
> wait for, would solve that.
> 
>   // point to point:
>   saga::message  msg;
>   saga::endpoint ep;
>   ep.serve (1);     // allow one client
>   ep.recv  (&msg);  // expect one message
>   exit;
> 
>   // publish/subscribe
>   saga::message  msg;
>   saga::endpoint ep;
>   ep.serve ();      // allow n clients
>   while ( 1 ) {
>     ep.recv  (&msg);  // expect m messages
>   }
> 
> Does that make sense?
> 
> 
> > Another thing to support is specification or query of  
> > the message service reliability (something that deserves at least a  
> > subsection to define.  That is, the document should define classes of  
> > reliability (just as done with other XML-based messaging APIs that  
> > even define intermediate cases for unreliable messaging that  
> > guarantee message arrival, but do not ensure that duplicate messages  
> > will not arrive).  The API should allow a user to specify these  
> > semantic attributes and will not allow a connection to be built if  
> > the underlying protocol for the message connection cannot meet those  
> > attributes.
> 
> Again, that could be done by using flags on the ep creation.
> I guess that a 'more reliable' connection than requested
> would be possible?  E.g., 
> 
>   saga::endpoint ep (saga::message::Unreliable);
> 
> could actually set up an unreliable or an reliable
> connection, as both would fulfill the user req.?
> 
> 
> Thanks, Andre.
> 
> 
> > 
> > -john
> > 
> > On Jan 16, 2007, at 11:17 AM, Andre Merzky wrote:
> > >Hi Folx ,
> > >
> > >here is the updated draft of the SAGA Message API, in
> > >preparation for OGF-19.  It is also available in CVS, as
> > >usual.
> > >
> > >We would be happy to get feedback on the list of course, so
> > >don't feel oblidged to hold back your comments for OGF-19
> > >:-)
> > >
> > >Cheers, Andre.
> > >
> > >
> > >-- 
> > >"So much time, so little to do..."  -- Garfield
> > ><saga_messages.pdf>
-- 
"So much time, so little to do..."  -- Garfield
-------------- next part --------------
A non-text attachment was scrubbed...
Name: saga_messages.pdf
Type: application/pdf
Size: 143469 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/saga-rg/attachments/20070117/94360bf3/attachment-0003.pdf