Patent Application
20060020553
License servers are used to manage licenses that enable or enhance capabilities of applications. The licenses issued by a license server may comprise “node lock” licenses that are issued to a single machine, or “floating” licenses, which are not machine specific. As shown in
To maintain compliance with licensing agreements, the license server 110 may track the number of licenses it issues. However, if the license server 110 fails, it may lose its knowledge of issued licenses and, upon restart, its entire quantity of licenses may once again be made available. If one or more applications obtained licenses before the license server failure, and the license server reissues these licenses to additional applications after it is restarted, license over-usage becomes possible.
In order to prevent license over-usage, the applications 102, 104, 106 may send heartbeats to the license server 110 at predetermined time intervals. If the license server 110 fails, the applications 102, 104, 106 will not receive acknowledgements of their heartbeats, and appropriate action(s) can be taken.
For circuit test applications that rely on licenses provided by a FLEXIm™ license server (a license server offered by Macrovision Corporation, a Delaware Corporation having its principal place of business in Santa Clara, Calif., USA), the heartbeats provided by the circuit test applications may be executed within a few milliseconds. However, if a circuit test application is executing tests within nanoseconds, or even picoseconds, a few milliseconds is a long time, and the application's need to execute heartbeats can degrade the application's performance. If several processes within a circuit test application all need to obtain licenses and provide heartbeats, the overhead for maintaining the application's licenses can become quite significant. Similar performance degradation is also suffered by other multi-process applications. In the past, programmers have merely suffered the performance “hit” of heartbeat execution; or, programmers have circumvented or disabled an application's need to provide heartbeats. In the latter case, a user of the application may fail to comply with their license requirements.
In one embodiment, a license proxy process transmits to a license server a request for a license that is to be shared by a plurality of applications. After the license proxy process receives the license from the license server, it stores license information corresponding to the license in a memory that is shared by the plurality of applications and the license proxy process.
Other embodiments are also disclosed.
Illustrative and presently preferred embodiments of the invention are illustrated in the drawings, in which:
An exemplary embodiment of a system that uses a license proxy process to obtain licenses and store license information is illustrated in
Each of the applications 102, 104, 106 may be communicatively coupled to a license proxy process 210. As defined herein, a communicative coupling is any sort of coupling that allows for communication between two processes. By way of example, a communicative coupling may comprise a socket or other software coupling, and/or a bus, cable, network, wireless mechanism, or other mechanism. Thus, it should be appreciated that license proxy process 210 and applications 102, 104, 106 may reside on the same or different machines. It should also be appreciated that, in some embodiments, the applications 102, 104, 106 may be components (e.g., processes) of a larger application. As will be described in further detail below, with reference to
The license proxy process 210 is communicatively coupled to the license server 110. By way of example, the license server 110 may be a FLEXIm™ license server. However, the license server 110 may also take other forms. The license server 110 may be used to issue and control licenses for one or more applications, including applications 102, 104, 106. Licenses issued by the license server 110 may be used to enable applications, or to enhance or govern the capabilities of applications (including the capabilities of hardware and firmware that may be controlled by the applications). In one embodiment, the license proxy process 210 is launched or initialized upon launch of one of the applications 102, 104, 106.
The system may optionally comprise a shared memory 220 that is communicatively coupled to and shared by the applications 102, 104, 106 and the license proxy process 210. The memory 220 may be used to store license information corresponding to one or more licenses that are obtained from the license server 110. License information may comprise the license type, the application and/or feature for which the license was issued, and/or other application specific information or types of information needed by applications 102, 104, 106. It should be appreciated that, in some embodiments, the license information may comprise the license obtained from license server 110. Alternately, the license information may simply be an indication that a license has been obtained (e.g., a Boolean flag). In some embodiments of the
An exemplary circuit tester 300 that employs the license proxy process 210 is illustrated in
As shown, tester 300 may comprise a plurality of boards 302-306. Each board may comprise a plurality of pins for driving inputs to, and receiving outputs from, device 350. In one embodiment, each pin may be associated with its own memory for storing test stimuli or test results (e.g., pin-specific vector information). In alternate embodiments of the tester 300, a dedicated memory may not be provided for each pin, but may instead be included for each board or other component of tester 300.
The circuit tester 300 may also comprise a plurality of applications, such as process 310 and process 320, that are communicatively coupled to tester 300. The processes 310, 320 may be part of a test operating system or application that is installed on a workstation coupled to tester 300 via a communication link such as an optical link. The processes 310, 320 may be used to control and enable features of the tester 300. In one embodiment, process 310 may communicate with firmware on tester 300 to set-up tests (possibly including multi-port tests) for device 350, and process 320 may receive test results from device 350. In an alternate embodiment, the processes 310, 320 may be part of the firmware of tester 300.
Processes 310, 320 may require one or more licenses to execute or enable capabilities of the processes. As will be described in further detail below with reference to
By way of example, a license obtained by the license proxy process 210 may be used to enable all of the capabilities of the tester 300 or may be used to grant limited use of resources (e.g., limited rights to use boards, pins, memory or functionality (e.g., speed, GUIs, algorithms, test development tools, or debug techniques)) of the tester 300.
If 410 the memory 220 does not contain the required license information, the license proxy process 210 can be notified so that it can obtain the required license. In alternate embodiments, the application 102 may obtain the license directly from license server 110 and store it in the shared memory 220 for subsequent management by the license proxy process 210. The application 102 may then notify the license proxy process 210 to begin heartbeat communications for the license with the license server.
After the license is received 510, the license proxy process 210 may optionally store 515 license information corresponding to the license in shared memory 220. As previously described, the license information may include the license itself, a Boolean flag, and/or other types of information needed by the applications 102, 104, 106. In one embodiment, after a license has been received 510, an indication may be sent from the license proxy process 210 to the applications 102,104, 106 to notify them that a license has been obtained. Alternately, the applications 102, 104, 106 may read the memory 220 whenever they require a license. If license information is not present, the applications 102, 104, 106 may cause the license proxy process 210 to obtain a license, and then periodically poll the memory 220 to determine if license information has been obtained; or, an application may wait until it receives an indication from the license proxy process 210 that a license has been obtained. In some embodiments, the license proxy process 210 may proactively obtain one or more licenses for the applications 102, 104, 106, before they are required by the applications 102, 104, 106.
In some embodiments, if an acknowledgement to a heartbeat is not received, the licenses under which the applications 102, 104, 106 or 310, 320 are running may no longer be valid (e.g., because the license server 110 may have released all of its licenses during a failure). If the license proxy process 210 determines that a license indication is no longer valid, either because it failed to receive an acknowledgement to its heartbeat, or for some other reason, the license proxy process 210 can then take appropriate action. By way of example, “appropriate action” may take the form of notifying the application(s) 102, 104, 106, and/or attempting to reacquire a license from the license server 110. In some embodiments, the affected applications 102, 104, 106 may be allowed to continue running, while in other embodiments, the affected applications 102, 104, 106 may be halted until a valid license or licenses can be reacquired.
The heartbeat transmitted by the license proxy process 210 may be used to help prevent license over-usage. The heartbeat transmittal 605 may also serve as a notification to the license server 110 that a license is being used by the applications 102, 104, 106, and may serve to trigger an automatic reissue of the license to the license proxy process 210 after a restart of license server 110 following a failure. It should be appreciated that by using a license proxy process 210 to communicate heartbeats to the license server 110, license over-usage may be prevented with minimal or no impact on the performance of applications 102, 104, 106.
After the applications 102, 104, 106 have finished using a license, the applications 102, 104, 106, or a larger application of which they are a part, may send a notification to the license proxy process 210 that the license is no longer needed. The license proxy process 210 may then transmit a request to free the license to the license server 110. In one embodiment, this may be done by forwarding the notification received from one of the applications 102, 104, 106. The license server 110 may then make the license available to other applications. Additionally, after the applications 102, 104, 106 have finished using the license, either the license proxy process 210 or the applications 102, 104, 106 may remove the license information from the memory 220.
Given that a license may be shared by various applications 102, 104, 106, an application's release of a license does not necessarily mean that the license proxy process 210 can check the license back into the license server 110 and remove its information from memory 220. Rather, the license proxy process 210 can only release a license after it has been released by “all” of the applications 102, 104106 that share it. A mechanism for tracking the number of applications that actively share a license may therefore be useful. One way to do this is by storing a license usage “count” for each license referenced in the memory 220. These counts can be initialized to zero, and then each time an application requests a license, the license's count may be incremented, and each time an application releases a license, the license's count may be decremented. The license proxy process 210 may then check a license back into the license server 110 only if the license's corresponding count is zero.
Although license usage counts could also be stored within the license proxy process 210, storing them within a shared memory 220 will usually make it easier for applications 102, 104, 106 to access them.
Sometimes, it may be desirable to allow sharing of some licenses, but require that other licenses be checked out on a “per application” basis. To facilitate the simultaneous use of both types of licenses, licenses provided by the license server 110 could be of the form [<license_type>, <quantity>, <shared_license_flag>], where shared_license_flag is a Boolean value that may be set to True or False. If True, the license_type may be shared by multiple applications, up to the specified quantity. If False, the license_type cannot be shared.
The methods described above may be performed by hardware components, or may be embodied in sequences of machine-executable instructions that may be used to cause a machine, such as a general-purpose or special-purpose processor, or logic circuits programmed with the instructions, to perform the actions of the methods. Alternatively, the methods may be performed by a combination of software, firmware, and/or hardware.
While illustrative and presently preferred embodiments of the invention have been described in detail herein, it is to be understood that the inventive concepts may be otherwise variously embodied and employed, and that the appended claims are intended to be construed to include such variations, except as limited by the prior art.
