Delivering a Certified Message

Once a delivery agreement is in place, all subsequent messages on the subject (from the certified sender to the certified listener) are certified messages. Each certified message generates a series of protocol actions:

• When a certified listening transport queues a certified message for the listener’s callback function, it includes the sender’s correspondent name and the message sequence number.
• When the callback function returns, the certified listening transport automatically confirms delivery to the sender. (Programs can override this behavior and confirm delivery explicitly.)
• When confirmation reaches the certified sender, the sending transport records delivery in its ledger, and presents a DELIVERY.CONFIRM advisory.
• When confirmation has arrived from every certified listener for this message, the sending transport deletes the message from its ledger, and presents a DELIVERY.COMPLETE advisory (to the transport it employs for network communication).

Automatic Confirmation of Delivery

The default behavior of certified listener transports is to automatically confirm message delivery upon return from the callback function. Programs can selectively override this behavior for specific CM listener event objects (without affecting other listener event objects).

By overriding automatic confirmation, the listening program assumes responsibility for explicitly confirming each inbound certified message.

Consider overriding automatic confirmation when processing inbound messages involves activity that is asynchronous with respect to the message callback function, such as computations in other threads or additional network communications.

Confirmation of Delivery Calls

C

tibrvcmEvent_ConfirmMsg()

tibrvcmEvent_SetExplicitConfirm()

C++

TibrvCmListener::confirmMsg()

TibrvCmListener::setExplicitConfirm()

Java

TibrvCmListener.confirmMsg()

TibrvCmListener.setExplicitConfirm()

.NET

CMListener.ConfirmMessage

CMListener.SetExplicitConfirmation

Requesting Confirmation

If a certified sender transport does not receive prompt confirmation of delivery from a certified listener transport (for example, because of network glitches), it automatically requests confirmation. After each request, it presents a DELIVERY.NO_RESPONSE advisory.

When a certified listening transport receives a request for confirmation, it checks its ledger, and reconfirms receipt of the messages that it has already confirmed. (This behavior is identical, whether the program uses automatic confirmation, or overrides it.)