Client-Server-Skript in einem
marco
- php
0 Mega0 marco0 marco0 Sven Rautenberg0 Mega0 Sven Rautenberg0 Mega0 Sven Rautenberg0 Mega
0 dedlfix
Hallo zusammen,
ich arbeite gerade an einem Skript, daß mit socket_create und socket_connect auf einem bestimmten Port Daten zu einem Server schickt. Nun soll es den gleichen Port abfragen, um die Antwort zu erhalten. Nach mittlerweile drei Tagen Bastelei und Suche, bin ich echt am Ende meines Wissens. Das Problem ist wohl der gleiche Port, denn für verschiedene Ports hat es bereits funktioniert. Allerdings erhalte ich auf dem gleichen Port mit socket_bind immer einer Fehler "Error #98: Address already in use", was eigentlich daraufhin deutet, daß der Port nicht mehr genutzt werden kann.
Vielleicht weiß ja jemand von euch Rat.
Ciao
Marco
Vielleicht weiß ja jemand von euch Rat.
Das liegt evtl. daran, dass dein Server zum Senden einen anderen Port verwendet also zum Empfangen. Der Empfang läuft bei HTTP meist auf Port 80. Das Senden auf einen der anderen 65565 Ports (wobei da einige wegfallen, z.B. alle unter 1024).
Ausserdem musst du den Timeout beachten. Du musst ständig (erfahrungsgemäss ca. alle 5 Sekunden) ein Zeichen an den Browser sendne, sonst wird die Verbindung geschlossen und beim nächsten Request wird ein anderer Port benutzt.
Eine Zweiwegeverbindung ist mit einem Browser aber grundsätzlich nicht möglich, da HTTP als Protokoll das nicht ermöglicht. (Request-Response ist das einzige, was geht).
Du musst also immer zwei Verbindungen zum Server aufbauen um eine Zweiwegekommunikation zu erhalten.
Vielleicht weiß ja jemand von euch Rat.
Das liegt evtl. daran, dass dein Server zum Senden einen anderen Port verwendet also zum Empfangen. Der Empfang läuft bei HTTP meist auf Port 80. Das Senden auf einen der anderen 65565 Ports (wobei da einige wegfallen, z.B. alle unter 1024).
Ausserdem musst du den Timeout beachten. Du musst ständig (erfahrungsgemäss ca. alle 5 Sekunden) ein Zeichen an den Browser sendne, sonst wird die Verbindung geschlossen und beim nächsten Request wird ein anderer Port benutzt.
Eine Zweiwegeverbindung ist mit einem Browser aber grundsätzlich nicht möglich, da HTTP als Protokoll das nicht ermöglicht. (Request-Response ist das einzige, was geht).
Du musst also immer zwei Verbindungen zum Server aufbauen um eine Zweiwegekommunikation zu erhalten.
Der Server sendet die Antwort laut Aussage des Serverbetreibers definitiv auf dem gleichen Port (wobei er da natürlich nicht Recht haben muß). Der Timeout ist mit set_time_limit(0); deaktiviert. Die Antwort des Servers könnte man doch als Request-Response verstehen oder?
Eine Zweiwegeverbindung ist mit einem Browser aber grundsätzlich nicht möglich, da HTTP als Protokoll das nicht ermöglicht. (Request-Response ist das einzige, was geht).
Du musst also immer zwei Verbindungen zum Server aufbauen um eine Zweiwegekommunikation zu erhalten.
"For example, the TCP has a request-response pattern protocol". Ich denke also schon, daß eine TCP/IP-Verbindung über den gleichen Port laufen kann.
Moin!
Das liegt evtl. daran, dass dein Server zum Senden einen anderen Port verwendet also zum Empfangen. Der Empfang läuft bei HTTP meist auf Port 80. Das Senden auf einen der anderen 65565 Ports (wobei da einige wegfallen, z.B. alle unter 1024).
Diese Aussage ist Unsinn.
Der Server arbeitet bei HTTP immer auf Port 80, der Client sucht sich für seine Seite einen beliebigen Port (was für den Verbindungsaufbau aber auch nicht relevant ist). Der Datentransfer passiert dann über diese aufgebaute Verbindung zwischen Port 80 (Server) und Port X (Client), und ist grundsätzlich bidirektional.
Ausserdem musst du den Timeout beachten. Du musst ständig (erfahrungsgemäss ca. alle 5 Sekunden) ein Zeichen an den Browser sendne, sonst wird die Verbindung geschlossen und beim nächsten Request wird ein anderer Port benutzt.
Das ist ebenfalls nicht korrekt. Eine TCP-Verbindung bleibt so lange geöffnet, bis sie geschlossen wird. Es wäre grundsätzlich problemlos möglich, ohne ein Byte Datenübertragung die Verbindung eine Woche offen zu haben, um genau dann ein Byte zu senden.
Das wird deshalb nicht gemacht, weil sich mit fortschreitendem Zeitverlauf die genutzte Netzwerkverbindung komplett verändern kann. Fällt sie zwischendurch aus und wird nahtlos wiederhergestellt, merkt das die ungenutzte TCP-Verbindung nicht - aber wenn einer der Kommunikationspartner zwischendurch mit DHCP eine neue IP bekommt, oder abstürzt bzw. neu gestartet wird, würde von der bestehenden Verbindung nichts übrig bleiben, und die andere Seite von der plötzlichen Nichtverfügbarkeit der Verbindung nichts mitbekommen. Deshalb werden auf der darüberliegenden Softwareebene Dinge wie regelmäßiges Heartbeat (Senden von Daten der Bedeutung "Ich bin noch da, will aber gerade nichts") bzw. Timeouts (wenn längere Zeit nichts übertragen wurde, wird die Verbindung als unterbrochen angesehen und getrennt) realisiert.
Auch deinen Erfahrungswert mit HTTP-Timeouts kann ich nicht bestätigen. Browser sind sehr geduldig, was das Warten auf den Server angeht. Zeiträume von mindestens 30 Sekunden bis hin zu mehreren Minuten sind durchaus die Regel. Andernfalls würde wohl kaum ein Server noch sinnvoll erreichbar sein - es gibt auch heutzutage noch sowas wie "Modems", mit denen man extrem langsam Daten überträgt.
Eine Zweiwegeverbindung ist mit einem Browser aber grundsätzlich nicht möglich, da HTTP als Protokoll das nicht ermöglicht. (Request-Response ist das einzige, was geht).
Du musst also immer zwei Verbindungen zum Server aufbauen um eine Zweiwegekommunikation zu erhalten.
Da explizit von einer Socket-Verbindung gesprochen wurde, darfst du davon ausgehen, dass TCP, vielleicht auch UDP, gesprochen wird - und das ist eindeutig bidirektional.
Abgesehen davon deutet die Beschreibung des Vorhabens exakt darauf hin, hier als HTTP-Client per Socket einen HTTP-Server zu kontaktieren und nach Senden des Requests dessen Antwort abzufragen. Also keine zwei Verbindungen.
- Sven Rautenberg
Das ist ebenfalls nicht korrekt. Eine TCP-Verbindung bleibt so lange geöffnet, bis sie geschlossen wird. Es wäre grundsätzlich problemlos möglich, ohne ein Byte Datenübertragung die Verbindung eine Woche offen zu haben, um genau dann ein Byte zu senden.
Und welcher Browser hält eine Woche die Verbindung offen, wenn nur ein Zeichen gesendet wird? Bitte auch mit Versionsangabe. Wieso Browser? s.u.
Da explizit von einer Socket-Verbindung gesprochen wurde, darfst du davon ausgehen, dass TCP, vielleicht auch UDP, gesprochen wird - und das ist eindeutig bidirektional.
Da der OP nichts anderes geschrieben hat, gehe ich von einem Browser aus. Oder hast du gegenteilige Informationen? Oder muss ich gar von einem selbstprogrammierten CLienten ausgehen, wenn der OP von einem Script auf dem Server schreibt?
Moin!
Das ist ebenfalls nicht korrekt. Eine TCP-Verbindung bleibt so lange geöffnet, bis sie geschlossen wird. Es wäre grundsätzlich problemlos möglich, ohne ein Byte Datenübertragung die Verbindung eine Woche offen zu haben, um genau dann ein Byte zu senden.
Und welcher Browser hält eine Woche die Verbindung offen, wenn nur ein Zeichen gesendet wird? Bitte auch mit Versionsangabe. Wieso Browser? s.u.
Ich habe nicht von einem Browser gesprochen, da das Originalproblem keinen Browser erwähnt hat, sondern ausschließlich eine Socket-Verbindung via Netzwerk. Dafür die Socket-Funktionen zu verwenden, und nicht die auf einer höheren Ebene angesiedelten Funktionen wie fsockopen() mit nachfolgendem fwrite()/fread() etc., ist zwar ungewöhnlich, aber nicht unmöglich.
Da explizit von einer Socket-Verbindung gesprochen wurde, darfst du davon ausgehen, dass TCP, vielleicht auch UDP, gesprochen wird - und das ist eindeutig bidirektional.
Da der OP nichts anderes geschrieben hat, gehe ich von einem Browser aus.
Themengebiet "PHP" und folgende Info:
"ich arbeite gerade an einem Skript, daß mit socket_create und socket_connect auf einem bestimmten Port Daten zu einem Server schickt. Nun soll es den gleichen Port abfragen, um die Antwort zu erhalten."
Da ist nirgends von einem Browser die Rede, sondern von einem Skript, welches sich als Client mit einem Server verbindet. Mutmaßlich ein Skript, welches selbst durch einen Browser als Client auf dem skripthostenden Server gestartet wird. Das ist dann aber auch schon der allerdichteste Berührungspunkt zwischen dem Problem und "einem Browser".
Oder hast du gegenteilige Informationen? Oder muss ich gar von einem selbstprogrammierten CLienten ausgehen, wenn der OP von einem Script auf dem Server schreibt?
Lies das OP aufmerksam durch, lies die schon gegebenen Antworten, und erkenne, dass du schlicht auf dem Holzweg bist.
- Sven Rautenberg
Ich habe nicht von einem Browser gesprochen, da das Originalproblem keinen Browser erwähnt hat, sondern ausschließlich eine Socket-Verbindung via Netzwerk.
Hab ich auch nie behauptet. _Ich_ bin von einem Browser ausgegangen, da es IMO das naheliegenste ist in diesem Forum und der OP dahingehend keinerlei ANgaben gemacht hat.
Wenn der OP also die relevanten Angaben für sich behält, muss ich Vermutungen anstellen, die aber auch falsch sein können.
Moin!
Ich habe nicht von einem Browser gesprochen, da das Originalproblem keinen Browser erwähnt hat, sondern ausschließlich eine Socket-Verbindung via Netzwerk.
Hab ich auch nie behauptet. _Ich_ bin von einem Browser ausgegangen...
Wie man angesichts der Fragestellung auf diese Idee kommen kann, wird mir ein Rätsel bleiben.
- Sven Rautenberg
Wie man angesichts der Fragestellung auf diese Idee kommen kann, wird mir ein Rätsel bleiben.
Durch die Kombination "PHP" und "Socket".
Denn ich persönlich würde nie die Serverseite in PHP programmieren, wenn ich auf der Clientseite eine native Anwendung habe.
Das kann aber auch daran liegen, dass ich ausser PHP noch einige andere Programmiersprache kann die mir dafür als sinnvoller erscheinen.
echo $begrüßung;
ich arbeite gerade an einem Skript, daß mit socket_create und socket_connect auf einem bestimmten Port Daten zu einem Server schickt.
Zu klären wäre erstmal, ob du UDP oder TCP oder was ganz anderes machen möchtest.
Nun soll es den gleichen Port abfragen, um die Antwort zu erhalten.
Erkläre den Vorgang bitte genauer. Wann passiert welcher Verbindungsauf- und abbau und wann wird in welche Richtung Daten gesendet?
echo "$verabschiedung $name";
echo $begrüßung;
ich arbeite gerade an einem Skript, daß mit socket_create und socket_connect auf einem bestimmten Port Daten zu einem Server schickt.
Zu klären wäre erstmal, ob du UDP oder TCP oder was ganz anderes machen möchtest.
Nun soll es den gleichen Port abfragen, um die Antwort zu erhalten.
Erkläre den Vorgang bitte genauer. Wann passiert welcher Verbindungsauf- und abbau und wann wird in welche Richtung Daten gesendet?
echo "$verabschiedung $name";
Es geht um eine asynchrone TCP/IP-Kommunikation. Zuerst muß das Skript eine Verbindung zum Server aufbauen und an diesen seine XML-kodierte Anfrage senden. Danach soll es auf die Antwort des Servers warten. Dabei wird der gleiche Port benutzt. Erst am Ende des Skripts wird die Socket-Verbindung wieder geschlossen.
1. socket_out = socket_create
2. socket_connect(socket_out, server-ip, port)
3. socket_write(socket_out, data)
4. socket_in = socket_create
5. socket_bind(socket_in, eigene ip, port)
6. socket_listen(socket_in)
7. incoming = socket_accept(socket_in)
8. socket_read(incoming, 1024)
9. socket_close(incoming)
10. socket_close(socket_in)
11. socket_close(socket_out)
Marco
echo $begrüßung;
Es geht um eine asynchrone TCP/IP-Kommunikation. Zuerst muß das Skript eine Verbindung zum Server aufbauen und an diesen seine XML-kodierte Anfrage senden. Danach soll es auf die Antwort des Servers warten. Dabei wird der gleiche Port benutzt. Erst am Ende des Skripts wird die Socket-Verbindung wieder geschlossen.
Das ist doch ein ganz normales Request-Response-Spielchen. Socket öffnen, Daten hinsenden, Antwort lesen, Socket schließen. Das müsste eigentlich schon mit den Filesystemfunktionen und PHPs eingebautem Protokollwrapper zu erledigen sein.
- socket_out = socket_create
- socket_connect(socket_out, server-ip, port)
- socket_write(socket_out, data)
data = socket_read(socket_out)
socket_close(socket_out)
echo "$verabschiedung $name";
Das ist doch ein ganz normales Request-Response-Spielchen. Socket öffnen, Daten hinsenden, Antwort lesen, Socket schließen. Das müsste eigentlich schon mit den Filesystemfunktionen und PHPs eingebautem Protokollwrapper zu erledigen sein.
- socket_out = socket_create
- socket_connect(socket_out, server-ip, port)
- socket_write(socket_out, data)
data = socket_read(socket_out)
socket_close(socket_out)
Hab ich wohl viel zu kompliziert gedacht. Die Daten, die ich per socket_read erhalten sind allerdings leer, wobei kein Fehler ausgelöst wird (socket_strerror für den Fehlercode 0: Success). Das Problem scheint also noch an einer anderen Stelle zu liegen nehme ich an.
Marco
echo $begrüßung;
Die Daten, die ich per socket_read erhalten sind allerdings leer, wobei kein Fehler ausgelöst wird (socket_strerror für den Fehlercode 0: Success). Das Problem scheint also noch an einer anderen Stelle zu liegen nehme ich an.
DIe Socket-Funktionen können sich blockierend oder nicht blockierend verhalten. Wenn blocking gesetzt ist, wartet ein Lesevorgang, bis Daten eintreffen. Im nonblocking-Mode kommt die Funktion sofort wieder zurück, auch ohne Daten. Da musst du dann selbst für eine Wiederholung der Leseversuche sorgen.
echo "$verabschiedung $name";