Fastcgi with C++ and NGINX

Asked

Viewed 168 times

1

I am trying to make a small server for study using fastCGI with C++ without using any library. My problem is that via socket NGINX even connects but does not give me any information about the request, and if I write some callback it generates error 502.

OBS: I’m using a Socket class I created. https://github.com/TigreFramework/Network

Here’s my code C++.

#include "Socket.h"
#include "thread"


using namespace Tigre;


int main(int argc, char *argv[], char** envp)  {
    try {
        Socket *s = new Socket("localhost", 9000, TCP);
        s->Bind(5);
        std::cout << "Esperando Cliente\n";
        Socket *cliente = s->Accept();
        //cliente->Write("\r\n");
        //cliente->Write("Bem vindo ao servidor!");
        std::cout << "Esperando Mensagem do Cliente\n";

        int i = 0;
        while(i < 100) {
            std::cout << "'"<< cliente->Read() << "'" << "\n";
            i++;
        }
    }catch (SocketException &e){
        std:cerr << e.what();
    }
}

Configuration of the NGINX:

worker_processes  1;

events {
    worker_connections  1024;
}

http {
include       mime.types;
default_type  application/octet-stream;

sendfile        on;

keepalive_timeout  65;


server {
    listen       80;
    server_name  localhost;

    location / {
            root           share/nginx/html;

            fastcgi_param REQUEST_METHOD $request_method;
            fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
           fastcgi_param  GATEWAY_INTERFACE  CGI/1.1;
            fastcgi_param  SERVER_SOFTWARE    nginx;
            fastcgi_param  QUERY_STRING       $query_string;
            fastcgi_param  REQUEST_METHOD     $request_method;
            fastcgi_param  CONTENT_TYPE       $content_type;
            fastcgi_param  CONTENT_LENGTH     $content_length;
            fastcgi_param  SCRIPT_FILENAME    $document_root$fastcgi_script_name;
            fastcgi_param  SCRIPT_NAME        $fastcgi_script_name;
            fastcgi_param  REQUEST_URI        $request_uri;
            fastcgi_param  DOCUMENT_URI       $document_uri;
            fastcgi_param  DOCUMENT_ROOT      $document_root;
            fastcgi_param  SERVER_PROTOCOL    $server_protocol;
            fastcgi_param  REMOTE_ADDR        $remote_addr;
            fastcgi_param  REMOTE_PORT        $remote_port;
            fastcgi_param  SERVER_ADDR        $server_addr;
            fastcgi_param  SERVER_PORT        $server_port;
            fastcgi_param  SERVER_NAME        $server_name;
            fastcgi_pass  127.0.0.1:9000;
    }
}

}

EDIT1: I made a change to the line std::cout << "'"<< cliente->Read() << "'" << "\n"; to check if any blank value arrived, and really arrives as you can see below. OBS2 The error only occurs when Nginx generates error 502 and returns to the browser.

Console:

Esperando Cliente
Esperando Mensagem do Cliente
''
'Sem conexão com o Socket.
Process finished with exit code 0
  • in its Socket class the command "socket_ = socket(AF_INET, SOCK_STREAM, 6);" is strange, usually in place of "6" it is used "0"; maybe it even works, but it is strange; now, to debug your application I suggest a network parser like tcark pdump or wireshp

  • I made the correction from "6" to "0", but the result was the same. The funny thing that if I use telnet to connect works perfectly, and if I open via browser direct on port 9000 I get the whole web header.

  • The Socket *cliente = s->Accept(); shouldn’t be inside a loop?

  • Yes, but how it gets locked inside the std::cout << cliente->Read() << "\n"; would never come to expect a new customer, unless I add each new customer into a new one thread.

  • @Pedrosoares just one note: if you want to serve multiple customers without threads you need the loop and non-blocking connection. A state machine is a good way to manage this. If you have a new connection you store it in a list, and attend each of them alternately (always checking for new connections as well, and removing closed connections from the list below).

  • @Bacco of that I know, but in this case as I do not even receive information from Nginx I have not worried about access more than 1 Client, besides I will create a Thread Pool when solving this problem. But thanks anyway.

  • @Pedrosoares yes, but since everything is simple and running in a "console" and not "GUI" I do not see how this will block in fact, of course it will not be an efficient thing, but still has to exist an observer to detect data received by Accept. I believe.

Show 2 more comments
No answers

Browser other questions tagged

You are not signed in. Login or sign up in order to post.