Cloud-Controlled Network Floating Licensing using SOLO Server

In cases where it is not practical or feasible to use semaphore files (such as for high-load and/or WAN environments), it is also possible to use SOLO Server to enforce concurrent seat limitations. In this case, SOLO Server web services are used to manage the state of each "session." These web services may also be used to automate authorization of "check-outs" for temporary, off-line use of the licensed application. To evaluate this feature, you may use the Cloud-Controlled Network Floating Licensing sample applications with the SOLO Server test author account. If you would like to use this functionality with your SOLO Server account please contact us.

Please read our Controlling Concurrent User Access with Network Floating Licensing blog post for great high level information.

Understanding Cloud-Controlled Network Floating Licensing using SOLO Server

Key Terms

To better understand Cloud-Controlled Network Floating Licensing using SOLO Server, you first need to understand several key terms:

Session: A network session represents a seat that is in use, and one session is typically created for each instance of the application being run.
Session ID: An alphanumeric value used to uniquely identify a given session.
Seat: A seat is simply a network session which may be created. In this sense, if you were to allow a maximum of 10 concurrent network sessions for a given license, you might rephrase that as a "10-seat network license." In this example, when 10 seats in total are allowed, and 7 sessions are active, only 3 seats would still be available (corresponding with the ability to create only 3 additional sessions).
Orphaned Session: This is a session which has not been closed, but has expired and is no longer valid. This could be the result of not performing a session close action, or from the licensed application terminating abnormally.
UTC: UTC stands for Universal Time, Coordinated. With UTC, the date and time is always the same regardless of what time-zone you are physically located in, or whether or not any kind of daylight saving time is in effect in your time-zone. SOLO Server and the Protection PLUS 5 SDK APIs use UTC for all of the dates and times used for managing network sessions; however, the sample applications will translate and display the Allocated Until Date to you in your local system time. In layman terms, time in UTC is the same as Greenwich Mean Time (GMT). More information about UTC is available at http://en.wikipedia.org/wiki/UTC.
Allocated Date: The date and time (in UTC) in which the network session was opened.
Allocated Until Date: The date and time (in UTC) in which a network session is no longer valid. This date is extended when the licensed application performs a poll. The date is also determined by the configurable parameters defined later, and is calculated by SOLO Server as follows:
Allocated Until Date = (Current Date and Time) + ((Poll Frequency) + (Poll Retry Count * Poll Retry Frequency)).
When a session is checked out for a given duration, the Allocated Until Date is then set to the (Current Date and Time) + (the specified duration).
Session Certificate File: When a network session has been checked-out for offline use, the information returned by SOLO Server comes back in a format that is designed to be used as a certificate file. This file may then be saved to the local computer’s file system so it may be used later to restore the checked-out session.

Configurable Parameters

When using Cloud-Controlled Network Floating Licensing using SOLO Server, there are a variety of parameters that can be configured in SOLO Server to control how protected applications behave. The benefit of configuring these options in SOLO Server is that it enables you to make adjustments on the fly, as your applications can pull the new settings down the next time they open or poll a session. This means you can respond to time limits being too restricted or to relaxed, or respond to heavy load by adjusting poll and retry frequency, etc...

Poll Frequency: This is the frequency, in seconds, in which the licensed application should poll against SOLO Server.
Poll Retry Count: If a poll fails for any reason, this is the number of times the licensed application should try polling again.
Poll Retry Frequency: If a poll fails for any reason, this is the amount of time that should pass, in seconds, between attempts to retry the poll.
Allow Temporary Overages: If enabled, this will allow temporary overages to occur within the set maximum overage period. An example scenario of where this could be useful could include a user shutting the lid on a laptop before heading out to lunch, which causes the computer to suspend or hibernate. In this state, the computer is unable to perform any polls to keep the session active. When the user lifts the lid on the laptop and returns to its normal, running state, the session would no longer be active, and this could result in the user being locked out of the application if other users have since consumed all available seats. By allowing temporary overages, this will allow the user to resume a session which has since expired within the allowed overage period; however, this would result in the possibility of more seats being used than licensed temporarily. No new sessions may be open until enough active sessions have closed or expired to fall back under the seats allowed.
Maximum Overage Period: Please refer to the description of Allow Temporary Overages above. This is the time, in seconds, in which a session is allowed to be expired before polling again to resume its session, even if it means an overage will occur.
Checkout Duration Minimum: The minimum amount of time, in hours, which may be requested for a session checkout request.
Checkout Duration Maximum: The maximum amount of time, in hours, which may be requested for a session checkout request.

How it Works

Applications that use Cloud-Controlled Network Floating Licensing using SOLO Server will perform a series of actions in order to create and manage concurrent sessions. A typical application work-flow is shown below:

As you can see in the flow chart above, session validation is meant to occur after every type of action occurs, so this is a very important piece to consider. While the Protection PLUS 5 SDK APIs simplify validation, below is an illustration of how the validation works.

Actions

As described in the section immediately above, a variety of actions are performed to create and manage a concurrent network session. The actions that are supported by the Protection PLUS 5 SDK APIs are described and illustrated in detail below.

Open

This opens/begins a new network session, resulting in a new, unique Session ID being issued if a seat is still available. When a new network session is opened, it is only valid until its next poll is required.

Poll

A poll is where the software checks the status of the current session with SOLO Server. This action prompts SOLO Server to extend the Allocated Until Date until the next poll is required.

Check-out

If a user needs to use the application in a disconnected state for some time, the user may request a checkout for that duration of time. During the time in which a session has been checked-out, it will consume a seat for the entire checkout duration or until it has been checked-in. It is possible to poll against a checked-out session, but in this scenario, a poll will not extend the session’s Allocated Until Date. The availability of this feature will be at the software author’s discretion, as would the minimum and maximum checkout durations allowed. Checking-out a session results in a certificate file being created, which allows you to resume a session after exiting and running the application again later. When resuming, the application must load the certificate file from the same path in which it was created. The protected application can also lock the session file when running to prevent other instances of the application from also using it on the same computer.

Check-in

When a network session is checked out, its seat is consumed for the full duration of the checkout period unless it is checked-in. After being checked-in, a session may resume its normal polling to remain active. The availability is at the software author’s discretion, and it is important to note that this feature should be used with caution. Caution is necessary because it is possible for a user to make a backup of the session certificate file, perform the check-in, disconnect, and then restore the session certificate file to resume offline use of the application without consuming a seat as it should. The only means of preventing the user from doing this is to either require the application to poll at least once when restoring a certificate file (usually during application start-up) to verify that the checked-out session is still valid, or to simply not make the check-in feature available to your users. If you decide this feature is necessary, you should take additional measures in your application to prevent users from restoring session certificate files recently checked-in sessions (i.e. you could store these recently checked-in Session IDs in a hidden, encrypted file or registry key).

Close

When a user is done working with a given network session, and the application is being closed, the network session should be closed. Closing a network session makes the current session invalid, and frees the seat the active session consumed so a new session may be opened later.

Working with Cloud-Controlled Network Floating Licensing using SOLO Server

After adding a license in SOLO Server, you can edit the license details to customize additional settings. When editing these details, you can change the number of network seats a given license may allocate by modifying the License Counter value.

For more information on implementing Cloud-Controlled Network Floating Licensing with either PLUSManaged or PLUSNative, view one of these manual topics: