How to communicate between application

[OZI]

Hi,
I have two application which are running on the same target computer and I will comunicate between them.
One is a just a program to start and stop the other. The second is the main application.

- I tried the CreateThread function of the windows api but the problem is that I couldn't communicate then.
- The second what I tried was to communicate over the network-functions like TCP-Server and TCP-Client or DataSocket. This is working. BUT the problem is when the system is on the customer network and a firewall of the server stopp the communication. Then it is working not save any more.
If the system is not on the network everything is ok.

My Question:
Is there any other (perhaps easy) possibility to communicate between applications ?

Thanks in advance
Oliver

[MJF]

I am not entirely sure what you mean here but I will take a shot at it.

The TCP Server/Client mechanism should work between two programs on the same machine. Just set the address of the server and the client to 127.0.0.1 and it should never send anything out over the network. (127.0.0.1 is the reserved address for "self", it tells the computer that it is to talk to itself and not anything on the network). Even if you used the machine's own assigned IP address for both the server and client programs, it should still never send anything over the physical network because the Winsock library is smart enough to recognize how to route the packet.

Another option is to use Datasocket. I am not overly familiar with it but it is supposed to be a simple to use interface to allow client/server type data connections. There are examples of how to use it in the CVI samples directory.

The threading functions are for creating and controlling multiple threads within a single program, they are not going to do you any good for interprocess communication.

I hope that helps.

[OZI]

Hi,
the problem is that I have only one network card in these computers and this is connected to the customers network. So I can't use 127.0.0.1 as IP-Adress. I asked my customer to give me a solid IP-Adress and I got one. If I use this IP-Adress to communicate with the other application it doesn't work. I see that the firewall on the computer reacts and the other application does not get any information. On all our other systems this is working.

Greetings
Oliver

[MJF]

Oliver,

Your understanding of the 127.0.0.1 address appears to be in error. The 127.0.0.1 address always refers to the local machine. If you ping 127.0.0.1, your own machine will respond through the TCP/IP software. No data traffic will go onto the network.

You can use the machine's assigned IP address too but why keep track of that? 127.0.0.1 is intended for local communication between programs via the TCP/IP stack. It was originally implemented for testing the TCP/IP protocol itself.

If the customer has a software firewall installed and it is blocking traffic on the local machine, it is misconfigured. It should be set to allow all traffic originating on the local machine to pass.

Regardless, you can still use the 127.0.0.1 address for both client and server if they run on the same machine. That is how TCP/IP works, that address is reserved specifically for the local machine as is the host name "localhost".

[MJF]

Oliver,

I have one more suggestion, you should recommend to your customer that they should get rid of the software firewall. They take a serious toll on networking performance and can cause the PC to slow down a lot. An inexpensive router like something from Linksys or Netgear is a much better solution and allows multiple machines to share one Internet connection while providing protection to all of them.

I have a ten year background in networking and TCP/IP specifically, this is something I know very well.

[OZI]

Hi Martin,
I didn't know this about the 127.0.0.1 !!! This is a great tip which I will try. And I think this will be the solution to communicate "inside" the computer.

The problem with the customer is, it is a french company and they have very strong restrictions about their network. We are very happy that they allow us to hang our computer up to the network too. They are very afraid about viruses, trojans etc.

But I think we got the solution with the 127.0.0.1 adress.

Thank you very much and best regards
Oliver

[MJF]

No problem, networking stuff is what I have been doing for the last 10 years and I know a lot of it pretty deeply. If you ever want to read up on it and get a good introduction, I recommend "Internetworking with TCP/IP Vol.1: Principles, Protocols, and Architecture" by Douglas E. Comer. This is a classic work in the field and is used extensively in university networking courses and by a lot of people working in the industry.

I really do recommend that you try to convince your customer that they would be far better served with a hardware firewall. Software firewalls are notoriously problematic because they can seriously affect computer performance. There is nothing wrong with your customer's desire to protect their network, I just question their approach. A hardware firewall/router, a good virus scan program with regular updates and scans and a regular backup schedule will protect them far better than a software firewall.

[rolfk]

---

@OZI wrote:
Hi Martin,
I didn't know this about the 127.0.0.1 !!! This is a great tip which I will try. And I think this will be the solution to communicate "inside" the computer.

The problem with the customer is, it is a french company and they have very strong restrictions about their network. We are very happy that they allow us to hang our computer up to the network too. They are very afraid about viruses, trojans etc.

But I think we got the solution with the 127.0.0.1 adress.

Thank you very much and best regards
Oliver

---

I prefer to use "localhost" for this. But it really resolves to the same 127.0.0.1 adress through every TCP/IP stack that I know of.

Rolf Kalbermatter

[jr_2005]

As an alternative to the networking approach to inter-process communication, you could try using Windows Events. I used this approach successfully to start and stop a second application from the main one:

  // This is the main application:
    handle = CreateEvent (0, 0, 0, "CommonStringToSynchroniseApps");

    LaunchExecutable ("SecondApp.exe");

    if (WaitForSingleObject (handle, 30) != WAIT_OBJECT_0) {    // The other app should set this event trigger

        // Other app did not start within 30 seconds - abort

    }

    ...
    // Both apps now running
    ...

    CloseHandle (handle);       // When main app terminates, close the handle

    return 0;

  // This is the second application, started and stopped by the first one:
    handle = CreateEvent (0, 0, 0, "CommonStringToSynchroniseApps");    // Use a macro in a common .h file for the name!
    // Inside a timer callback, running every second:
        if (WaitForSingleObject (handle, 0) == WAIT_OBJECT_0)    // Detects when handle has been closed by other (main) app
            QuitUserInterface (0);

If you need to pass data between apps, you can use the SDK File Mapping functions (CreateFileMapping(),  MapViewOfFile(), UnmapViewOfFile ()) quite easily.

JR

[rolfk]

---

@jr_2005 wrote:

As an alternative to the networking approach to inter-process communication, you could try using Windows Events. I used this approach successfully to start and stop a second application from the main one:

< cut code example >

If you need to pass data between apps, you can use the SDK File Mapping functions (CreateFileMapping(), MapViewOfFile(), UnmapViewOfFile ()) quite easily.

---

While this is a possibility and has the possible benefit of shaving off a few microseconds in data transfer overhead, it has some extra complications:

1) You need to write C code or at least interface to more or less complicated WinAPI functions through the Call Library Node.

2) Once you do 1) you are inherently limited to the Windows platform only for your VIs as well as your application, with the additional limitation of only supporting local data transfer.

TCP/IP leaves you open the possibliity of distributing your apps over the network by simply changing the connection adres and it will also just recompile in any LabVIEW platform version such as LabVIEW Embedded, MacOS, Linux etc, and including possible upcoming versions such as LabVIEW for Windows 64bit.

Rolf Kalbermatter