Proposal for REL-31

Here is a proposal for REL31:

 

Guaranteed delivery:
To deliver a message from 
a sender RMP to a receiver RMP without failure, or to report failure to the 
sender's application. To realize guaranteed delivery,the message MUST be 
persisted in the sender RMP until it delivery to it's receiver is acknowledged, 
or until the ultimate failure is reported to it's requestor. There is a 
requirement of the underlying transport protocol that the message MUST be 
transported without corruption.

 

When message persistence is lost for any reason, 
it is no longer possible to continue to guarantee message delivery.  Since 
the reliability of message persistence is A property of the system 
implementation, the conditions under which guaranteed message delivery holds is 
also a property of the system implementation..

 

Example 1). A PC Server may use a HDD for it's 
persistent Storage, and those messages persisted in the HDD are reliably 
maintained even if the the system software crashes and the system is rebooted. 
However, if the HDD itself crashes, it is no longer possible to guarantee 
message
delivery

 

Example 2) . A message persisted in a mobile 
phone may be lost when it's battery is detached. In this case, message delivery 
is only guaranteed by proper battery maintenance of the mobile 
phone.

 

--

REL-31 Spec 1.1.2 def Design Unassigned  
Peter Furniss 

Title: Meaning of gaurantee 

Description: Meaning of gaurantee needs to be defined (i.e. it is OK to 
announce 

failure of meeting guantee in a particular 
case)
Related to crash tolerance, see REL-5 
When is a guarantee not a 
guarantee? Message corruption issue may come up 

here. Should be specifying a protocl and its 
failure modes (relatively complete).
One case: Recipient loses all of their 
message identifier store and can no longer 

detect duplicates. Recipient system failed and 
sender is not notified. Outside 

the scope of the protocol, one of the partners no 
longer playing. Need to 

document the limitations of the protocol. (Cannot 
document correct error 

message for case where sender of that error does 
not know what is going on.)