The situation with settlement isn't quite analogous to the open/close
handshake because at the protocol settlement is not an actual handshake,
it's a truly one way operation. Conceptually, settling a delivery consists
of forgetting everything about that delivery. When this happens the
protocol does notify the peer that the delivery is settled, however there
is no answer at the protocol level because the answer would reference a
delivery that you claim to have forgotten about.

Really the protocol is defined in terms of unsettled deliveries and the
notification of settlement is simply an optimization, e.g. at link recover
the two endpoints exchange information about unsettled deliveries and from
this they infer if any of the deliveries they retain have been settled by
the peer. (It's the absence of information that implies settlement in this

This basically means there is no way to confirm that a peer has received
the notification of settlement and it doesn't really make sense to try to
do so given what settlement is defined to mean. I suspect if you feel the
need to do this you should be using delivery states, e.g. not settling the
delivery until it reaches a terminal state such as ACCEPTED or REJECTED.
Once you confirm that the delivery has reached the appropriate terminal
state you can then settle and you truly shouldn't care about the delivery
at that point anymore.

Note that if I've misinterpreted your question and all you care about is
knowing whether the settlement info has been written to the wire (as
opposed to possibly being buffered in the transport), then it's possible
that pn_transport_quiesced() might help you out.


On Mon, Sep 22, 2014 at 12:19 PM, Dominic Evans <dominic.ev...@uk.ibm.com>

> For operations such as `pn_link_close` its fairly easy to confirm that it
> has
> been transmitted over the network and that the appropriate @close response
> has been received from the remote end by doing a state check (e.g., if
> (!(pn_link_state(link) & PN_REMOTE_CLOSED)) type thing)
> I previously attempted to confirm that message settlement has been
> transmitted over the network from a pn_messenger_settle call by checking if
> the delivery tag had been null'ed out on the associated delivery - which
> should happen once pn_real_settle is called.
> However, in someone else's testing this was reported as being unreliable.
> Is
> there something I'm missing, or some alternate way of achieving this?
> --
> View this message in context:
> http://qpid.2158936.n2.nabble.com/Confirming-pn-messenger-settle-settlement-disposition-has-been-transmitted-tp7613952.html
> Sent from the Apache Qpid Proton mailing list archive at Nabble.com.

Reply via email to