Nginx is my WEB Server,and there is a TCP Server used for processing data.I want to use fcgi process to communicate with TCP Server,the fcgi process is code in C++.I need a process manager between WEB Server and C++ fcgi.
Actually,I found a C++ fcgi process manager ---- "spawn_fcgi".But in my case,it always lost connections in stress test(maybe the problem came from the C++ fastcgi++2.1，a third party library，but I'm not sure).
Now, I want to change some part to locate problem,but I only find "spawn_fcgi",is there another C++ fcgi process manager?
Anyway,apologize for my bad English and thanks in advance.
Related
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?)
All examples for the subject are based on some C/C++ libraries like fcgi_stdio and similar. But I want to make a FastCGI script, using assembly language and there is no such libraries.
Almost everything about the protocol and communication is clear, but I still can't understand how the program gets the handle to the listening socket, passed by the web server?
My findings:
I installed the lighttpd server and tried to configure it in order to get fastCGI to work with my programs.
But I was confused, that the configuration file needs "host" and "port" - Is this means the FastCGI should create the listening socket by itself? I mean using socket/bind/listen/accept functions? Then how my application will know these host and port parameters. They are in the web server config file?
The other way lighttpd allows is to specify some named socket path - for example "/tmp/myapp.socket". How my application have to handle this? And how it will know this path?
I tried to make some small program using accept(0, ...) as #user58697 specified in his answer (and this answer is in accordance with the official FastCGI specification!) Unfortunately nothing happened - the call to accept fails miserably!
So, is the communication is server specific?
According to the spec, from the application point of view FCGI_LISTENSOCK_FILENO equals to STDIN_FILENO, which is defined as 0. That means that you shall accept(STDIN_FILENO, ...) or even accept(0, ...).
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 want to make my c++ app (running on Linux system) to connect and send data to node.server via socket.
I tried to implement small sample app by using socket.io library (https://github.com/uning/socket.io-client-cpp), but doesnt helping me to achieve my goal.
Any guidance on this or alternative to do something like this.
I'm writing a program in C++ that will run all the time in the background to do different tasks - a deamon.
Apart from it's usual tasks a web application should communicate with it (AJAX requests in doing a COMET pattern = lots of open but sleeping connections).
So the question is: how should I connect it to the web server (apache and lighttpd are relevant)?
Of what I've read FastCGI would be very interesting for that task, but all references I've read were talking about the web server starting the FastCGI application when necessary. This wouldn't work here as the deamon would already be running...
I've also read that the web server would talk via socets with the FastCGI application - so that could be an entry point for me, the deamon would "only" need to talk to such a socket.
But are there good libraries available for that?
Looking at the features of http://cppcms.com/wikipp/en/page/main it looks very interesting for me - but could that work in my case? And could it be stripped down - offering even a SQL connection is far too heavy for my case...
So what advice can you give me?
PS: Performance wise I recon a single threaded but asynchronous implementation would work for the deamon <-> web server glue.
FastCGI is the standard protocol to communicate with the web server. All mentioned web servers can communicate with the remote deamon application via fastcgi.
http://cppcms.com/wikipp/en/page/cppcms_1x_tut_web_server_config
Also if you are looking for Comet support, that what CppCMS provides you natively:
http://blog.cppcms.com/post/107
And could it be stripped down - offering even a SQL connection is far too heavy for my case...
CppCMS library is very small also it allows to reduce its size:
http://cppcms.com/wikipp/en/page/cppcms_1x_build#Build.Options
also SQL connectivity CppDB is independent part.
Performance wise I recon a single threaded but asynchronous implementation would work for the deamon <-> web server glue.
It is one of the standard CppCMS run mode - running asynchronous web applications.
Update:
Of what I've read FastCGI would be very interesting for that task, but all references I've read were talking about the web server starting the FastCGI application when necessary. This wouldn't work here as the deamon would already be running..
Indeed some web servers start the fast cgi applications but:
Lighttpd allows both to start FastCGI and SCGI application or connect to independent one
Cherokee (AFAIR) allows both to start FastCGI and SCGI application or connect to independent one
Apache:
mod_fascgi allows both to start FastCGI application or connect to independent one
mod_scgi connects to independent application - does not start application.
mod_fcgid always starts application - does not suite you
Also as general note, apache does not suit a pattern of working with many idle connections as it uses thread (or even process depending mpm) per connection.
Nginx - does not start applications at all, however for fastcgi currently not the best for comet streaming because of buffering, so SCGI would be better with nginx (assuming you are using latest nginx version)
Small note: SCGI is a protocol that is very similar to FastCGI but significantly simpler.