Open topic with navigation
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.
To better understand Cloud-Controlled Floating Network Licensing using SOLO Server, you first need to understand several key terms:
When using Cloud-Controlled Floating Network 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...
Applications that use Cloud-Controlled Floating Network 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.
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.
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.
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.
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.
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).
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.
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: