proggen.org

Hi,

wie sich im anderen Thread herauskristallisert hat, suche ich eine Möglichkeit zwischen einem Webserver und einer nativen Anwendung zu kommunizieren. Das soll heißen:

• Mittels Webserver (z.B. Apache) läuft eine Webseite. Gehen wir hier mal von PHP aus.
• Parallel dazu läuft eine native Anwendung, die zur Behandlung der Eingaben usw. genutzt werden soll. Nehmen wir hier mal ein C++-Programm.
• Nun möchte ich eine Client-Anfrage XY an das native Programm weiterleiten, so dass dieses die notwendigen Aktionen und Berechnungen durchführt, und anschließend ein "Datenpaket" zurückgibt, anhand dessen PHP dann ein Template befüllen und zurückliefern kann.

Eine Möglichkeit die mir einfällt, sind Sockets. Ich habe bisher an einem Netzwerk-Framework (C++, auf Basis von SDL_net) inklusive einer JSON-Implementierung geschrieben. Nun überlege ich das Framework dafür zu verwenden:

Es stellt eine Client-Server-Struktur bereit, über die ich kommunizieren könnte. Wrappe ich diese mit SWIG, könnte prinzipiell eine PHP-Anwendung (oder auch eine in einer anderen Sprache geschrieben Applikation) mit dem Server (den ich in das native Programm integriere) kommunizieren:

• Mit der nativen Anwendung läuft ein lokaler Server, für die interne Kommunikation.
• Wird ein PHP-Aufruf ausgelöst, lädt PHP die gewrappte Extension (zur Kommunikation mit dem Server, die Extension beeinhaltet nicht den Server^^) und erzeugt einen neuen Client, der sich lokal mit dem Server (native Anwendung) verbindet. Dann werden die Daten (GET/POST Daten, Client-Informationen) in ein JSON-Objekt gepackt und der nativen Anwendung geschickt.
• Die native Anwendung macht damit was auch immer sie will und gibt dem lokalen Client (PHP-Anwendung) eine Antwort in Form eines JSON-Objekts.
• Die PHP-Anwendung erhält das PHP-Objekt, lädt entsprechend ein Template und füllt es (das ließe sich ja alles mit dem JSON-Objekt beschreiben).

Damit verknüpfe ich nicht nur eine native Anwendung (und i.d.R. schnellere Bearbeitung der Anfrage) mit einem beliebigen Webserver, sondern trenne auch Logik (natives Programm) und Ausgabe (via Templates im PHP).

Effektiv müsste ich die Kommunikation einmal implementieren und für PHP wrappen. Anschließend kann ich den eigentlichen Server implementieren und dem PHP-Skript einige Templates zur Verfügung stellen und ihm sagen, welche Templates er wie füllen soll wenn eine Antwort XY vom nativen Server kommt.

Was haltet ihr davon? Sinnvoll? Oder habt ihr sogar bessere Vorschläge?

LG Glocke

Glocke hat geschrieben:Was haltet ihr davon? Sinnvoll? Oder habt ihr sogar bessere Vorschläge?

Okay, Anfrage des Spielers an Apache, Apache leitet die Anfragen an PHP, PHP macht aus der Anfrage ein JSON-Objekt daraus, stellt eine Netzwerkanfrage an Deinen Netzwerkdienst, der nimmt das JSON-Objekt auseinander, bearbeitet es, packt die Antwort in ein JSON Objekt, PHP packt es aus, formatiert es zu HTML und liefert eine Antwort.

Oder kurz: Man kann auch mit der Zange den Nagel in die Wand schlagen.

Der eine sagt "Endlich mal einer, der ein Problem schnell und ohne viel Aufwand mit dem löst, was er gerade zur Hand hat", der andere sagt "Ein Professioneller hätte wohl einen Hammer genommen."
Beide haben recht.

Xin hat geschrieben:Der eine sagt "Endlich mal einer, der ein Problem schnell und ohne viel Aufwand mit dem löst, was er gerade zur Hand hat", der andere sagt "Ein Professioneller hätte wohl einen Hammer genommen."
Beide haben recht.

Der "Hammer" (für den Nagel^^) wäre dann ein reiner C++-Webserver, richtig?

