I have a GUI (frontend, programmed in C++) and a kernel (backend, programmed in C++). Currently, the frontend is just linked to the backend library. However, due to performance reasons I want the functions from the library to be exceuted from another computer/server. The communication to the server shall be done via a TCP/IP connection.
The current idea to achieve this, is to set up a TCP/IP client/server connection. After the connection is set up the gui sends a header id and maybe additional data to the server, where the code is executed and the return is send back. However, to achieve this, I have to map every function to a header id and program the handling of the received data for every function in the backend. This is a tedious work, where I have to wrap each function manually.
The question is now: What is the common practice to connect the frontend to the backend via a server/client connection? And is there any generator (like SWIG for Python etc.) to generate a TCP/IP interface?
Related
We have started using gRPC C++ for our embedded system project (ARM Processor Cortex-A7) as a client. We have successfully created a sample application which communicates with the server using protobuf.
We have a new requirement now. We have to open multiple connections to the different endpoints (or server) via different interfaces (like ethernet, wifi and cellular [using ppp]).
I tried to google but couldn't find any solutions to it. I have tried gRPC forum but hasn't received a proper reply to my question.
I have wondering if gRPC has provision to bind to a particular interface or IP. Linux POSIX socket provides SO_BINDTODEVICE option but I am not sure if gRPC has any application layer method or function to achieve it (can't find it in the documentation).
Or Can we achieve it via some other hack (may be by modifying the routing table?).
I have a nodeJS server which receives user POST/Streaming requests from a web-UI.
I have a C++ back-end engine process which does some calculations and sends API calls to other 3rd party services. The API call requires certain info provided by the web users.
My question is what is the best solution to pass the request data received on NodeJS and send over to the C++ process?
WebUI -> NodeJS ->???->> C++ engine
Make your C++ application listen on a TCP or Unix socket.
Make your NodeJs application connect to that socket and exchange messages. For messages you can use Google Protocol Buffers, JSON, etc..
If the information what you have is still at JavaScript layer, then you have to implement C/C++ Addons implementation. If you already have some type of native module, then you may follow the same design based on that (very likely existing module could be based on NAN). If you are plan to introduce a brand new native module then it is a good time to consider N-API. You can get more information about it from.
https://nodejs.org/dist/latest-v11.x/docs/api/n-api.html
https://github.com/nodejs/node-addon-api
I made a simple program in c++ for connecting to a site and loading a page HTML code or send data using GET/POST requests.
But now I want the program to connect and send/receive data through proxy.
You probably know software like NextVpn and proxifier. when they are running any application which tries to communicate through internet will have to go through these apps.
The problem is that my program connects and communicates directly and my proxy software doesn't interfere.
Communication is done by the socket programming routins (SOCKET class) like this
SOCKET sck=socket(AF_INET,SOCK_STREAM,IPPROTO_TCP);
connect(sck,(SOCKADDR*)(&SockAddr),sizeof(SockAddr));
send(sck,myRequest,strlen(myRequest),0);
Any solution?
EDIT: The problem was from NextVPN not the Proxifier itself. It seems that NextVPN lacks functionality in hooking into some programs. First NextVPN finds the program which is trying to connect to a remote address then redirects it to its portable version of proxifier with something named "compose.ns" . Unfortunately it was unable or couldn't detect my app connecting to internet. Instead I used Proxifier itself and it successfully detected my app as it was showing in its connection list.
I have a system where I want to listen to a socket and wait to client connect and then pass the connection to another application that I'll start as soon as the connection is established.
I do not have control on this other application and can only set the port where it will listen, but I want to have one process for each new client.
This is what I'm trying to do:
I've been searching for a solution, but I thing I don't have the right terminology, but I managed to find on Richard Stevens' "Unix Network Programming" something about the AF_ROUTE family of sockets that may be combined with a SOCK_RAW to route a connection to another IP and port. But there's too little documentation about how to use this flag and seems to require superuser privileges (that I want to avoid).
Maybe there's an easier solution but I'm probably using the wrong terms. Is it clear what I want to do?
I don't think you'll be able to just "pass" the socket like you want to, especially if you can't change and recompile "APP". Sockets include various administrative overhead (resource management, etc) that are linked to the process they are owned by. In addition, if you can't recompile APP, there is no way to make it bypass the steps involved with accepting a connection and simple have an already open connected "handed" to it by your router.
However, have you considered simply using router as a pass-through? Basically, have your "Router" process connect via sockets to the each "APP" process it spawns, and simply echo whatever it recieves from the appropriate client to the appropriate APP, and visa versa for APP to client?
This does add overhead, and you will have to manage a small mapping to keep track of which clients go to which apps, but it might work (assuming the APP or client aren't basing any behavior off of the IP address they are connected to, etc). Assuming you can't recompile APP, there might not be too many other options.
The code for this is relatively simple. Your handler for data recieved from APP just looks up the socket for the appropriate app from your mapping, and then does a non blocking send of this data out on it. Likewise the handler for data recieved from client. Depending on how exactly the clients and app behave, you may have to handle a bit of synchronization (if you recieve from both simultaneously).
I would like to create a connection between two applications. Should I be using Client-Server or is there another way of efficiently communicating between one another? Is there any premade C++ networking client server libraries which are easy to use/reuse and implement?
Application #1 <---> (Client) <---> (Server) <---> Application #2
Thanks!
Client / server is a generic architecture pattern (much like factory, delegation, inheritance, bridge are design patterns). What you probably want is a library to eliminate the tedium of packing and unpacking your data in a format that can be sent over the wire. I strongly recommend you take a look at the protocol buffers library, which is used extensively at Google and released as open source. It will automatically encode / decode data, and it makes it possible for programs written in different languages to send and receive messages of the same type with all the dirty work done for you automatically. Protobuf only deals with encoding, not actually sending and receiving. For that, you can use primitive sockets (strongly recommend against that) or the Boost.Asio asynchronous I/O library.
I should add that you seem to be confused about the meaning of client and server, since in your diagram you have the application talking to a client which talks to a server which talks to another application. This is wrong. Your application is the client (or the server). Client / server is simply a role that your application takes on during the communication. An application is considered to be a client when it initiates a connection or a request, while an application is considered to be a server when it waits for and processes incoming requests. Client / server are simply terms to describe application behavior.
If you know the applications will be running on the same machine, you can use sockets, message queues, pipes, or shared memory. Which option you choose depends on a lot of factors.
There is a ton of example code for any of these strategies as well as libraries that will abstract away a lot of the details.
If they are running on different machines, you will want to communicate through sockets.
There's a tutorial here, with decent code samples.