nicht angemeldet
Hi Christoph,
Also, du traust dir ja was:
gibt es die möglichkeit aus einer php datei auf server A die abarbeitung einer 2. php datei auf server B anzustossen und die erste php datei mit einem rückgabewert über die beendigung der zweiten php datei über deren abschluss informieren?
_eigentlich_ müßte man mit einem empörten NEIN reagieren und dich zart darauf hinweisen, daß PHP dafür zuständig ist, irgendetwas auf _dem_ Server anzustellen, auf dem es grade installiert ist.
Jain. Natürlich hat PHP auf dem Server zu laufen, auf dem auch der Webserver läuft. Aber was macht zum Beispiel ein mysql_connect? Richtig, es connected einen anderen (andersartigen) Server (der u.U. natürlich physisch auf derselben Maschine laufen kann, aber keinesfalls muss).
fsockopen() tut nichts anderes, als ein solches Socket zu einem beliebigen Server zu öffnen, wenn der es erlaubt. Damit kann man nun natürlich SMTP connecten, FTP, oder was immer man will. Und natürlich kann man damit auch einen HTTP-Verbindung aufbauen. Ich verstehe nicht, warum du dich über die Frage aufregst, ich halte diese Vorgehensweise in der Tat für sinnvoll (auch, wenn ich die Motive des Posters nicht billigen kann - ich bleibe einfach mal auf der technischen Schiene ;-)), wenn man über mehrere Server seine Daten "zusammensammeln" muss. Dass geht natürlich nicht nur mit PHP, genauso, wie man damit ein pseudo-CGI-Interface bauen kann, dass PHP mit Perl (oder wasimmer du möchtest) "sprechen" lässt.
Aber:
Prinzipiell ist sowas tatsächlich möglich, bloß fürchterlich umständlich. Dein Client muß von Server A über eine PHP-Abfrage was zugeschickt bekommen, das muß er dann als zweite Abfrage an Server B schicken, dort ein anderes PHP-Script abfragen, dessen Ergebnis wiederum als neue Abfrage an Server A zurücklaufen lassen und dann von dem das endgültige Ergebnis abfordern. Das geht tatsächlich, ist aber viel zu aufwendig und auch ziemlich unsinnig.
Finde ich nicht, man muss bloß HTTP-RFCs lesen und verstehen, alles andere kann das Script ziemlich effizient erledigen, so der zweite Server schnell genug ist.
Welchem Zweck soll denn das Ganze dienen?
Den hat er dir genannt, und *den* kann ich nicht billigen.
In Webseiten, die etwa erwünscht Daten eines (vom Netz aus absichtlich nicht direkt zugänglichen) Intranets bereitstellen sollen *können* so aufgebaut sein und sehr effizient dazu.
Ich hätte auch antworten können: so direkt, wie du es in der Frage formuliert hast, ist das nicht möglich, daß ein PHP-Script auf Server A gewissermaßen "aus eigener Kraft" auf Server B irgendwas anstellt.
Doch, nämlich dann, wenn er sich dort
a) Eine Art PHP-Socket bastelt oder
b) Über fsockopen() an eine Shell rankommt.
Allerdings kann ein Client von mehreren sehr unterschiedlichen Servern jeweils unterschiedliche PHP-Script-Ergebnisse anfordern.
Nur: wenn du in die Adreßzeile deines Browsers eine URL schreibst, fragt dein Browser natürlich bei dieser URL an (hinter der sich Server A verbirgt). Diese Anfrage geht nur in _eine_ Richtung. Das Ergebnis, das er zurückbekommt, kann allerdings die Abfrage einer (oder mehrerer) anderer URL's beinhalten.
Das ist irrelevant, da das angestoßene "primärlevel"-PHP-Script die Rolle eines sekundär-Clients übernimmt.
damit ist nicht include oder require gemeint, die ja die dateien direkt einbinden.
Nein, hier wäre tatsächlich ein empörtes NEIN, und ein zarter Hinweis auf RTFM angebracht. Naja, Nachlesen schadet nicht, und RTFM hilft gelegentlich auch ...
Wie gesagt, da er das nachschob, hielt ich ein RTFM nicht für angebracht, sondern habe eine konstruktive Antwort gegeben. Ich kann ehrlich gesagt nicht ganz nachvollziehen, warum du so empört reagierst.
Was hier gemacht werden soll ist nichts anders, als auch dein Kernel grob gesagt immer mal wieder macht, nämlich Anfragen (da dann eben Programmtechnischer Art) auf (Unix-)Sockets weiterleiten. Wo die (physikalisch oder netzwerktechnisch) liegen ist irrelevant, wenn die Route bekannt und nutzbar ist. Das ist auch der Grund, warum man bald im Internet Rechenkapazität "mieten" werden kann.
Grüße aus Barsinghausen,
Fabian