I am trying to implement inter process communication between a desktop native app and an electron app on Windows for assignement(Operating systems).
I am new to this area and not able to find relevant links.
The options I have considered are:
1. TCP
2. HTTP server
3. COM
4. Namedpipes
NamedPipes seem correct, as electron implements its IPC using named pipes. There is a net module available which implements sockets that seem to be similar.
And I can write the server in the native app.
Does this sound correct to you guys? Any better alternatives? Any suggestions which will help me learn will be useful.
Check out the library node-ipc https://github.com/RIAEvangelist/node-ipc which has a range of ways by which you can communicate between node (which is what basically electron is) and other system level processes.
Related
I am failing to allow ipc between Go and C++ over sockets on Windows.
I have a C++ app and a Go app on Windows (10/11) where I need IPC between the apps. I have been trying out gRPC and it worked over a localhost channel perfectly but the firewall popup is not ideal. It looks like grpc++ doesn't support named pipes but finding out if I can switch to sockets on the C++ side is a little less clear.
Trying TestClient client(grpc::CreateChannel("unix:grpctest", grpc::InsecureChannelCredentials()));
just results in:
DNS resolution failed for unix:grpctest: C-ares status is not ARES_SUCCESS qtype=A name=unix is_balancer=0: Domain name not found
Does anybody know if this is possible?
Scenario:
We have a Qt application(Qt 5.9.5,C++,QML,Ubuntu) running on a device (deals with telecommunications), which can also be viewed in a browser using webserver. All the operations done manually on the device have been visualized on the browser simultaneously.
Requirement: Now what we want to achieve is build a similar application(maybe web application) so that you execute it from a browser and simultaneously the application on the device should execute by itself. The device is just switched on initially. everything should be operated from the client application. What are the possible options?
We have started with Qt Remoteobjects to make a remote application but Qt version of device is older one when compared with Qt version of some functionalities in remote objects module. so using remote objects is not possible now.
Can Qt WebGL streaming helpful in this case?
Does QtWebchannel and websockets help by setting up communication with html/javascript application. Is it a possible solution?
Is virtual network computing (VNC) an option to think about in my scenario?
I have come across some concepts like Qt for WebAssembly, Web toolkit(Wt), Emscripten, Cutelyst web-framework, Qt for Automation - MQTT,OPC UA, KNX, CoAP . Do these really help at any point while developing a client application to control the QML GUI on a telecom. device?
Which of the options suits my scenario?
I have been following Qt's blogs about these related topics. Still not sure which method is suitable?
Sorry for a lengthy explanation. Kindly provide some suggestions.
Thank you.
I am trying to create P2P(UDP) windows 10 UWP application written in c++ using networking library written in C (tried both enet and libuv).
The problem is when the app is acting like client everything works as expected, but when I am testing the server part the application refuse to receive any events (connection in enet and messages from libuv). I tried the code from simple console applications and it works for both enet and libuv!
Also I added rules in the firewall to allow everything on the default port.
My question is, do I need to make additional configurations for the UWP application for receiving?
According to your description on your same thread in MSDN, the server and the client are on the same device.
According to the note of DatagramSocket official sample:
Network communications using an IP loopback address cannot normally be used for interprocess communication between a Universal Windows Platform (UWP) app and a different process (a different UWP app or a desktop app) because this is restricted by network isolation.
We cannot communicate a uwp app with other apps in a same machine. Not even with a loopback exemption. This is as design. If you use a c# console project as server and a uwp app as client, they may communicate successfully. But it need special steps (E.g. run the console as administrator) to let it work which you may happen to meet the requirements. Details you can reference this thread.
I have 2 application running on the same machine.
Editor, is a Windows 8 application developed with WinRT and is sand-boxed. (Client)
Integrator is a C++ application for reading hardware devices over serial COM ports. (Server)
I have done a lot of searches about how to get client/server communication to work on Windows 8,
and can only find posts that say it is not possible using standard WinRT classes, etc.
What I need is a solution where by the Windows 8 application works as a client, and the standalone
executable works as a server.
Can someone please suggest a mechanism that can be used to do client/server communication.
If we cannot find a good solution for this, then we will have to resort to using files, which
I would rather not have to do.
Clarification: I am aware of the many mechanism that can be used to do client/server communication.
What I am looking for is a workaround to the problem, where the these techniques will not work on
a Windows 8 application, developed with WinRT. As the sand-boxing explicitly prohibits the client
and server being on the same host machine.
Well, the posts stating that such communication is not possible, are mostly right. There are 2 reasons, why this is prevented:
Being able to communicate to an application outside the sandbox effectively breaks the sandbox. The Windows Store app is now suddenly able to do everything the desktop application can do: access file system, registry... Windows Store apps live in a sandbox for reason - to be safe for the user.
The Windows Store app won't work after it is installed from the the store or from a package. It needs to have a desktop application installed and set up correctly as well.
I would suggest you try to move your server part to a different machine and make it a proper server. If for some reason you really can't do that, you still have the following options available:
You can use TCP/IP to connect local network resources if you remove the isolation for your Windows Store app. You will need to use CheckNetIsolation.exe, but since you already need to separately install the desktop application, this shouldn't be that much of a problem.
You can create files with a specific extension. Then register the desktop app for one extension and the Windows Store app for another extension. You can now shell execute files with these extensions to use them as a message for the other app.
I am developing 2 Windows services, one of them will send pictures and word files to other and other service will give a string answer. That services are in same computer.
I will develop same program's Linux version also.
Which way is the best for communication between services in Linux and Windows.
By the way I am developing that services with C++.
There're different options for your task:
Network. Establish TCP connection between your services, with service that asks as a client and service that answers as a server. It's possible to implement cross-platform solution using Boost.Asio or any other portable network library.
Shared memory. You can implement inter-process communication using shared memory. Cross-platform library: Boost.Interprocess.
Pipes. I don't know cross-platform library for this.
I would recommend to use TCP communication as more flexible solution.
I would suggest reading up on C++ sockets. You're probably going to want to use TCP sockets, since you want to ensure that the data being transferred does so correctly.
Try checking these links out:
Linux Sockets
Windows Sockets
You should search for IPC.
There are a lot of possibilities for inter process communication. Because you are not very specific about your problem and your requirements but I would suggest to take a look at boost::interprocess.
As long as you are sure that both services run on the same machine this will do it.
If you want to switch to a distributed approach you need something different.
Like XML-RPC, thrift or corba. Just to mention some possibilities.