Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.java.programmer > #14726 > unrolled thread

Network license control for a Java application

Started by"Qu0ll" <Qu0llSixFour@gmail.com>
First post2012-05-21 19:08 +1000
Last post2012-06-15 19:31 +1000
Articles 6 — 4 participants

Back to article view | Back to comp.lang.java.programmer


Contents

  Network license control for a Java application "Qu0ll" <Qu0llSixFour@gmail.com> - 2012-05-21 19:08 +1000
    Re: Network license control for a Java application Hatter Jiang <jht5945@gmail.com> - 2012-05-21 05:04 -0700
    Re: Network license control for a Java application "Jeffrey H. Coffield" <jeffrey@digitalsynergyinc.com> - 2012-05-21 07:47 -0700
      Re: Network license control for a Java application Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2012-05-21 09:48 -0700
        Re: Network license control for a Java application "Qu0ll" <Qu0llSixFour@gmail.com> - 2012-06-02 13:01 +1000
          Re: Network license control for a Java application "Qu0ll" <Qu0llSixFour@gmail.com> - 2012-06-15 19:31 +1000

#14726 — Network license control for a Java application

From"Qu0ll" <Qu0llSixFour@gmail.com>
Date2012-05-21 19:08 +1000
SubjectNetwork license control for a Java application
Message-ID<tL-dnV9Cee7NmyfSnZ2dnUVZ_q2dnZ2d@westnet.com.au>
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)
_________________________________________________
Qu0llSixFour@gmail.com
[Replace the "SixFour" with numbers to email me] 

[toc] | [next] | [standalone]


#14731

FromHatter Jiang <jht5945@gmail.com>
Date2012-05-21 05:04 -0700
Message-ID<ea0f67ab-986c-41dd-ab07-8590bdd9257a@googlegroups.com>
In reply to#14726
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.

On Monday, May 21, 2012 5:08:45 PM UTC+8, 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.
> 
> 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)
> _________________________________________________
> Qu0llSixFour@gmail.com
> [Replace the "SixFour" with numbers to email me]

[toc] | [prev] | [next] | [standalone]


#14739

From"Jeffrey H. Coffield" <jeffrey@digitalsynergyinc.com>
Date2012-05-21 07:47 -0700
Message-ID<jpdkim$ajt$1@dont-email.me>
In reply to#14726

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

[toc] | [prev] | [next] | [standalone]


#14741

FromPeter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com>
Date2012-05-21 09:48 -0700
Message-ID<1jo1065lokvjq$.68ia31b03umg$.dlg@40tude.net>
In reply to#14739
On Mon, 21 May 2012 07:47:49 -0700, Jeffrey H. Coffield wrote:

> 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
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

[toc] | [prev] | [next] | [standalone]


#14999

From"Qu0ll" <Qu0llSixFour@gmail.com>
Date2012-06-02 13:01 +1000
Message-ID<yP6dnTNUSJrfH1TSnZ2dnUVZ_g6dnZ2d@westnet.com.au>
In reply to#14741
Apologies for the lack of indenting...

"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
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

-----------------------------------------

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

--
And loving it,

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

[toc] | [prev] | [next] | [standalone]


#15301

From"Qu0ll" <Qu0llSixFour@gmail.com>
Date2012-06-15 19:31 +1000
Message-ID<iridnXl6p5S-nEbSnZ2dnUVZ_hGdnZ2d@westnet.com.au>
In reply to#14999
"Qu0ll"  wrote in message 
news:yP6dnTNUSJrfH1TSnZ2dnUVZ_g6dnZ2d@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?

--
And loving it,

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

[toc] | [prev] | [standalone]


Back to top | Article view | comp.lang.java.programmer


csiph-web