[Sis-ams] Predictability concerns with AMS, and other questionstoo

[Marek Prochazka]

Hi Scott,

> Actually the application can indeed have knowledge of which 
> nodes are currently subscribed, because subscription 
> indications are (optionally) passed up to the application by 
> AMS whenever subscriptions are detected.  But the application 
> isn't required to ask for these indications or to remember 
> them; publication works the same way in any case.

O.K., I see.

> Again, nodes don't need to exchange heartbeats among 
> themselves to get this information: AMS knows about it anyway 
> (because of the heartbeats exchanged between nodes and 
> registrars), and the registration and unregistration (whether 
> intentional or not) of nodes is always
> (optionally) announced to the application by AMS whenever 
> these events are detected.  And, again, the application isn't 
> required to ask for these indications or to remember them, 
> but is free to do so if it likes.

Right, what I had in mind was the heartbeats exchanged with the
registrar and available to AMS.

> When a node publishes a message, the message is sent to N 
> destination nodes where 0 <= N <= (cardinality of the message 
> space).  Each message transmission utilizes a transport 
> service that is implicitly chosen for that particular 
> transmission based on the service mode specified by the 
> subscriber.  The only possible guarantees on delivery and 
> performance for each individual transmission are those 
> provided by the underlying transport service.  If, for 

I understand that you rely on the underlying service. But still, the AMS
doesn't give the user any chance to reason about delivery. In other
words, being implemented on top of a transport service, the AMS will get
exact failure codes if they are available, but there is no way to get
them from AMS. Or is it?

> The key concept here is that AMS by design gives the 
> application a great deal of control over - and, 
> correspondingly, responsibility for - message exchange 
> performance.  Application developers still have to give some 
> thought to exactly what is important to them, because nothing 
> comes for free - retransmission increases the chance of 
> delivery but increases latency, real-time performance is only 
> possible in networks of limited scope, bandwidth reservation 
> can degrade network performance, and so on
> - and AMS declines to make all these design trade-offs in 
> advance and lock all developers into those decisions.
> 
> Summing up: AMS is no substitute for engineering.  There's no 
> magic here.

I didn't ask to get something for free. We consider AMS to be used for
our project and we like the publish/subscribe model and the support for
priorities. So far we have been using MTS and we think that AMS might be
a better choice. (Recently I read something about the OMG Data
Distribution Service and it seems very similar to AMS either.)

As a part of the project, we will have to implement a distributed
consensus algorithm on top of MTS or AMS. The more the
communication/transport protocol is reliable (bounded message loss,
bounded delays, etc.), the easier is to design and write a solution that
solves the consensus problem.

It seems to me that there is basically no delivery guarantee provided by
either MTS or AMS.

Marek