[SAGA-RG] SAGA Message API Extension

[Andre Merzky]

Quoting [John Shalf] (Jan 17 2007):
> 
> I agree.  I think the reliability semantics should be a property of  
> the channel (and hence underlying protocol) and not something to  
> switch at runtime.  However, I think the clients that use the  
> connection should be able to query what the channel properties are  
> (or define the minimum requirements and throw an exception if they  
> cannot be met).  This is just a little introspection (not really a  
> deep or fancy coding underneath).

I agree - that can safely be done with a read-only
attribute.


> >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?
> 
> I cannot remember the document, but there was a spec for defining  
> reliability of another kind of messaging bus.  It had
> 	unreliable: message may or may not arrive (typical UDP).
> 	semi-reliable: message must arrive (will be retransmitted if not  
> acked).  Source keeps resending until it sees the ack.  It is  
> possible that the ack is lost, in which case, the message may arrive  
> at the client twice (so this is a Message will arrive at least once,  
> and possibly more than once.)  This protocol is useful since the  
> message destination does not need to maintain complex message  
> state... it just acks messages that arrive (very simple).
> 	reliable: the message must arrive and it will only arrive once.

I added to the spec:

   The available realiability levels are:

   \up
   \begin{tabbing}
    XXXXXXXXXX          \= \kill
    |Unreliable|:       \> messages MAY (or may not) reach the
                           remote clients.\\[0.3em]

    |Atomic|:           \> |Unreliable|, but a message received 
                           by one client is\\ 
                        \> guaranteed to (MUST) arrive
                           at all clients.\\[0.3em]

    |SemiReliable|:     \> messages are guaranteed to (MUST) 
                           arrive at all\\
                        \> clients, but may arrive more than once.\\[0.3em]

    |Reliable|:         \> all messages are guaranteed to (MUST) 
                           arrive at\\
                        \> all clients.\\[0.3em]
   \end{tabbing}

That is similar to your list, but adds the 'atomic' one.
Not sure if that is useful (sounds like) or easily
implementable (??), but I found it in a list of relibility
modes for message transmissions which looked sensible, and
seems to be close to what you propose.

[ about point-to-point ]

> That does address one of the cases (not exactly the one I was  
> thinking of).
> Also should allow -1 to specify *any-number-of-clients* at the  
> underlying protocol's discretion.

Yes, definitely, thats in the spec already.


> But now for a semantic thicket....
> 
> Case 1: I connect to a named destination and I am joined together  
> with everyone else who has connected to that port.  In this case, any  
> message I send will be broadcast to everyone else and vice verse  
> (message bus).  This is the equivalent of a publish-subscribe service.
> Case 2: I connect to a port and I own the service.  This appears to  
> be the case you are setting up above as it only allows one client to  
> join the service.
> Case 3: I connect to the port and for a sub-process that does not  
> share the messages with the other clients that have connected to that  
> port (like an HTTP server).  I don't quite see how that kind of point- 
> to-point message service is supported.
> 
> I think we need an attribute for the message port that says whether  
> it is a bus or a point-to-point.  In addition, I like the idea of  
> setting the message queue length (as you have above).  I was not  
> thinking of that, but I can see the value of creating a first-come- 
> first-serve message port as well. (if that is not too complicated).

Got you (I think) :-)  Yes, that makes sense.  I added a
'topology' enum and attribute, which is handled similarly to
the 'reliability' property (static over connection/endpoint
lifetime, inspection via ReadOnly attribute).


New draft is attached, with new sections marked.  It would
be great if you could review the paragraphs about connection
topology.

Thanks!

  Andre.

-- 
"So much time, so little to do..."  -- Garfield
-------------- next part --------------
A non-text attachment was scrubbed...
Name: saga_messages.pdf
Type: application/pdf
Size: 150322 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/saga-rg/attachments/20070118/04b3b82c/attachment-0003.pdf