Open topic with navigation
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.
Note that the Cloud-Controlled Network Floating Licensing using SOLO Server is only supported in Windows platforms. See the overview of network floating for additional details.
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.
To begin, use/import the necessary namespaces to your relevant source file(s). This is typically added to your application's primary form, or where your primary application start-up logic is located.
Next, you'll need to add a member variable for the network session, and some static configuration properties.
Note that the samples include encryption envelopes that are linked to the Instant SOLO Server test account. You can either use the test credentials, or you can retrieve the encryption key data for your account, even if you are currently evaluating Instant SOLO Server.
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.
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. In the example above, the data is available in properties under the _Session.Certificate property.
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 example below shows how you can use the NetworkSessionValidation class, which is included with PLUSManaged to simplify the validation process.
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).
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.
Once the session has been checked-in, it may resume normal connected use with periodic polls. Otherwise, the session should be closed if the session is no longer being used actively.
A session should be closed any time it is no longer being used by the user, or any time it fails local validation. This helps ensure it the seat that was previously in use becomes free for other users to open and use.
The example code excerpts given above are only meant to provide guidance on how the APIs should be used. Review the PLUSManaged samples to see complete, functioning example code that can be re-used in your applications.