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@merzky.net> To: John Shalf <jshalf@lbl.gov> Cc: Andre Merzky <andre@merzky.net>, SAGA RG <saga-rg@ogf.org>, Andrei Hutanu <ahutanu@cct.lsu.edu>, Werner Benger <benger@zib.de>, Gregor von Laszewski <gregor@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