EldoS | Feel safer!

Software components for data protection, secure storage and transfer

MsgConnect and user license management

Also by EldoS: CallbackRegistry
A component to monitor and control Windows registry access and create virtual registry keys.
#1214
Posted: 09/14/2006 08:21:59
by Mark Wilsdorf (Basic support level)
Joined: 09/14/2006
Posts: 3

We market a couple single-user applications which, when used in a network setting, must be installed on each workstation. In these situations we sell a license for our products for "X" number of users, but supply just one Registration Code...and currently, must trust that the purchaser really is using no more than "X" instances of our software at one time.

I was wondering if we might be able to use MsgConnect to control the number of instances of our product which are running on a LAN at any one time. That is, could MsgConnect be used for some kind of generic "broadcast" system whereby when an instance of our application starts up, it would check for other running instances of our application on the network and, if the number of licensed instances is already running, would provide a message and prevent running an additional instance.

I'm not worried about having something that's "ironclad" in terms of security, I just want something that would help most of our customers "stay honest" with respect to their license purchases.

Might MsgConnect be used in some way for this?

Thanks,
Mark Wilsdorf
#1217
Posted: 09/14/2006 13:24:38
by Eugene Mayevski (EldoS Corp.)

MsgConnect's UDP Transport can be done to send UDP broadcasts. And other instances can report to the originator using SocketTransport (since UDP is not reliable, and the instances *must* access the originator, TCP is required).


Sincerely yours
Eugene Mayevski
#1219
Posted: 09/14/2006 14:48:43
by Mark Wilsdorf (Basic support level)
Joined: 09/14/2006
Posts: 3

Sorry to sound like I was raised in a cave, but I don't know much about the wide variety of LAN communication protocols & their capabilities--I've spent my time in other technologies--that's why I'm looking to MsgConnect to handle some of those details. I hope you don't mind a couple more questions.

If UDP is unreliable, how can I trust that messages broadcast via UDP will be received by new instances of my application? (In what way is it unreliable...speed when LAN traffic load is high? or messages not received in some cases? or messages not sent in some cases? etc.?)

Since you're suggesting sockets for the reply, I suppose the originator would send its IP address in the original UDP message, and the receiver could use that for socket communication?

Here's what I've envisioned, in generic terms:

1. Whenever an instance of our app starts up, it sends out a UDP broadcast across the LAN, which includes its IP address as part of the message.

2. All receivers of the message report back to the new instance via sockets (to the IP address provided in the UDP message).

3. The new instance continues running if it receives back no more than (n - 1) replies from existing instances, where n is the maximum number of licensed users allowed.

3a. If the new app instance receives more than (n - 1) replies, it displays a "Number of licenses exceeded... click here if you wish to purchase more licenses" message, then shuts itself down.

Please tell me if you can think of a better approach.

Also, I realize there are some other issues to deal with in the procedure I've outlined above. For instance, due to response time lags across the LAN, it may be possible for more instances of the application to be started than the 'n' allotted number of licenses--if, during the start up period one or both of the application instances failed to receive the UDP broadcast. Or possibly the reverse could be true as well, in that case where both new instances received each other's broadcast message and both shut themselves down because they believed they were the n+1 instance.

Anyway, I'd appreciate any ideas you might have.

Thanks,
Mark Wilsdorf
Flagship Technologies, Inc.
QuickBooks™ Add-Ons and Solutions You Can Use
http://www.goflagship.com
#1220
Posted: 09/14/2006 15:25:59
by Eugene Mayevski (EldoS Corp.)

Quote
Mark Wilsdorf wrote:
If UDP is unreliable, how can I trust that messages broadcast via UDP will be received by new instances of my application? (In what way is it unreliable...speed when LAN traffic load is high? or messages not received in some cases? or messages not sent in some cases? etc.?)


UDP doesn't guarantee delivery. Loss of packet can happen for whatever reason, and it's generally not user's business to care, why this happens. If the user needs guaranteed delivery, he must use TCP.
BUT. TCP doesn't offer broadcasting.

There's no magic bullet unfortunately, i.e. you can either have broadcasts, or reliable delivery (or notification about impossibility to deliver).

To be continued...


Sincerely yours
Eugene Mayevski
#1221
Posted: 09/14/2006 15:28:56
by Eugene Mayevski (EldoS Corp.)

Quote
Mark Wilsdorf wrote:
Please tell me if you can think of a better approach


Your scheme is correct and the simpliest one. As for possible conflicts, each instance of the application can save the IPs of the other systems and count them. Then contact the other sides and agree on who will shut down.


Sincerely yours
Eugene Mayevski
#1222
Posted: 09/15/2006 09:02:59
by Mark Wilsdorf (Basic support level)
Joined: 09/14/2006
Posts: 3

Quote
Then contact the other sides and agree on who will shut down.


Yes, that won't be hard to do.

As for the possibility of UDP broadcasts not reaching all workstations, I don't really need an ironclad approach, just something to keep "most" users compliant with their license agreements "most" of the time.

If UDP really isn't quite reliable, I suppose another alternative might be to have each instance of my app broadcast once every 3 minutes or so. This wouldn't result in much processing or network traffic overhead, but might overcome part of the UDP reliability problem. (If the first UDP broadcast was missed, a later one might get through to its destination.)

Thanks for your help.
Also by EldoS: CallbackProcess
A component to control process creation and termination in Windows and .NET applications.

Reply

Statistics

Topic viewed 5945 times

Number of guests: 1, registered members: 0, in total hidden: 0




|

Back to top

As of July 15, 2016 EldoS Corporation will operate as a division of /n software inc. For more information, please read the announcement.

Got it!