ubuntuusers.de

Folgende Situation: Mein Netzwerk Client schickt eine Statusabfrage zum Server und bekommt:

http://127.0.0.1:8081/file_01?stat
HTTP/1.1 404 FILE NOT FOUND.
Date: Mon, 02 Jan 2023 16:56:26 GMT
Server: thumb_server 0.3
Accept-Ranges: none
Content-Length: 190
Connection: Keep-Alive

zurück. Die anschließenden HTML Daten will ich aber nicht auswerten. Daher wollte ich jetzt auf das Abholen der Daten verzchten, wenn der Statuscode nicht 200 ist. Leider habe ich dabei übersehen, dass der Empfangsteil, der hier nichts findet, auch den Socket Descriptor schließt. Den darf ich also nicht überspringen, denn jeder Fehler gelegt einen neuen Socket.

Die Frage ist jetzt, muss ich die Daten trotzdem abholen, also den Empfangspuffer leeren, oder kann ich den Socket "einfach so" schließen? Im Netz habe ich bisher nur Angaben zur Server Seite gefunden.

Edit: Tippfehler

Dakuan schrieb:

Leider habe ich dabei übersehen, dass der Empfangsteil, der hier nichts findet, auch den Socket Descriptor schließt. Den darf ich also nicht überspringen, denn jeder Fehler gelegt einen neuen Socket.

Ich bin mir nicht sicher, was Du hier meinst. Generell würde ich eine Bibliothek für HTTP benutzen, z.B. libcurl.

Die Frage ist jetzt, muss ich die Daten trotzdem abholen, also den Empfangspuffer leeren, oder kann ich den Socket "einfach so" schließen? Im Netz habe ich bisher nur Angaben zur Server Seite gefunden.

Alle Prozesse, die Netzwerken, müssen immer damit rechnen, dass eine Verbindung zu jeder Zeit geschlossen wird oder zusammen bricht. Nicht zuletzt Sicherheitssoftware (IPS, manche Firewalls) schließt Verbindungen.

Wenn Du vorher weißt, dass Du den Inhalt nicht willst, böte sich ein HEAD-Request an.

Noch ein Punkt: da Du HTTP/1.1 nutzt, ist es vielleicht doch ratsam, einfach den Inhalt zu lesen und zu verwerfen. Dann sparst Du Dir den neuen Verbindungsaufbau. Ist halt immer eine Abwägungssache.

Alle Prozesse, die Netzwerken, müssen immer damit rechnen, dass eine Verbindung zu jeder Zeit geschlossen wird oder zusammen bricht.

Das ist klar. Ich wollte auch wissen, was mir den bereits empfangenen Daten passiert, die der Kernel wohl irgendwo noch gespeichert hat, also ob dadurch ein Speicherleck entstehen kann, wenn die Daten nicht abgeholt werden.

Wenn Du vorher weißt, dass Du den Inhalt nicht willst, ...

Ich will den Inhalt ja haben, aber nur wenn der Server die Datei gefunden hat. Bei Erfolg sollen dann noch weitere Aktionen folgen z.B. der Empfang von Binärdaten.

Noch ein Punkt: da Du HTTP/1.1 nutzt, ist es vielleicht doch ratsam, einfach den Inhalt zu lesen und zu verwerfen.

Ok, dann baue ich da mal ein Dummy-Read ein. Und wenn der Server "text/plain" sendet, könnte ich das sogar als Meldung anzeigen.

Dakuan schrieb:

Alle Prozesse, die Netzwerken, müssen immer damit rechnen, dass eine Verbindung zu jeder Zeit geschlossen wird oder zusammen bricht.

Das ist klar. Ich wollte auch wissen, was mir den bereits empfangenen Daten passiert, die der Kernel wohl irgendwo noch gespeichert hat, also ob dadurch ein Speicherleck entstehen kann, wenn die Daten nicht abgeholt werden.

Überleg mal: würde das Internet funktionieren, wenn der Linux-Kernel dieses Problem hätte?

Noch ein Punkt: da Du HTTP/1.1 nutzt, ist es vielleicht doch ratsam, einfach den Inhalt zu lesen und zu verwerfen.

Ok, dann baue ich da mal ein Dummy-Read ein. Und wenn der Server "text/plain" sendet, könnte ich das sogar als Meldung anzeigen.

Könnte schneller sein, als die Verbindung zu kappen und neu aufzubauen.

Ok, Du hast mich überzeugt. Meine Unsicherheit liegt wohl daran, dass mein Englisch nicht so dolle ist und ich damit schon öfters auf die Nase gefallen bin.

Könnte schneller sein, als die Verbindung zu kappen und neu aufzubauen.

