Floating Licensing Software - Need Sugggestions

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • Maidenz08
    New Member
    • Sep 2007
    • 31

    Floating Licensing Software - Need Sugggestions

    I am trying to build a client server floating licensing software. The methodology im following is as follows.

    1. There are two daemons running. One is on the client and the other is on the server.

    2. When the user installs the client he points to the IP address of the licensing server. The product key is a combination of the Server Mac Id and number of Floating licenses that the user has bought and the expiry date of the software which is encrypted.

    3.The server and the client talk to each other using a designated port. So as soon as the application is opened, the app writes a log file in a particular path which is encrypted with the current date time.

    4. The Client daemon passes this info to the server to check if the licenses are available. If the licenses are available the server grants one license. The server maintains the number of licenses available in the pool in a text file which again in encrypted.

    5. When the user closes the app it again writes a log in the file which is watched by the client daemon and that particular license is released into the free pool.

    I do not have any technical difficulties in archiving the same. But i want to know if the approach im taking to design the tool is right.

    Am i missing something here. Suggestions are welcome

    Regards,

    Alvin
  • IanWright
    New Member
    • Jan 2008
    • 179

    #2
    Originally posted by Maidenz08
    I am trying to build a client server floating licensing software. The methodology im following is as follows.

    1. There are two daemons running. One is on the client and the other is on the server.

    2. When the user installs the client he points to the IP address of the licensing server. The product key is a combination of the Server Mac Id and number of Floating licenses that the user has bought and the expiry date of the software which is encrypted.

    3.The server and the client talk to each other using a designated port. So as soon as the application is opened, the app writes a log file in a particular path which is encrypted with the current date time.

    4. The Client daemon passes this info to the server to check if the licenses are available. If the licenses are available the server grants one license. The server maintains the number of licenses available in the pool in a text file which again in encrypted.

    5. When the user closes the app it again writes a log in the file which is watched by the client daemon and that particular license is released into the free pool.

    I do not have any technical difficulties in archiving the same. But i want to know if the approach im taking to design the tool is right.

    Am i missing something here. Suggestions are welcome

    Regards,

    Alvin
    Few things to consider:

    1) What happens if the server changes MAC address?
    2) What happens if the client can't connect to the server?
    3) What if the times are out of sync (by a few seconds, or a number of days)?
    4) What if they try to avoid expiry by shifting the date considerably?
    5) Ensure that the server file is threadsafe... Otherwise you may fail reading/writing the file or even corrupt it making it difficult to know it's current state again when you restart.

    Comment

    • Maidenz08
      New Member
      • Sep 2007
      • 31

      #3
      Originally posted by IanWright
      Few things to consider:

      1) What happens if the server changes MAC address?
      I will have a configuration wizard where they can change the License server on the clients. And they would have to request for a new license key in case they change a server. Coz i'd guess that they wouldnt keep changing the server frequently. Any better way to do it? I have to restrict the access of the app within the Lan.

      Originally posted by IanWright
      2) What happens if the client can't connect to the server?
      Then the app would not work. Isnt that how client server licensing works?

      Originally posted by IanWright
      3) What if the times are out of sync (by a few seconds, or a number of days)?
      All i was trying to do here is raise an event by the app requesting for a license. So Datetime wouldnt be important here.

      Originally posted by IanWright
      4) What if they try to avoid expiry by shifting the date considerably?
      Good that you brought it up. Kindly suggest a way to handle it.

      Comment

      • IanWright
        New Member
        • Jan 2008
        • 179

        #4
        1) They shouldn't do it too often, but if they need zero downtime you need to be aware that it should be easily switchable. Restricting access to within a LAN. That brings some understanding to some of your other questions that you were asking before... To do that you may want to see if CAS etc is applicable to disable net connections from your app.

        2) Yes, but you need a backup in case...

        4) I don't know as yet. I have a similar problem to tackle in the coming months.

        Originally posted by Maidenz08
        I will have a configuration wizard where they can change the License server on the clients. And they would have to request for a new license key in case they change a server. Coz i'd guess that they wouldnt keep changing the server frequently. Any better way to do it? I have to restrict the access of the app within the Lan.



        Then the app would not work. Isnt that how client server licensing works?



        All i was trying to do here is raise an event by the app requesting for a license. So Datetime wouldnt be important here.



        Good that you brought it up. Kindly suggest a way to handle it.

        Comment

        • Curtis Rutland
          Recognized Expert Specialist
          • Apr 2008
          • 3264

          #5
          As to point number 4, I would suggest some way for the client to request the current date/time from the server, and then compare. If the times are greatly apart, have the software refuse to function until the date is set correctly.

          Comment

          Working...