Server Behavior when Assigning Features to Clients

When the license server receives a capability request from a client, it tries to serve the feature counts matching the requested version from the first partition that is configured in the model definition. If the request cannot be fulfilled from the first partition, or can only be partially fulfilled, the server will try to serve any remaining counts to the client from further feature slices and partitions in a specific hierarchy. The following rules apply, in order, when fulfilling capability requests:

1.

Regular counts take priority over overdraft counts (overdraft counts are only available from the default partition).

2.

Counts are served from accessible partitions in the order partitions are specified in the model definition (starting from the top).

3.

Counts that match the requested version are served before counts of a higher version (lower versions are not accepted).

4.

Counts with the shorter expiry date are served before counts with a later expiry date.

The following diagrams illustrate this hierarchy. The following diagram shows the order in which feature counts are assigned from partitions.

Flow of feature allocation

The diagram above includes a subroutine (highlighted in green) that explains how counts are assigned if the request is served from more than one slice. This subroutine—see the following diagram—also comes into play when regular (non-overdraft) counts are exhausted, but the request has access to the default partition which includes overdraft counts:

Flow of feature allocation in the subroutine