Example Scenarios of the Basic Process for Granting Licenses
The following scenarios illustrate instances of the basic process (described in the previous section) that the license server uses to grant licenses when reservations are involved. The sections describing the scenarios in include the following:
For the sake of simplicity, the feature version is omitted in these scenarios. Anytime feature F1 is mentioned, assume that its version is 1.0.
Feature Allocation on the License Server
The license server has 10 counts of feature F1:
|
•
|
3 reserved counts for device D1 |
|
•
|
2 reserved counts for user U1 |
|
•
|
5 shared counts available |
Starting State for Each Scenario
The starting state for each scenario is a follows:
|
•
|
Device D1 has been served 4 counts (all 3 reserved counts, 1 shared count). |
|
•
|
Device D2 has been served 3 counts (3 shared counts). |
|
•
|
User U1 currently has no served counts. |
|
•
|
1 shared count remains available. |
Scenario 1—No Device or User Reservations Available
When user U7 (who has no reservations) sends a capability request from device D2 (which also has no reservations), the 3 counts of F1 currently served to D2 are returned to the shared counts. (Four shared counts are now available.)
The following describes possible scenarios of what happens next:
|
•
|
If the request has no desired features, no counts are served since neither D2 nor U7 has reserved counts. |
|
•
|
If the request specifies 4 counts of F1, the remaining 4 available shared counts are served. |
|
•
|
If the request specifies 5 counts of F1, no counts of F1 are sent in the response since only 4 shared counts are available. |
Scenario 2—Device Reservations But No User Reservations Available
When user U7 (who has no reservations) sends a capability request from device D1, the 4 counts of F1 currently served to D1 (3 reserved counts for D1 and 1 shared count) are returned. (Two shared counts are now available.)
The following describes possible scenarios of what happens next:
|
•
|
If the request has no desired features, the 3 counts of F1 reserved for D1 are served. |
|
•
|
If the request specifies 4 counts of F1, the 3 counts reserved for D1 plus 1 shared count are served. |
|
•
|
If the request specifies 6 counts of F1, the 3 counts reserved for D1 and the remaining 2 shared counts are insufficient to fulfill the request, so no counts of F1 are sent in the response. |
Scenario 3—User Reservations But No Device Reservations Available
If user U1 sends a capability request from device D2 (which has no reservations), the 3 counts of F1 currently served to D2 are returned to shared counts. (Four shared counts are now available.)
The following describes possible scenarios of what happens next:
|
•
|
If the request has no desired features, the 2 counts of F1 reserved for U1 are served. |
|
•
|
If the request specifies 4 counts of F1, the 2 counts reserved for U1 plus 2 shared counts are served. |
|
•
|
If the request specifies 7 counts of F1, the two counts reserved for U1 and the remaining 4 shared counts are not sufficient to fulfill the request, so no counts of F1 are sent in the response. |
Scenario 4—Device and User Reservations Available
If user U1 sends a capability request from device D1, the 4 counts of F1 currently served to D1 (3 reserved and 1 shared) are returned. (Two shared counts are now available.)
The following describes possible scenarios of what happens next:
|
•
|
If the request has no desired features, all reserved features—3 counts of F1 for D1 and 2 counts for U1—are served. |
|
•
|
If the requests specifies 4 counts of F1, the 3 counts reserved for D1 and 1 of the 2 counts reserved for U1 are served. |
|
•
|
If the request specifies 8 counts of F1, the 3 counts reserved for D1, the 2 counts reserved for U1, and the 2 remaining shared counts are not sufficient to fulfill the request, so no counts are sent in the response. |