The most common licensing provisioning mode is named, which means that for n clients you would provision n tokens. However, the floating (also known as concurrent) licensing model is a viable model used by several software vendors. In a floating scenario, a license with n tokens allows n clients to be active simultaneously. The n+1 client has to wait until a client disconnects in order to use the software.
Floating device licensing is typically found in desktop applications, that do not communicate to a specific application backend.
CREATING A FLOATING DEVICE EDITION
The provisioning mode is an edition (not a product) property. This allows you to offer both named and floating licenses for a specific product. The following parameters are important when creating/editing an edition:
- Provisioning Mode: Floating.
- Client Type: Devices.
- Session Period: Ideally, clients send a session close (disconnect) event when access to the software application is not necessary anymore. This is mandatory in order to make sure that floating tokens become available again, ready to be assigned to other clients. However, especially in desktop applications in which users frequently do not explicitly close the application, such session close events are not sent, resulting in zombie sessions. In order to circumvent this, the session period defines the maximum inactivity period in minutes for a client. If SLASCONE does not receive any event during a session period, it automatically unassigns this token.
MONITORING
In floating license models, it is always interesting to monitor the actual usage, in order to know if more (or even less) floating tokens are required. In this context, each time a client is unable to access the software application because all floating tokens are assigned, this is logged and visualized:
In addition to the log, a chart helps you identify the number of denied sessions over time:
CLIENT/API CONSIDERATIONS
ACTIVATION
Similar to the named provisioning mode, the first step for a floating client is to get activated. Activation takes place once. After initial activation, SLASCONE’s session management takes place.
The activation typically takes place when the user enters the license key, as described here.
Contrary to the named provisioning mode, a floating license code can be used to activate as many devices as possible. In other words, the number of floating tokens has no activation implications.
OPEN SESSION
When starting the software application, your software sends an open session event:
POST /isv/{isv_id}/provisioning/session/open
The API returns one of the following:
- Successful: A floating token has been assigned. The response body also includes the floating token validity (valid until).
- Conflict 1007: The number of allowed connections has been reached. In this case, a session can not be initiated.
EXTEND SESSION
The client needs to regularly send open session events in order to keep the session alive. There are two ways that these can be achieved:
- Static: The session period is hard-coded in the application. In this case you have to make sure that the same session period is configured in the license template.
- Dynamic (recommended): In this case, the session period is not hard-coded in the software application, but depends on the timestamp returned by the first successful open session event. In this way, you have the flexibility to control (and change if necessary) the session period in your license without having to change your code.
CHECKOUT SESSION
SLASCONE enables a session checkout in order to facilitate (partially) offline scenarios, e.g., when a device is on a construction site for some days, with no connectivity.
The request body of the open session event contains an optional checkout_period field (in minutes). This value overrides the default session_period value of the license edition.
{
"license_id": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
"client_id": "string",
"session_id": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
"checkout_period": 0
}
For example, if the open session event contains a checkout_period of 24x60=1440 minutes, the session is valid for 24 hours. During these 24 hours, no extend session event is necessary.
A check in occurs automatically after 24 hours, or if the client sends an explicit close session event.
CLOSE SESSION
As previously mentioned, it is important to explicitly close the session in order to unnecessarily reserve floating tokens, and prevent other clients from accessing the software application.
POST /isv/{isv_id}/provisioning/session/close
HANDLING MULTIPLE SESSIONS FROM THE SAME DEVICE
It is not unusual to have different sessions originating from the same client/device. This can be the result of a user opening multiple independent application sessions on the same device, or different users opening sessions within a server environment.
- For such scenarios, you need to provide a session_id when opening and closing the session. This ensures that each session uses a different floating token.
- If you do not provide a session_id, then a client always occupies one floating token, regardless of the number of parallel sessions.
WHAT TO SAVE IN YOUR CLIENT
Please refer to this article.
CODE EXAMPLES
You can find code examples of floating licenses on our GitHub repository.
Comments
0 comments
Please sign in to leave a comment.