Handling Inconsistencies Sample Clauses

Handling Inconsistencies. As described in Section 2, this protocol relaxes the requirement for consistency of the contract state across the customer and resource provider. In doing so we gain the availability of resources for booking as they are never in a state between ‘not- booked’ and ‘booked’, unlike in a protocol based on a transactional approach in which resources need to be reserved until a transaction completes or aborts. This section describes how inconsistencies between the customer and provider are han- dled through the protocol, illustrated through two example message exchanges.

Handling Inconsistencies. As described in Section 2, this protocol relaxes the requirement for consistency of the contract state across the customer and resource provider. In doing so we gain the availability of resources for booking as they are never in a state between ‘not- booked’ and ‘booked’, unlike in a protocol based on a transactional approach in which resources need to be reserved until a transaction completes or aborts. This section describes how inconsistencies between the customer and provider are han- dled through the protocol, illustrated through two example message exchanges. Example 1 With both the customer and the resource provider in the contracted state, the customer sends a RenegotiationOffer offer with identifier A to the provider and moves to the renegotiating state. Unfortunately, this message is lost on the network, thus the two parties have inconsistent states. This scenario is shown in Figure 2. Upon not receiving a reply to their RenegotiationOffer, the customer may keep resending the same message until they receive a response from the resource provider. Resending a RenegotiationOffer is not a problem as it can only be ac- cepted or rejected once. Thus, the customer can be confident that they will not be contracted multiple times. In Figure 2, the provider returns a RenegotiationAccept with an identifier B and a correlation identifier A to indicate which offer is being accepted. Following the receipt of the RenegotiationAccept the customer will be in the same state as the provider when the provider sent the xxxxxxxx0. Example 2 Figure 3 shows the customer and the provider in the renegotiating state after the customer sends RenegotiationOffer with identifier Y. The provider sends a RenegotiationAccept with identifier Z and correlation identifier Y in re- sponse. The accept message is lost and the customer and the resource provider are in inconsistent states. As in Example 1, the customer may keep resending the RenegotiationOffer until it receives a response.