[SAGA-RG] SAGA Message API Extension

[Andre Merzky]

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