Concurrent Licensing Scheme
-
The customer wants to sell a vb.net app by the 'seat' The application uses SQL. Here's my thoughts: There will be an encrypted key. One of the fields will be # seats. There will be a user logon table, one row for each seat. When the app starts it will stuff it's workstation id in the table, and the TOD. Then every 5 minutes, the app will update the TOD field. When the app quits, the table entry is cleared. If we can't find a blank row, we look at the TOD fields, if none are more than 5 minutes old, then all seats are taken.
-
The customer wants to sell a vb.net app by the 'seat' The application uses SQL. Here's my thoughts: There will be an encrypted key. One of the fields will be # seats. There will be a user logon table, one row for each seat. When the app starts it will stuff it's workstation id in the table, and the TOD. Then every 5 minutes, the app will update the TOD field. When the app quits, the table entry is cleared. If we can't find a blank row, we look at the TOD fields, if none are more than 5 minutes old, then all seats are taken.
Things to consider: - this system would limit the amount of opened clients to the amount of PCs using the app. "Per seat" normally means per user. What if the user would like to open two clients for example to compare a live db with a test copy? Consider including a field for session amount in the table, so a user can open more than one session of the app. (a technique employed by SAP) This allows you to control that users don't simply use the same login for everybody, but will allow a user to open multiple (with a maximum number?) clients on the same machine. - Using the workstation ID, or any other form of registration by PC (IP address, MAC, etc), will cause a lot of frustration among users, because it is very sensitive to problems with firewalls, anti virus programs, network problems, problems with an exchange server in the network, etc, etc. (trust me, this is from personal experience). Using only login IDs and some form of user management will save your customers and therefor you, a lot of grief in the short and long run. No need to predetermine the rows in the table, instead you simply limit the number of users. A user management module will also allow for easier adaptation when a customer wants to purchase additional seats in the future. - the app will quit in unwanted ways (Murphy's Law), due to unexpected errors, power outs, etc. and entries may not get cleared from the table. Consider a way to regularly check whether sessions are still alive. - Using this TOD (Time Of... Death, Departure, Didgeridoo?) the way you describe (ofcourse I may misunderstand you), seems superfluous to me, and I see it creating even more frustration. When a user logs in and the app closes in an unexpected way, the user would have to wait for five minutes before he can restart the app. Hope this is of help to you, Johan
My advice is free, and you may get what you paid for.
-
Things to consider: - this system would limit the amount of opened clients to the amount of PCs using the app. "Per seat" normally means per user. What if the user would like to open two clients for example to compare a live db with a test copy? Consider including a field for session amount in the table, so a user can open more than one session of the app. (a technique employed by SAP) This allows you to control that users don't simply use the same login for everybody, but will allow a user to open multiple (with a maximum number?) clients on the same machine. - Using the workstation ID, or any other form of registration by PC (IP address, MAC, etc), will cause a lot of frustration among users, because it is very sensitive to problems with firewalls, anti virus programs, network problems, problems with an exchange server in the network, etc, etc. (trust me, this is from personal experience). Using only login IDs and some form of user management will save your customers and therefor you, a lot of grief in the short and long run. No need to predetermine the rows in the table, instead you simply limit the number of users. A user management module will also allow for easier adaptation when a customer wants to purchase additional seats in the future. - the app will quit in unwanted ways (Murphy's Law), due to unexpected errors, power outs, etc. and entries may not get cleared from the table. Consider a way to regularly check whether sessions are still alive. - Using this TOD (Time Of... Death, Departure, Didgeridoo?) the way you describe (ofcourse I may misunderstand you), seems superfluous to me, and I see it creating even more frustration. When a user logs in and the app closes in an unexpected way, the user would have to wait for five minutes before he can restart the app. Hope this is of help to you, Johan
My advice is free, and you may get what you paid for.
Thanks for the response. I am thinking along simple lines that the number of rows in the table limits the number of concurrent users. I was planning on using the computer name (that you can easily get in .net) + user_name as the key, for a row in the license table, thus, a user could have as many instances open, but just use one license. The one issue I have is when an app aborts without clearing it's license record. This is why I was thinking of having the app update it's license record every so many minutes, with the TOD. My logon logic could determine which records were 'stale' and zero them out. What do you think?