Preventing the turbofloat client to keep renewing the lease forever.Answered
Hello! Today I have quite an unusual question.
I sell my software to clients who have multi-site organizations, with offices in different timezones. It happens that users leave their software open (the main software, SideFx Houdini, for which I developed a plug-in which is authorized using turbofloat) and the license lease keeps being renewed for several hours without any actual need. The employee is not present and another employee on the other side of the world can't get their license.
If the automatic renewal was triggering a callback I could handle this myself, but unfortunately this basic behaviour of turbofloat doesn't.
The client is running the turbofloat server in their network and asked me if there's a way of declining an existing lease.
What are your suggestions? At the moment the best solution I found is to close the turbofloat server, and wait for the lease timeout. When the lease expires the client process triggers the callback with the TF_CB_LEASE_DROPPED status and then, when the server will restart, it won't ask for a license lease anymore without human intervention.
Can I do better?
Thanks!
Ultimately this is a user-behavior issue. By default, (for years now), if your software has a lease, and the machine goes to sleep, your software will drop the lease before the machine goes to sleep. You don't have to do anything, TurboFloat just handles it.
So, if you're using the latest version of TurboFloat, and the customer has their machine configured correctly (to save their own energy bills and increase the life of their computers) then it will go to sleep after idling for anywhere from 15 minutes to a half hour.
You could, of course, also handle this inside your app (drop the lease after idling for X minutes), but this is a configuration issue on the customers side. Just reproducing a per-process “sleep” algorithm is wasteful. Their whole machine should be going to sleep.
They should fix their issue so they'll save money (and also, incidentally, solve the problem). It's also a more secure option (less chance of intrusions happening, and less chance of the machine being used in a botnet).
Short answer: yes, you can handle this in your code, but you shouldn't. They should fix their config.
Make sense?