Could you pls. consider to support installation of multiple LexFloatServer instances on the same machine (with different port numbers) with the same version GUID but different product keys like following:
LexFloatServer.exe -a -config=LexFloat1.config -pfile=Product.dat -pkey=(first license key)
LexFloatServer.exe -a -config=LexFloat2.config -pfile=Product.dat -pkey=(second license key)
LexFloatServer.exe -a -config=LexFloat3.config -pfile=Product.dat -pkey=(third license key)
The need for this is that we use custom fields to activate/deactivate specific features in our product and also we need to limit number of concurrent users on feature basis.
Using different product versions is not an option for us - there are too many feature combinations, and for each combination we’ll have to create a product version and a separate build with corresponding product.dat and version guid embedded… This is just unmanageable,
I understand that currently there is a limitation for one product key per version per machine, but I see no reason for this in case of LexFloatServer.
We’re going to provide a user with a set of product keys for one product version with different features activated. We use custom fields to provide information on what features are activated in a version. Then our client will have to install a dedicated instance of LexFloatServer per each product key on separate server, which is very inconvenient and rather costly solution.
Am I missing something? Do you have a better solution for this case?
As I said previously - we have to many features (say, 10) and each of them should be licensed independently on per client basis. This gives unmanageable count (1024) of versions required.
It is technically feasible to support your use case in LexFloatserver, would require some major changes. Most probably we will expose a switch for that during activation.
The technical effort in implementing your use case, actually turned out to be very high. It would require lot of breaking changes in the API and the usage also.
You will have to take a mixed route of multiple versions and custom fields to decrease the number of total versions in your case.
We would also like to be able to run multiple floating licence servers on the same machine on different ports for the same GUID.
The use case is:
Multiple organisations will have their own floating licence pools on their allocated ports.
We want to provide the service from our server machine rather then let them play with it.
We also don’t want to complicate everything with creating a product version for each client and having to somehow deliver .dat files over to all client machines (as these would not be standard .dat files distributed with a public installer).
We are planning to offer hosting floating server wherein Cryptlex would act as an floating server, does that solve your issue. It won’t be onpremise though.
Do you mean that the difference to the current process would be that the server address and port would be somewhere on your side (e.g. floating.cryptlex.com:3121), and you would start up the server instance automatically (or provide an option for web API to) when a floating licence is created?
I think this scenario would work for us if we could also access server stats over https or something.
Do you have any rought ETA on this?
Actually it will work like normal LexActivator activations. You use lexactivator to ActivateLicense() and then it automatically keeps on refreshing the license by invoking Cryptlex Web Api, if it doesn’t renew the license, the activation slot will be automatically cleared up on the server. The activation log will be available in the dashboard. You can add ip restriction to prevent the usage of license key.
Oh right, so this sounds like deprecating LexFloat methods in favour of just using the LexActivator.
In terms of Java implementation, does this mean we would get rid of LexFloatClient.java? How would the licence refresh failure be handled? Currently we bind AddLicenseCallbackListener.
