Hi, 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 case.) 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. --Rafael On Mon, Sep 22, 2014 at 12:19 PM, Dominic Evans <dominic.ev...@uk.ibm.com> wrote: > 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. >
