Network Floating Licensing is where an application may be restricted to running on a specific network, and restricted to a certain number of concurrent seats (where a seat may be a user or running instance of your application). This topic guides you through some basics of getting started with using Cloud-Controlled Network Floating Licensing using SOLO Server. This feature has some limitations, so it is very important to review the overview of network floating before using it.
If you wish to use Cloud-Controlled Network Floating Licensing using SOLO Server, you will need to contact us for additional details on availability and pricing.
As is characteristic of PLUSNative, the first step is to initialize an API context. Only one network session may be opened at a time for each API context initialized. In other words, if you have a single application that needs to manage separate sessions to limit concurrent use of individual modules/features separately, each one will require its own API context.
Note that, due to operating system API limitations, the Cloud-Controlled Network Floating Licensing using SOLO Server can only limit use of a session certificate file to 1 process in Windows platforms.
Opening a session is synonymous with attempting to allocate a seat, which is only allowed to occur if the seats are not already consumed by other users and/or application instances. A rough example of the contents of a function that opens a session is shown below.
The code excerpt above has 3 primary steps needed to open the session, and exhibits the same pattern needed to perform other actions with a session.
To avoid making this topic excessively long, the additional steps will be summarized like the list above, without also providing example code here. Of course, you can always reference the PLUSNative samples to get complete, functioning code that you can re-use in your applications.
Upon opening a session, you receive a network session certificate, which contains data about the session and how the protected application should behave. For example, it contains the date and time the session expires, whether or not it has been checked-out, how long it should wait between poll attempts, and more. Expanding on the example above, here is an example of how you can get the Session ID from the certificate:
Once a session is open, and immediately after any action (other than closing the session) is performed, it is necessary to validate the session. The PLUSNative API automatically does this for you any time you call any of the SK_PLUS_NetworkSession* functions (though this does not apply to SK_PLUS_NetworkSessionClose). The automatic validation does the following:
Note that it is important to close the session rather than abandoning it when validation fails. This is because the session should not be allowed to be used when invalid, and if the session remains open on SOLO Server even though local validation has failed, abandoning it will cause SOLO Server to consider the seat to be valid until the allocated until date (or the date and time the session is set to expire if it has not polled successfully before then).
When a session is open, it is set to expire by its "allocated until date." In other words, if no poll occurs before the date and time shown in the "allocated until date" is reached, the session is considered expired by SOLO Server. Successfully polling the session with SOLO Server automatically extends the allocated until date, which is what allows SOLO Server to recover orphaned sessions/seats (which is helpful for handling abnormal application termination).
If a session has been checked-out for extended/offline use, you may still poll to verify the session if Internet connectivity is available. However, the "allocated until date" is not automatically extended for a checked-out session.
In some cases, you may find the need to allow users to check-out a session/seat for offline and/or extended use. An example could be a user who needs to use the protected application while traveling. To allow this, you can allow the user to check-out a session for a requested duration. When successful, SOLO Server will respond with an updated session certificate that has an allocated until date that is valid for the requested duration (or until the minimum or maximum check-out duration allowed if the requested duration is outside of those bounds). Follow the steps below to check-out a session:
Once checked-out, your application may continue to poll when Internet connectivity is available (just keep in mind that attempting to poll while offline could cause performance degradation). The seat will then be consumed until the allocated until date is reached, or the user checks-in and closes the session. So in the example of a traveling user, you might allow the user to check-out for up to a week, even though the user is only expected to travel for 3 to 4 days. This allows the user to continue to use the application in a disconnected state should unforeseen circumstances (such as inclement weather) arise. If the user returns when expected, he or she could then check-in the session and return to normal connected use so the seat becomes available for other users when not in use. Follow the steps below to check-in a session that was previously checked-out:
When your user finishes using the application or feature being licensed, you should close the session to make the seat available to other users. Follow the steps below to close a session:
When you're done using the PLUSNative for managing a network session you should also call the SK_PLUS_NetworkSessionDispose function. This function is automatically called for you when calling SK_ApiContextDispose, which needs to be called when you are done with the API context (such as when the application is being closed).
The example code excerpts given above are only meant to provide guidance on how the APIs should be used. Review the PLUSNative samples to see complete, functioning example code that can be re-used in your applications.