I have a C++ GDB Server application that runs on host and is currently integrated with Eclipse CDT to provide debugging support on different hardware platforms. Below is overall structure of it:
Eclipse CDT <-----> GDB <-------> MYGDBServerApp <------> Hardware Platform
This app listens on a port for communication with GDB. This works perfectly fine in desktop environment.
I am now evaluating options to move whole solution to web. For this, I need to move this native C++ GDB server application to web as well. For Cloud based IDE, I am using Eclipse Theia project and have developed an extension for it. Now, I am looking for options to somehow use this C++ application from browser as well.
I have tried to compile this app to WASM using emscripten but I ran into different problems. One problem is socket communication. As WASM script will be running in browser, it cannot open TCP sockets for communication. It can only use websockets and Emscripten documentation suggests to use some proxy server (websockify) to translates WebSockets traffic to normal TCP socket traffic.
I have following questions:
What are recommended options to use such application from browser?
Has someone tried this proxy-server approach in similar scenario. As per Emscripten documentation, This emulation is not very complete at the moment, it is likely that you will run into problems out of the box
Is there any other better approach to reuse/port this application to web?
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?
Background: I've got an C++/Qt-based application that communicates with servers on the user's LAN. It uses non-blocking TCP and UDP sockets, and the networking is implemented via calls to the BSD sockets API (i.e. socket()/send()/recv()/select()/etc). It all works well.
The other day, just for fun, I decided to recompile the application using emscripten, so that it could run as a WebAssembly app inside a web browser.
This worked surprisingly well -- within an hour or two, I had my app up and running inside Google Chrome. However, the app's usefulness in this configuration is severely limited by the fact that it isn't able to connect to any servers -- presumably this is because it is running in a restricted/sandboxed environment.
If I wanted to pursue this line of development beyond the clever-hack-demo stage and try to make it useful, I would need to find a way for my program to discover and connect to servers on the user's LAN.
My question is: is that functionality at all possible for a Emscripten/WebAssembly-based app to perform? If so, what steps would I need to take? (i.e. would it require upgrading the LAN's servers to handle WebSocket-based connections? Would it require adding some sort of proxy server to run on the web server that the web page was served from? Is UDP even a thing in a web-app context? Are there other hoops that would also have to be jumped through?)
I need to build an application on a remote server so it can be run locally, where it will issue commands to a website it is hosting. I'm building this application on my machine in QtCreator, but I would like to streamline testing the application by having it build on the remote server.
What is the best way to go about this?
That first sentence is so long and so confusing... -_-
That said Qt Creator supports remote deploying and debugging but not remote building (as far as I know; please someone correct me if I'm wrong).
The only remote-related thing about the building step is cross-compilation which again is performed locally (using a cross-compiler, specifying the sysroot etc.). Of course if the target platform is the same (architecture and installation wise) as the one you use for development the cross-compilation chaos can be completely omitted.
If you want to build Qt-based application (and not only run it) on the remote platform, you will have to setup the development infrastructure (Qt dev libraries, qmake etc.). However, I would suggest using your local system for the development unless the server provides a very noticeable boost during the building step. It's easier that way and makes sense especially if the application that you are building on the remote will be executed locally.
you have 3 options really:
run the IDE on the remote server and connect using vnc or x2go. This requires a relatively high bandwidth/low latency connection, or the GUI won't be reponsive. This is personally what I do at my work - although we have a dev server set up to mirror prod in our building - so the data connection is great.
sync your files using lsyncd and build via commandline. You code-completion will be based on your local machine, so won't be perfect, and you wont be able to double click compile errors, etc. If you are brave you could maybe set up a qt creator build configuration to do this for you, but includes would still be broken.
use another IDE. NetBeans supports remote builds. I have never personally used this feature, but I've heard that it works ok.
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.