10-01-2018 07:53 AM
Hi,
I want to write an application which will be the only instance that will run. No other instance of the same application should be able to run from any computer in the network and prompted that a instance of application is already running. Any solution to this problem?
Solved! Go to Solution.
10-01-2018 07:58 AM
Hi lvbms,
you need to find a way to detect other instances of that executable in your network.
Ideas:
- have the executable lock a file on your local server. Once the file is already locked, you know there is another instance running.
- have the executable contact a server. The server can respond with a "first instance?" response. You need to create such a server (maybe using LabVIEW?) somewhere in your network.
- have the executable broadcast an UDP message and wait for answers. Your executable must respond for such messages to indicate it's already running.
- …
10-01-2018 01:26 PM
@lvbms wrote:
Hi,
I want to write an application which will be the only instance that will run. No other instance of the same application should be able to run from any computer in the network and prompted that a instance of application is already running. Any solution to this problem?
I have to ask from more details, mainly why?
But anyway your applications is going to have to do these things
I guess you could listen and announce on a UDP port of your choosing as long as it's not a port something else needs.
10-01-2018 02:13 PM
A couple problems with any of these schemes is suppose the other instances fail to respond to a UDP request to announce themselves?
Or an instance checks itself out of a server, but fails to check itself back in when exiting. A later instance of the application will think the first instance is still running when it tries to check itself out of the server.
10-01-2018 02:34 PM
@RavensFan wrote:
A couple problems with any of these schemes is suppose the other instances fail to respond to a UDP request to announce themselves?
Or an instance checks itself out of a server, but fails to check itself back in when exiting. A later instance of the application will think the first instance is still running when it tries to check itself out of the server.
IKR.. There are so many things that could go wrong here, a little (a lot) more information is really needed on this one, as there has to be a better way to do this.
I still want to know what exactly this program is doing that it can be the only program running in an entire company that is doing it?
10-02-2018 04:06 AM
The application works as a client and connects to a server to command it to measure. However if application fails to connect to server it remotely kill the server instance and restart the server instance again.
So in case of first instance of the application is connected to the server. If second instance run, I can kill the server instance and connection of first instance to server will become invalid.
10-02-2018 06:14 AM
@lvbms wrote:
However if application fails to connect to server it remotely kill the server instance and restart the server instance again.
That just sounds like a horrible design. The client has absolutely NO information on the status of server. The server could just be busy with another client. Just tell the user you were unable to connect and let them worry about it. Alternatively, you could allow for multiple connections and only use the second one to tell people it is busy (and close that connection almost immediately). The user can react accordingly.
10-02-2018 09:08 AM - edited 10-02-2018 09:08 AM
Patient: "Doctor, it hurts when I do this"
Doctor: "Well then, stop doing that!"
The application works as a client and connects to a server to command it to measure. However if application fails to connect to server it remotely kill the server instance and restart the server instance again.
So in case of first instance of the application is connected to the server. If second instance run, I can kill the server instance and connection of first instance to server will become invalid.
-Kevin P
P.S. Looks like crossrulz already gave a more complete and direct answer.
10-05-2018 03:46 AM
Finally found the two approaches :
1. Using network shared variable. Need a server where you can deploy the shared variables.
2. Using a file opening and deny access until the application exits. Opens the file on a PC which is always required to be connected in the network i.e. measurement PC where the measurement system is connected.
@Kevin_Price
10-05-2018 09:15 AM - edited 10-05-2018 09:16 AM
@lvbms wrote:
Finally found the two approaches :
1. Using network shared variable. Need a server where you can deploy the shared variables.
2. Using a file opening and deny access until the application exits. Opens the file on a PC which is always required to be connected in the network i.e. measurement PC where the measurement system is connected.
@Kevin_Price
So is this all about #2? If you use the proper File primitives when Windows Opens or Creates a file it will be locked, meaning no other program can access that file while the first program has it locked. Actually they can but Windows will only allow it to be opened read only or open a copy of the file so others can still view the file while it is locked.
This file can even exist on a network, so you could write your program so it will not run if it can not open or create that file in that spacific network location.