Geschwindigkeit ist an dieser Stelle nicht das Problem, eher die Netzlast bei schlechtem W-LAN oder wie schnell der User klicken kann. Oder natürlich, wenn große Video Dateien zu übertragen sind. Aber da verwende ich auf der Server Seite sendfile(). Mehr kann man da wohl nicht machen.

Dakuan schrieb:

Geschwindigkeit ist an dieser Stelle nicht das Problem, eher die Netzlast bei schlechtem W-LAN oder wie schnell der User klicken kann. Oder natürlich, wenn große Video Dateien zu übertragen sind.

Aber das passiert ja üblicherweise im Erfolgsfall, wo Du den Inhalt auch wirklich herunterladen willst. Die Seite mit der Fehlermeldung ist vermutlich eher kleiner.

Aber da verwende ich auf der Server Seite sendfile(). Mehr kann man da wohl nicht machen.

Vielleicht bietet libcurl da ja auch etwas an.

Die Seite mit der Fehlermeldung ist vermutlich eher kleiner.

Steht ja in meinem ersten Post, 190 Bytes.

Vielleicht bietet libcurl da ja auch etwas an.

Glaube ich nicht. Jedenfalls habe ich bei meinem ersten Besuch auf der Projektseite keine Hinweise darauf gefunden. Der Trick bei sendfile() ist ja, das alles im Kernelspace abgehandelt wird. Der Bremser wird das Netzwerk sein.

Aber libcurl sieht interessant aus. Zumal da auch SMB dabei ist. Aber bevor ich damit etwas mache, werde ich mich wohl noch mit autoconf und automake befassen müssen. Und ich benötige für meine Anwendung auch nicht das komplette Protokoll. Das ist nur eine zusätzliche Option in meinem Programm.

Ursprünglich wollte ich boost-asio verwenden (weil das in meinem Buch so empfohlen wurde), aber als ich die unendlich lange Liste der Abhängigkeiten gesehen hatte, hatte ich mich dann entschieden das mit dem zu machen, was sowieso schon da ist. Trotz der Bemerkung eines Experten hier, dass man sich so etwas nicht antun sollte.

Dakuan schrieb:

Vielleicht bietet libcurl da ja auch etwas an.

Glaube ich nicht. Jedenfalls habe ich bei meinem ersten Besuch auf der Projektseite keine Hinweise darauf gefunden. Der Trick bei sendfile() ist ja, das alles im Kernelspace abgehandelt wird. Der Bremser wird das Netzwerk sein.

In dem Fall meinte ich Funktionalität, die den Rest des HTTP-Bodies liest und verwirft - also die Clientseite.

Aber libcurl sieht interessant aus. Zumal da auch SMB dabei ist. Aber bevor ich damit etwas mache, werde ich mich wohl noch mit autoconf und automake befassen müssen. Und ich benötige für meine Anwendung auch nicht das komplette Protokoll. Das ist nur eine zusätzliche Option in meinem Programm.

Ja, autoconf und automake stehen schon ganz lange auf meiner "Wenn ich mal Zeit habe"-Liste. ☺

Ursprünglich wollte ich boost-asio verwenden (weil das in meinem Buch so empfohlen wurde), aber als ich die unendlich lange Liste der Abhängigkeiten gesehen hatte, hatte ich mich dann entschieden das mit dem zu machen, was sowieso schon da ist.

In der Firma haben wir auch eine geplante Tätigkeit, boost so weit wie möglich loszuwerden. Zum einen bringt die C++-Standardbibliothek mittlerweile Dinge mit, für die man früher boost gebraucht hat. Zum anderen ist das Debuggen durch viele Templates oft schwierig.

Trotz der Bemerkung eines Experten hier, dass man sich so etwas nicht antun sollte.

Sind halt alles Abwägungen - immer. ☺

Ja, autoconf und automake stehen schon ganz lange auf meiner "Wenn ich mal Zeit habe"-Liste. ☺

Und ich dachte, ich bin wieder mal der einzige, der das vor sich herschiebt.

In der Firma haben wir auch eine geplante Tätigkeit, boost so weit wie möglich loszuwerden.

Den, den es trifft beneide ich nicht. Liegt aber möglicherweise auch daran, dass ich von boost keine Ahnung habe (wg. Vermeidung).

Sind halt alles Abwägungen - immer. ☺

Ja, aber als Hobbyprogrammierer habe ich keinen Chef, der mir Vorgaben macht. Ich darf meine Prioritäten selber setzen und meine Fehler selber machen und (hoffentlich) daraus lernen. Vermutlich habe ich durch die Anwendung der grundlegenden Funktionen mehr gelernt, als durch die Anwendung fertiger Rezepte. Ich bevorzuge, externe Abhängigkeiten möglichst zu vermeiden, auch wenn mir das in der Vergangenheit als unnötiger Kleinkram vorgeworfen wurde.