A provider engages in long-running conversations with multiple partners. Each of these conversations requires the provider to allocate resources.
How can a service provider avoid holding resources for clients who are no longer interested?
- Loose coupling includes resource management. Holding resources at another participant's convenience introduces a form of coupling.
- Resources can take many forms such as sessions and the related memory allocations, database records, authentication tokens and the like.
- Service consumers may voluntarily or involuntarily terminate a conversation without notifying the service provider. For example, a connection may drop. This can lead to orphaned resources that can hinder system performance or require costly machine resources. Ultimately, the provider may run out of resources.
- A provider may not be able to contact consumers to check whether they are still active and reachable. This could for exampel be the case because the consumers are not able to receive inbound connections as it is common with Web clients.
- A service provider may want to gauge how long it is willing to hold resources for a consumer, depending on its current resource usage. If the provider is nearly running out of resources it may not be willing to hold new resources for a long amount of time.
- Unused resources could be detected periodically in a sort of "garbage collection", but in a distributed systems the collection process may not be clear as to which resources are unused because the state of remote participants may be unknown.
- The resource to be allocated may be part of a limited pool that has to be shared across all requestors.
Have the service provider issue a Lease to the resources. If not renewed, the lease will expire, allowing the provider to free allocated resources.
The Lease conversation involves the following participants:
- The Requestor issues a Request for a resource. In return it receives a Lease, which typically indicates a time interval for which the lease is valid. The Lease also contains a reference to the resource being held. In order to retain the resource it must Renew the lease within the specified interval. The Request message may contain attributes that help the Provider decide on the lease terms.
- The Provider accepts Request messages for resources and grants them if resources are available, sharing the lease terms in a Lease message to the Requestor. The Provider associates a timer with each granted resource and expires the resource if no Renew message is received within the set time interval. The Provider also accepts Renew messages, which it acknowledges with a Lease message.
Using a Lease the lease holder is always certain about the state of the resource. For example, if a Renew request fails (e.g. because the lease grantor is unreachable), the lease holder knows that the grantor will relinquish the lease. This conversation puts the burden for lease renewal on the lease holder.
A Renew message usually results in a new lease being issued and a new Lease message being sent. The conversation contract could also specify that the existing lease is renewed on the same terms as before, but an explicit Lease message simplifies the design of the Requestor and reduces coupling in the protocol as each interchange transmits the complete state. It also allows the Provider to re-adjust the lease duration, e.g. it can shorten the lease because it is short on resources.
The Requestor of the service is also referred to as the "holder" of the lease while the service is called the "grantor". The lease holder can actively cancel the lease before it is up to help the grantor release resources.
The lease holder can apply for a new lease before the existing one runs out.
The lease grantor can deny a Renew request. The Requestor may therefore be prepared to lose access to the resource. Whether such a denial is allowed should be specified in the conversation protocol as it places additional requirements on the Requestor.
Requestors may become over-eager in renewing leases, causing unnecessary network traffic and a potential strain on the Provider.
Lease relies on a shared clock between requestor and provider. In reality distributed systems are likely to use clocks that are slightly our of sync. If Lease durations are long, e.g. hours or days this likely does not matter. To be safe, the provider could add some extra "slack" after lease expiration before it actually de-allocates the resource.
See also: [POSA3].
Example: DHCP
The Dynamic Host Configuration protocol (DHCP) assigns IP addresses from a pool to requesting machines as a Lease. Machines have to renew their assigned IP address before the Lease expires. Otherwise, the server may reclaim it and assign it to a different machine. In many cases, clients receive the same address after renewal, but this is not guaranteed.
