How to start an application on another system?
-
Hi, I wonder if we can start any console application which resides on a remote system from another system. Say I have abc.exe console application on pc2 and I would like to run it from pc1 say via an ethernet cable. There is no bi-directional data transfer, all I have to do is, whenever the user on pc1 wants to run that application he will communicate with pc2 to start the console application. Yeh I know you can do that by having another program on pc2 running and listening to the ethernet port. But is there any other way to run the application on pc2 without having another program on pc2 listening to the ethernet port?? I am not sure if I am clear, but lemme know if I am not clear. thanks, -Pavan.
-
Hi, I wonder if we can start any console application which resides on a remote system from another system. Say I have abc.exe console application on pc2 and I would like to run it from pc1 say via an ethernet cable. There is no bi-directional data transfer, all I have to do is, whenever the user on pc1 wants to run that application he will communicate with pc2 to start the console application. Yeh I know you can do that by having another program on pc2 running and listening to the ethernet port. But is there any other way to run the application on pc2 without having another program on pc2 listening to the ethernet port?? I am not sure if I am clear, but lemme know if I am not clear. thanks, -Pavan.
Just an idea, and probably not what you want to hear, but if I were going to do this, I would create a COM server, register it on PC2, and use it to start a separate console application on PC2. Then, I would set up my console application on PC1 to act as a COM client, remotely instantiating the COM server on PC2. When it creates the (remote) COM server, the creation process itself could indicate the the COM server is to launch the PCS console application. With this framework, you could even set up the COM server on PC2 such that you could tell it which of serveral console applications you would like it to start. Of course, this all presumes that you understand how to build COM servers and clients. This isn't too bad if your using C# or VB.net with VS 2005. Much harder if your using straight C++. Scott :)
-
Hi, I wonder if we can start any console application which resides on a remote system from another system. Say I have abc.exe console application on pc2 and I would like to run it from pc1 say via an ethernet cable. There is no bi-directional data transfer, all I have to do is, whenever the user on pc1 wants to run that application he will communicate with pc2 to start the console application. Yeh I know you can do that by having another program on pc2 running and listening to the ethernet port. But is there any other way to run the application on pc2 without having another program on pc2 listening to the ethernet port?? I am not sure if I am clear, but lemme know if I am not clear. thanks, -Pavan.
Google for Remote Procedure Calls (RPC).
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
-
Just an idea, and probably not what you want to hear, but if I were going to do this, I would create a COM server, register it on PC2, and use it to start a separate console application on PC2. Then, I would set up my console application on PC1 to act as a COM client, remotely instantiating the COM server on PC2. When it creates the (remote) COM server, the creation process itself could indicate the the COM server is to launch the PCS console application. With this framework, you could even set up the COM server on PC2 such that you could tell it which of serveral console applications you would like it to start. Of course, this all presumes that you understand how to build COM servers and clients. This isn't too bad if your using C# or VB.net with VS 2005. Much harder if your using straight C++. Scott :)
I am also thinking exaclty on the same lines. Have an application running on pc2 listening to the network all the time (client) and whenever it receives message from pc1 (server) it executes the corresponding routine/program. But since I am coding this in vc++, are there any readily available libraries/programs to setup this kind of client/server. Actually I do have some files which I use in my other MFC applications (without any problems) where I do exactly the same, those files are like SCNet, SDLnet, SDLnetsys, SDLnetTCP, SDLnetUDP, SDLx. But I am not able to use these files in my vc++ program as when I try to compile the program after adding all those files to the project and including the header files in the program, it gives me 155 or so errors all of them are of undeclared idetifiers and all the errors are in those added files. -Pavan
-
Just an idea, and probably not what you want to hear, but if I were going to do this, I would create a COM server, register it on PC2, and use it to start a separate console application on PC2. Then, I would set up my console application on PC1 to act as a COM client, remotely instantiating the COM server on PC2. When it creates the (remote) COM server, the creation process itself could indicate the the COM server is to launch the PCS console application. With this framework, you could even set up the COM server on PC2 such that you could tell it which of serveral console applications you would like it to start. Of course, this all presumes that you understand how to build COM servers and clients. This isn't too bad if your using C# or VB.net with VS 2005. Much harder if your using straight C++. Scott :)
I have tried this creating a client/server architecture. I have created a server program on the PC on which I would like to run the programs and then used a client program on another PC to send messages to the server to start/stop a program. The problem is, from the time I disconnect and reconnect the client, the server doesn't recevie any messages from the client untill I reinitiate/rerun the server side program. I am using Ethernet to communicate. I am not having any COM ports left to use on client system, so the remaining are USB, parallel and ethernet ports. Is there anyway to overcome this. I would like to run the server program all the time listening to the client requests no matter whether the client connects/disconnects. In other words, I would like to run the server program when windows boots and closes at windows shutdown and keeps listening to the client requests. thanks, -Pavan.
-
I have tried this creating a client/server architecture. I have created a server program on the PC on which I would like to run the programs and then used a client program on another PC to send messages to the server to start/stop a program. The problem is, from the time I disconnect and reconnect the client, the server doesn't recevie any messages from the client untill I reinitiate/rerun the server side program. I am using Ethernet to communicate. I am not having any COM ports left to use on client system, so the remaining are USB, parallel and ethernet ports. Is there anyway to overcome this. I would like to run the server program all the time listening to the client requests no matter whether the client connects/disconnects. In other words, I would like to run the server program when windows boots and closes at windows shutdown and keeps listening to the client requests. thanks, -Pavan.
OK, you can do what you suggest but it is a little different than what I was thinking. I see two basic ways to do this, both of which are perfectly reasonable: 1 - Use a COM server and client, as we have already discussed. 2 - Use a SERVICE program running on the server, which is continually listening to a specific port for incoming connections using Windows sockets. Your statement above indicates that you are thinking in terms of the second approach. Let me clarify the first approach a little. A COM server typically only resides in memory when a client has requested its service, and therefore has a REFERENCE to the COM server. When the client closes down, it releases the reference to the COM server, and when the COM server realizes that there are no "open" references to it, it shuts itself down. This is typical behavior in the COM world. This is OK, because with the proper registry entries on both the server and client machines, the Windows COM system will automatically locate and launch the COM server when a client requests its services. It seemed to me that your client would simply invoke the server, getting a pointer to the server's interface, then invoking an interface function that would launch a specific program on the server. Because the Windows COM system handles launching the COM server, you don't need to worry about whether the COM server is always on and always "listening" for incoming client requests. It will get started up as soon as a client requests one of its interfaces. Now, for approach number two...I have done this type of thing as well, using a SERVICE program, which is NOT the same thing as a COM server. Not too long ago, I wrote a service program that I set up to start every time the operating system was started. These programs show up in the "Services" program under "Administrative Utilities" in the control panel. There are a number of articles that discuss how to write a service program. In my case, my service program was designed to "listen" on a user-selectable port for incoming socket connections. When a connection was established, it would spin off a thread to process bi-directional communications between the service program and the client. This was all done using the WinSock API. In this case, the service program was always running and listening for incoming connections. I wish I could help you more, but it seems to me you will need to first decide which of the above approaches you wish to take (or yet another approach if someone else has made any add
-
OK, you can do what you suggest but it is a little different than what I was thinking. I see two basic ways to do this, both of which are perfectly reasonable: 1 - Use a COM server and client, as we have already discussed. 2 - Use a SERVICE program running on the server, which is continually listening to a specific port for incoming connections using Windows sockets. Your statement above indicates that you are thinking in terms of the second approach. Let me clarify the first approach a little. A COM server typically only resides in memory when a client has requested its service, and therefore has a REFERENCE to the COM server. When the client closes down, it releases the reference to the COM server, and when the COM server realizes that there are no "open" references to it, it shuts itself down. This is typical behavior in the COM world. This is OK, because with the proper registry entries on both the server and client machines, the Windows COM system will automatically locate and launch the COM server when a client requests its services. It seemed to me that your client would simply invoke the server, getting a pointer to the server's interface, then invoking an interface function that would launch a specific program on the server. Because the Windows COM system handles launching the COM server, you don't need to worry about whether the COM server is always on and always "listening" for incoming client requests. It will get started up as soon as a client requests one of its interfaces. Now, for approach number two...I have done this type of thing as well, using a SERVICE program, which is NOT the same thing as a COM server. Not too long ago, I wrote a service program that I set up to start every time the operating system was started. These programs show up in the "Services" program under "Administrative Utilities" in the control panel. There are a number of articles that discuss how to write a service program. In my case, my service program was designed to "listen" on a user-selectable port for incoming socket connections. When a connection was established, it would spin off a thread to process bi-directional communications between the service program and the client. This was all done using the WinSock API. In this case, the service program was always running and listening for incoming connections. I wish I could help you more, but it seems to me you will need to first decide which of the above approaches you wish to take (or yet another approach if someone else has made any add
Thanks for explaining in detail. I think I would go with the second approach. I am not worried about the server side program as its a basic c++ console application (I can even end up executing exe files depending on the message it receives), but on the client side, I have to send messages from both MFC based application and also from basic c++ application DLL. But I can try both of the approaches that you suggested and see which one is more feasible within my application. thanks, -Pavan.