Adding a side question. I didn't manage to run multiple instances of the server on my test machine. Do I need multiple hardwares?
Turbofloat server limitations and workaroundsAnswered
Hello! I spent a couple of days reading the documentation and testing Turbofloat. Very early I bumped into the need of handling multiple keys with the same turbofloat server, and I realised I couldn't. An old thread has the answer to that: I have to "clone" the server and having one for each key.
Given this I wanted to elaborate a bit and get your advice for making this work in a typical scenario: the client is buying from me floating licenses for a product, with the validity of 1 year (and I plan to use a key custom field to check that in my app) with me offering various commercial packages with different pool sizes.
The client will run the turbofloat server on their own network. What if they decide to add other licenses after a few months? My alternative are A) I ask the client of handling multiple instances of the server B) I edit the current key and I increase the pool size. But B) unfortunately brings to inconsistent expiration dates, so it sounds it can't be handled like that.
If we stick to the A) option, what could be the strategy if the tf server instances the client needs become slowly three, four, five instances. Should the app use a list of servers to be checked for attempts to request a lease?
What about the possibility for the client of checking the status of the license servers? I didn't find API functions to request information, it looks like I just have the turbofloat server printing to the log and to the standard output (and I can't interrogate with the -x option when it's running).
Do you think is possible to build a neat solution related to these aspects?
Answer
Adding a side question. I didn't manage to run multiple instances of the server on my test machine. Do I need multiple hardwares?
Yes. For the same product version you will need separate pieces of real hardware to run each separate instance.
For different product versions you can run them on the same hardware.
This is by design.
The client will run the turbofloat server on their own network. What if they decide to add other licenses after a few months? My alternative are A) I ask the client of handling multiple instances of the server B) I edit the current key and I increase the pool size.
B is the easiest, obviously.
If we stick to the A) option, what could be the strategy if the tf server instances the client needs become slowly three, four, five instances. Should the app use a list of servers to be checked for attempts to request a lease?
It sounds like a single instance where you pro-rate any date-changes is the best solution. Yes, you can juggle multiple TFS instances, but that sounds like a headache for everyone.
What about the possibility for the client of checking the status of the license servers? I didn't find API functions to request information, it looks like I just have the turbofloat server printing to the log and to the standard output (and I can't interrogate with the -x option when it's running).
Yep, you have to stop it to get the current information. There isn't currently API to query it at runtime (it's coming - no hard date).
Thanks for your reply. With regards to adopting the mentioned solution B) there's still the problem that the expiration date represented by a custom field would be unique for the whole pool.
From a commercial point of view, for the final customer, not all the floating licenses expire at the same time. Client would expect them to expire according to the purchase date of each “package”, and me instead I am forced to bind them all together to a unique license key with a unique value for the custom field.
It seems to me that this floating solution works more like a “client-key”, and it would force me to do a lot of management, changing the pool size all the time and asking the client to re-activate.
Also there's the issue with the client being able to set the check inbetween in the config file to the maximum of 90 days, potentially exposing this solution to be abused (because, again, I can't use the license custom field for the expiration date).
Do you have any plans to overcome these limitations in the future? Because I wouldn't blame the clients for telling me they expect something more standard, compared to other products of the industry (Film and VFX). Or only the creation of an API for the server status is in your roadmap?
Thank you very much.
Lease expiration time from a pool of leases is determined by the TF client and the TFS.
It sounds more like you just want the more typical node-locked licensing (ie TurboActivate).
Wait a minute, I am not talking about lease expiration time. I am talking about an expiration time for the validity of the license that allows me to request the lease. I wrote a detailed scenario above.
A studio buys my product: they want 3 floating licenses, they bought them and they will be valid for 1 year, or 6 months, or whatever. At some point the studio's production increases in volume for that specific task and they decide they need other two licenses, because they want to work with the software on 5 machines at the same time (out of the hundreds they own). So they buy 2 additional licenses, which of course will expire according the purchase date. That's it.
It's quite a common situation. A very big VFX studio has hundreds of machines, they buy dozens of different softwares and they manage their finances on licenses in order to not waste money. Also, employees usually have access to some UI that tells them if licenses for a each software are available, and which machines are holding them. But if a license server has no API the IT dept of the studio can't retrieve the info and include it in their panel.
Hope this clarifies why certain needs arise, at least for this kind of customers.
At some point the studio's production increases in volume for that specific task and they decide they need other two licenses, because they want to work with the software on 5 machines at the same time (out of the hundreds they own). So they buy 2 additional licenses, which of course will expire according the purchase date. That's it.
Ah, OK. Then yes, pro-rating the expiration for those new leases in the pool is the easiest option for everyone (so, it's one renewal date for them, one renewal date for you, one pool of leases, etc.).
You can either pro-rate the cost of the 2 leases for the remainder of he term. Or, pro-rate the existing leases for 1 year from now.
That's the easiest solution. Yes, you can create separate keys with separate TFS instances and separate pools, but that becomes a hassle for everyone to manage. This is really just a billing problem.
Thank you for discussing these alternatives with me.
Please do accept honest feedback about this part of the library: at the moment it is a bit too basic, almost a deal breaker for a person who needs this kind of applications of the floating license formula. If the server could handle multiple keys there will be at least one way of designing the scenario we discussed… but at present, it's a bit of a pain.
And, as a developer/seller, the moment you need to look for other solutions just for the floating licenses you could end with giving up also on the TurboActivate, which is a shame.
We’re definitely improving TFS server soon with more monitoring and hosting options.