C++-Programm als Webserivce in Webserver einbinden
-
Hallo zusammen! Ich bin bei der Webentwicklung eine Weile aus dem Loop und würde gerne wissen, was heutzutage die bevorzugten Methoden sind, ein C- oder C++-Programm mithilfe eines vorgeschalteten Webservers auf HTTP(S)-Requests antworten zu lassen.
Ich bin gerade dabei nach Ansätzen zu recherchieren und suche eigentlich nur ein paar Stichworte zu weiteren einlesen, wobei ich gerne vermeiden würde, mich zu tief in eventuell bereits veraltete Techniken einzuarbeiten. CGI, FastCGI und SCGI sind mir ein Begriff - hat sich da über die Jahre noch etwas getan, oder sind das immer noch angesagte Methoden?
Wichtig sind mir dabei gute Performance, Skalierbarkeit und möglichst wenig Berührungspunkte mit den Details von Netzwerkprogrammierung und dem HTTP-Protokoll. Das sollen mal schön alles der Webserver und weitere vorgeschaltete Dienste machen (die bevorzugt auch frei wählbar sein sollten - Apache, nginx, etc.).
-
FastCGI ist nachwievor der bevorzugte weg. Performance und scalability sind schwer zu schlagen, besonders da es in dieser Richtung wenig technischen fortschritt gibt.
Optional gibt es so spielereien wie das hier, aber usability technisch wuerde ich das nicht empfehlen.
-
@Cardiac sagte in C++-Programm als Webserivce in Webserver einbinden:
FastCGI ist nachwievor der bevorzugte weg. Performance und scalability sind schwer zu schlagen, besonders da es in dieser Richtung wenig technischen fortschritt gibt.
Danke. Ich hatte schon den Verdacht, wollte aber sicher gehen nichts zu übersehen. Ich denke ich werde erstmal etwas mit SCGI experimentieren und FastCGI im Hinterkopf behalten, wenn ich mehr Flexibilität benötige. Eigentlich brauche ich nur simple Request->Antwort Funktionalität, auch Session-Tokens würden ebenfalls mit diesem Request gesendet.
Schön wäre, wenn der Webserver gleich eine ganze Reihe Instanzen meines Programms startet und den nächsten Request dann selbständig die Instanz weiterleitet, die gerade nichts (oder am wenigsten) zu tun hat. Da geht sicher was in die Richtung, werde da mal weiter recherchieren.
Optional gibt es so spielereien wie das hier, aber usability technisch wuerde ich das nicht empfehlen.
Das sieht mir aus wie ein Webserver-Modul, ohne sich zu sehr mit den Modul-API-Details des Webservers auseinandersetzen zu müssen. Das dürfte vom Performance-Overhead etwa gleichauf mit einem eigenen Modul liegen, hat aber den Nachteil, dass es nicht zwischen Webserver-Implementierungen portabel ist und der eigene Code auch direkt im Webserver-Prozess ausgeführt wird.
Es stimmt schon, das ist wahrscheinlich fummelig damit zu arbeiten, vor allem wenn ich schon solche Sachen wie ein nginx-
mallocsehe, bin ich skeptisch, wie gut sich das mit vorhandenem C++-Code verträgt. In einem eigenen Prozess dürfte man da mehr Freiheiten haben.
-
Da du das protokoll ja sowieso nicht (selbst) anfassen willst, stellt sich mir die frage ob du fastCGI ueberhaupt verwenden muesstest.
Wenn du bspw. Beast/Boost als protocol layer verwendest, kannst du nginx (als beispiel) ja einfach als reverse proxy benutzen und daten viaproxy_passauf ein unix socket schieben.Ich vermute mal, dass beast et al sowas von haus aus supporten.
-
@Cardiac sagte in C++-Programm als Webserivce in Webserver einbinden:
Beast/Boost ... reverse proxy
Auch ne interessante Idee. Wenn ich das richtig verstehe, hole ich mir damit allerdings die potentielle Angriffsfläche der HTTP-Protokollimplementierung via Beast in meine eigene Software (etwas mehr Pflegebedarf, da es dann nicht nur mit einem Webserver-Update getan wäre) - hat aber den Vorteil, dass sie dann auch als Standalone zu betreiben wäre und das Ganze wahrscheinlich simpler umzusetzbar ist, besonders wenn ich mir die FastCGI-Spezifikation so anschaue.
Erstmal sehen was mit SCGI so geht, die Sache mit dem Reverse Proxy behalte ich aber mal im Hinterkopf, vielleicht ergeben sich ja noch andere Probleme, die sich damit auch erschlagen lassen
