Equivalent of Flex’s DUP_GROUP=UHD

We rely heavily on DUP_GROUP=UHD in our Flex licenses. The setting is applied to individual features. With this setting, when the same user on the same machine asks for multiple checkouts of the feature, the license server only makes the first checkout and somehow internally counts all the additional ones. When the user makes the last of all the check-ins, the server checks in the feature.

In Cryptlex we are using meter attributes for the licensed features and the allowed uses are the seat counts. So we would want something like a per-instance/per-machine/per-user switch on meter attributes. If the meter attribute is not set to per-instance, the server would need to check the machine/user (I’m hoping this info is in the fingerprint) and if there is already an active increment for this machine/user it would reference count it rather than make another increment. Decrements would have to do the reverse, decreasing any reference count before finally decrementing the meter.

Is something like this possible?

Hi Gary,

Can you explain this using an example?

We sell a single license that enables a collection of features that covers our entire suite of applications. So let’s say a customer has bought 6 seats of a particular product containing solver feature X and GUI feature Y. Their license has 6 seats of X and 6 seats of Y. Feature X is marked DUP_GROUP=NONE because it is a solver feature, and feature Y is marked DUP_GROUP=UHD because it is a GUI feature.

If 6 solvers are already running and using feature X, then a seventh solver that wants feature X will unconditionally fail with a “no more licenses” error.

If 6 different users are already running GUIs using feature Y, then a seventh user wanting feature Y will get a “no more licenses” error. But if one of the 6 existing users wants to start a second GUI using feature Y on the same machine, DUP_GROUP=UHD means that a second checkout for this user on this machine is not necessary and the second GUI instance will run without error.

So DUP_GROUP=NONE is equivalent to the Cryptlex per-instance model, except it is applied per feature (ie would apply to incrementing meter attributes in Cryptlex rather than activation). DUP_GROUP=UHD is similar to applying the per-machine model to meter increments except that it uses the user+machine combination and not just the machine.

Does this help?

Hi Gary,

If you have enabled per-machine leasing startegy, you can use GetActivationMeterAttributeUses() function to know whether the user has already consumed the meter attribute usage or not. If it reports 1 then the machine has already consumed the count and you can allow the second instance to run without incrementing the meter attribute.

Essentially in the case of a per-machine leasing strategy, multiple instances on the same machine can share the same activation.

We are using per-instance leasing. We are asking whether it is possible to have a hybrid of per-instance activation and per-(user+machine) meter incrementing.

Perhaps we need to revisit per-machine leasing, but if you remember we had some performance issues with the local activation cache when we had lots of short-running processes running nearly simultaneously on a single machine.

It won’t be easy to support this combination. I would recommend using some inter-process communication mechanism between multiple instances on the same machine to know if another instance is running and has acquired the license along with the feature.

I understand.

I think we’re more likely to look at per-machine activation before we consider writing yet more custom code.

Thanks,
Gary