Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Network license control for a Java application

10 views
Skip to first unread message

Qu0ll

unread,
May 21, 2012, 5:08:45 AM5/21/12
to
I have been tasked with providing some form of network license control for a
Java application. The app would be stored on a network drive and run from a
client machine. The basic idea is that it will be able to work out how many
times it is being run concurrently and prevent the N+1th user from running
the software where N is the number of concurrent licenses the customer has
purchased.

Is this possible somehow with a Java application? I was thinking of maybe
incrementing a number stored in a file every time the app is run and then
decrementing it again when the app exits. I also thought of storing a time
when each app invocation started so I could "time-out" users in the cases
where the app may crash.

Is this a viable solution or is there a better way?

--
And loving it,

-Qu0ll (Rare, not extinct)
_________________________________________________
Qu0llS...@gmail.com
[Replace the "SixFour" with numbers to email me]

Hatter Jiang

unread,
May 21, 2012, 8:04:38 AM5/21/12
to
How does this method;

create a database table :
ID, TASK_NAME, TASK_RUN_COUNT

insert (id, task_run_count) values(1, 10);

when run :
update set task_run_count=task_run_count-1 where id=1 and task_run_count > 0;

if update one record the the application can run, if no record updated then the application cannot run.

but if the application crash, i have no good idea, it depends on your requirement.

Jeffrey H. Coffield

unread,
May 21, 2012, 10:47:49 AM5/21/12
to


On 05/21/2012 02:08 AM, Qu0ll wrote:
> I have been tasked with providing some form of network license control
> for a Java application. The app would be stored on a network drive and
> run from a client machine. The basic idea is that it will be able to
> work out how many times it is being run concurrently and prevent the
> N+1th user from running the software where N is the number of concurrent
> licenses the customer has purchased.
>
My first idea would be to have the application open a connection to a
"license server" that would only accept N connections. With some sort of
keep-alive packet you could time out systems that crashed. (I have seen
windows systems crash and leave TCP/IP connections open).

Jeff Coffield
www.digitalsynergyinc.com

Peter Duniho

unread,
May 21, 2012, 12:48:54 PM5/21/12
to
As an alternative to adding to network traffic with keep-alive packets, the
license server could simply requery active instances when a new instance
attempts to run. An instance that doesn't respond at that point can be
considerd defunct.

An even simpler alternative to a license server would be to use UDP
broadcasts to have a new instance query the LAN for any other instances.
If too many respond, then the new instance doesn't run. This approach
doesn't require any centralized license server.

It's important to note, however, that with all of the suggestions offered
so far it is not difficult to hack around the DRM.

One important _benefit_ to those suggestions IMHO though is that they
aren't likely to create false positives (where "positive" is the denial of
an instance running). That is, while due to network congestion and other
issues it's possible an instance would be allowed to run when it shouldn't
have been, but it's unlikely for an instance to be prohibited when it
should have been allowed.

Personally, it's my opinion that DRM should always fail in favor of the
licensee. Granted, this generally leads to weaker,
more-easily-circumvented DRM but IMHO that's as it should be. DRM is
useful for keeping honest people honest; especially in the realm of
software-only DRM, if it's used to try to keep dishonest people honest, it
invariably fails to accomplish that goal, while inconveniencing (sometimes
in dramatic, significant ways) the honest people.

Pete

Qu0ll

unread,
Jun 1, 2012, 11:01:04 PM6/1/12
to
Apologies for the lack of indenting...

"Peter Duniho" wrote in message
news:1jo1065lokvjq$.68ia31b03umg$.dlg@40tude.net...
-----------------------------------------

Thanks very much for this Pete. Using your idea and guidelines I was
successfully able to implement network license control using multi-cast UDP.

Qu0ll

unread,
Jun 15, 2012, 5:31:48 AM6/15/12
to
"Qu0ll" wrote in message
news:yP6dnTNUSJrfH1TS...@westnet.com.au...

>> "Peter Duniho" wrote in message
news:1jo1065lokvjq$.68ia31b03umg$.dlg@40tude.net...
>>
>> > On 05/21/2012 02:08 AM, Qu0ll wrote:
>> >> I have been tasked with providing some form of network license control
>> >> for a Java application. The app would be stored on a network drive and
>> >> run from a client machine. The basic idea is that it will be able to
>> >> work out how many times it is being run concurrently and prevent the
>> >> N+1th user from running the software where N is the number of
>> >> concurrent
>> >> licenses the customer has purchased.
>> >>
>> > My first idea would be to have the application open a connection to a
>> > "license server" that would only accept N connections. With some sort
>> > of
>> > keep-alive packet you could time out systems that crashed. (I have seen
>> > windows systems crash and leave TCP/IP connections open).
>>
>> As an alternative to adding to network traffic with keep-alive packets,
>> the
>> license server could simply requery active instances when a new instance
>> attempts to run. An instance that doesn't respond at that point can be
>> considered defunct.
>>
>> An even simpler alternative to a license server would be to use UDP
>> broadcasts to have a new instance query the LAN for any other instances.
>> If too many respond, then the new instance doesn't run. This approach
>> doesn't require any centralized license server.
>>
>> It's important to note, however, that with all of the suggestions offered
>> so far it is not difficult to hack around the DRM.
>>
>> One important _benefit_ to those suggestions IMHO though is that they
>> aren't likely to create false positives (where "positive" is the denial
>> of
>> an instance running). That is, while due to network congestion and other
>> issues it's possible an instance would be allowed to run when it
>> shouldn't
>> have been, but it's unlikely for an instance to be prohibited when it
>> should have been allowed.
>>
>> Personally, it's my opinion that DRM should always fail in favor of the
>> licensee. Granted, this generally leads to weaker,
>> more-easily-circumvented DRM but IMHO that's as it should be. DRM is
>> useful for keeping honest people honest; especially in the realm of
>> software-only DRM, if it's used to try to keep dishonest people honest,
>> it
>> invariably fails to accomplish that goal, while inconveniencing
>> (sometimes
>> in dramatic, significant ways) the honest people.
>>
>
> Thanks very much for this Pete. Using your idea and guidelines I was
> successfully able to implement network license control using multi-cast
> UDP.

Unfortunately I spoke a little bit too soon! My solution worked very well
on my network but as soon as it was tried on the client's network it failed
miserably.

The reason was simple: their network has group policies which prevent
arbitrary ports being opened and therefore there were never any responses
from other machines on the same network also running the software
concurrently. The result was that each instance thinks it's the only
instance running.

So now I am back to square one... is there any other way I can implement
network license control using Java? The other problem is that the client
machine running the software usually doesn't have administrator rights to
the machine from which the software is launched and therefore cannot write
data into the working directory which is usually in Program Files (the OS is
Windows only). This prevents me implementing some system where I write to a
file on the launch machine and try to keep track of the client machines and
how many times the app has been run.

I am at a bit of a loss here. Does anyone have any other ideas how I could
implement this?
0 new messages