Sven Rautenberg: Client-Server-Skript in einem

Beitrag lesen

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

--
"Love your nation - respect the others."