Xin hat geschrieben:Der eine sagt "Endlich mal einer, der ein Problem schnell und ohne viel Aufwand mit dem löst, was er gerade zur Hand hat", der andere sagt "Ein Professioneller hätte wohl einen Hammer genommen."
Beide haben recht.

...Du bist doch ein oller C++-Faschist
Es wäre falsch zu sagen, dass der "Hammer" besser als die "Zange" ist. Der "Hammer" kann den "Nagel" auch so hart in die Hauen, dass die Wand ein Loch hat. Bei der "Zange" kann es vorkommen, das der "Nagel" nicht richtig in der Wand ist. Es liegt an dir

Glocke hat geschrieben:Der "Hammer" (für den Nagel^^) wäre dann ein reiner C++-Webserver, richtig?

Richtig. Du machst Dir hier mehr den McGyver.

Xin hat geschrieben:Richtig. Du machst Dir hier mehr den McGyver.

Ich bin immer offen für weitere Vorschläge ;D

Glocke hat geschrieben:

Xin hat geschrieben:Richtig. Du machst Dir hier mehr den McGyver.

Ich bin immer offen für weitere Vorschläge ;D

Es sind beides akzeptable Methoden. Der Server in C++ wäre die saubere, aber aufwändigere Lösung. Den Umweg über PHP halte ich für frickelig, aber sogar die üblichere "Technik". Vielleicht kannst Du die HTTP-Anfragen über Apache verarbeiten, aber statt PHP zu rufen, direkt nach C++ gehen, in dem Du ein Modul zu Apache schreibst: Du verlierst die Abhängigkeit, wirfst eine interpretierende Sprache raus, die zur Wartung Deines Projektes notwendig ist und bei der Du keine Ahnung hast, welche Bugs zwischenzeitlich mal Deine User verärgern, weil Dein Projekt auf einmal Fehler wirft...

Für mich war der Hauptgrund für einen eigenen Webservice, dass der Apache recht groß ist und tausende Sachen konfigurieren kann, ich aber gerne einen schlanken Webservice möchte und soviel wie möglich an Arbeitsspeicher zum Cachen nutzen möchte.

Xin hat geschrieben:

Glocke hat geschrieben:

Xin hat geschrieben:Richtig. Du machst Dir hier mehr den McGyver.

Ich bin immer offen für weitere Vorschläge ;D

Es sind beides akzeptable Methoden. Der Server in C++ wäre die saubere, aber aufwändigere Lösung. Den Umweg über PHP halte ich für frickelig, aber sogar die üblichere "Technik". Vielleicht kannst Du die HTTP-Anfragen über Apache verarbeiten, aber statt PHP zu rufen, direkt nach C++ gehen, in dem Du ein Modul zu Apache schreibst: Du verlierst die Abhängigkeit, wirfst eine interpretierende Sprache raus, die zur Wartung Deines Projektes notwendig ist und bei der Du keine Ahnung hast, welche Bugs zwischenzeitlich mal Deine User verärgern, weil Dein Projekt auf einmal Fehler wirft...

Für mich war der Hauptgrund für einen eigenen Webservice, dass der Apache recht groß ist und tausende Sachen konfigurieren kann, ich aber gerne einen schlanken Webservice möchte und soviel wie möglich an Arbeitsspeicher zum Cachen nutzen möchte.

Ich überlege einfach den "anderen Standardweg" zu nehmen: erstmal normal in PHP, Kommunikation mit der MySQL-Datenbank. Und dazu für "Hintergrundberechnungen" (Kämpfe, eigentliche Spiellogik) ein C++ Programm, das mit der gleichen MySQL Datenbank redet. Dann erzeugt PHP nur die HTML-Oberfläche und füllt sie mit Daten aus der Datenbank.

Hallo,
also, es ist auch nicht so schwierig, ein Modul für PHP zu schreiben. PHP ist ja in C entwickelt. Ein eigenes C-Modul läßt sich auf dem Server integrieren und direkt von PHP aus aufrufen. Das finde ich den saubersten Weg in Deinem Fall.

Ich persönlich nehme garkein PHP sondern habe Apache-Module und ein eigenes C/C++-Framework für Webanwendungen.

mareb hat geschrieben:Ich persönlich nehme garkein PHP sondern habe Apache-Module und ein eigenes C/C++-Framework für Webanwendungen.

Kannst Du mir was zu den Apache-Modulen erzählen?