posix sockets, tcp/ip und ende der Übertragung
-
Hi Leuts,
Ich beschäftige mich bezüglich meines Studiums gerade mit POSIX Sockets.
Ich versuche sowohl Client als auch Server aufzusetzten. Klappt eigentlich ganz gut. Was mir jedoch Kopfschmerzen bereitet ist das mitteilen des Endes einer Übertragung. Mein Client sendet eine Textnachricht mittels "write" an den Server. Der Soll diese ausgeben, wenn er sie erhalten hat. Genauer soll der Server solange "read" ausführen, bis er das ende der Übermittlung erhalten hat. Das Klappt auch, wenn mein Client die Verbindung wieder schließt mir close. Das blockende "read" des Servers wird verlassen und die Nachricht ausgegeben. Was aber wenn ich die Verbindung nicht jedes mal kappen will nur um sie im Anschluss direkt wieder aufzubauen. Also eine Permanente Verbindung zwischen Client und Server. Muss ich selbst irgend eine Zeichenkette festlegen, die der Server entsprechend zu interpretieren hat. oder gibt es in eine Möglichkeit ein EOF an den Server zu schicken ohne eben die Verbindung zu kappen? Oder ist das vielleicht eine dumme Idee? confused:MFG
Martin
-
Hallo,
Du musst dafür ein Protokoll definieren, womit der Server das Ende der Übertragung feststellen kann. Anders geht es nicht.
Eine TCP/IP-Verbindung schickt lediglich einen Strom von Bytes. Es gibt kein besonderes EOF-Zeichen.
-
Die schlechte Lösung: Ein Zeichen, um das Ende zu markieren. Zum Beispiel ein Null-Byte.
Die gute Lösung: Man sendet zuerst die Länge.
-
TyRoXx schrieb:
Die gute Lösung: Man sendet zuerst die Länge.
Man darf dabei aber nicht vergessen, dass man dem Nutzer nicht trauen kann. Also auf gar keinen Fall die Nachricht ausgeben, wenn man nicht ganz sicher ist, dass man sie auch komplett empfangen hat! Sonst hat man Heartbleed.
Das soll nicht heißen, dass die Idee mit der Längenangabe schlecht ist, sondern dass man trotzdem aufpassen muss, diese nicht falsch mit einer anderen Methode zu kombinieren.
-
SeppJ schrieb:
TyRoXx schrieb:
Die gute Lösung: Man sendet zuerst die Länge.
Man darf dabei aber nicht vergessen, dass man dem Nutzer nicht trauen kann. Also auf gar keinen Fall die Nachricht ausgeben, wenn man nicht ganz sicher ist, dass man sie auch komplett empfangen hat! Sonst hat man Heartbleed.
Das soll nicht heißen, dass die Idee mit der Längenangabe schlecht ist, sondern dass man trotzdem aufpassen muss, diese nicht falsch mit einer anderen Methode zu kombinieren.
Das wäre einfach nur ein Programmierfehler. Sonst nichts. Dass die Nachricht möglicherweise in mehreren read-Aufrufen verteilt ist, muss immer berücksichtigt werden und hat gar nichts damit zu tun, ob man dem Client vertrauen kann.
-
tntnet schrieb:
SeppJ schrieb:
TyRoXx schrieb:
Die gute Lösung: Man sendet zuerst die Länge.
Man darf dabei aber nicht vergessen, dass man dem Nutzer nicht trauen kann. Also auf gar keinen Fall die Nachricht ausgeben, wenn man nicht ganz sicher ist, dass man sie auch komplett empfangen hat! Sonst hat man Heartbleed.
Das soll nicht heißen, dass die Idee mit der Längenangabe schlecht ist, sondern dass man trotzdem aufpassen muss, diese nicht falsch mit einer anderen Methode zu kombinieren.
Das wäre einfach nur ein Programmierfehler. Sonst nichts. Dass die Nachricht möglicherweise in mehreren read-Aufrufen verteilt ist, muss immer berücksichtigt werden und hat gar nichts damit zu tun, ob man dem Client vertrauen kann.
Kümmert sich deine Programmlogik etwa um die Details der Kommunikation?
-
SeppJ schrieb:
tntnet schrieb:
SeppJ schrieb:
TyRoXx schrieb:
Die gute Lösung: Man sendet zuerst die Länge.
Man darf dabei aber nicht vergessen, dass man dem Nutzer nicht trauen kann. Also auf gar keinen Fall die Nachricht ausgeben, wenn man nicht ganz sicher ist, dass man sie auch komplett empfangen hat! Sonst hat man Heartbleed.
Das soll nicht heißen, dass die Idee mit der Längenangabe schlecht ist, sondern dass man trotzdem aufpassen muss, diese nicht falsch mit einer anderen Methode zu kombinieren.
Das wäre einfach nur ein Programmierfehler. Sonst nichts. Dass die Nachricht möglicherweise in mehreren read-Aufrufen verteilt ist, muss immer berücksichtigt werden und hat gar nichts damit zu tun, ob man dem Client vertrauen kann.
Kümmert sich deine Programmlogik etwa um die Details der Kommunikation?
Ich verstehe Deine Schlussfolgerung nicht. Wenn ich das Kommunikationslayer implementiere, dann muss ich mich darum kümmern, dass nur vollständige Nachrichten weiter gegeben werden. Meiner Applikationslogik ist es doch egal, ob die Nachricht mit Längenangabe übertragen wird oder nicht. Hauptsache, meine Nachricht wird korrekt übertragen.
Ich gehe bei meinen Applikationen sogar noch einen Schritt weiter. Ich habe ein Serialisierungsframework, welches Objekte verschickt und empfängt. Und zwar alles garantiert vollständig. Die Applikation schickt oder empfängt nicht einfach nur ein Haufen Bytes sondern ein Objekt. Also mache ich mir so gar keine Gedanken mehr über Längenbytes oder so was.
-
tntnet schrieb:
SeppJ schrieb:
tntnet schrieb:
SeppJ schrieb:
TyRoXx schrieb:
Die gute Lösung: Man sendet zuerst die Länge.
Man darf dabei aber nicht vergessen, dass man dem Nutzer nicht trauen kann. Also auf gar keinen Fall die Nachricht ausgeben, wenn man nicht ganz sicher ist, dass man sie auch komplett empfangen hat! Sonst hat man Heartbleed.
Das soll nicht heißen, dass die Idee mit der Längenangabe schlecht ist, sondern dass man trotzdem aufpassen muss, diese nicht falsch mit einer anderen Methode zu kombinieren.
Das wäre einfach nur ein Programmierfehler. Sonst nichts. Dass die Nachricht möglicherweise in mehreren read-Aufrufen verteilt ist, muss immer berücksichtigt werden und hat gar nichts damit zu tun, ob man dem Client vertrauen kann.
Kümmert sich deine Programmlogik etwa um die Details der Kommunikation?
Ich verstehe Deine Schlussfolgerung nicht. Wenn ich das Kommunikationslayer implementiere, dann muss ich mich darum kümmern, dass nur vollständige Nachrichten weiter gegeben werden. Meiner Applikationslogik ist es doch egal, ob die Nachricht mit Längenangabe übertragen wird oder nicht. Hauptsache, meine Nachricht wird korrekt übertragen.
Eben das mahne ich an. Da ein Teil der Nachricht eine Längeninformation durch die Gegenseite ist, muss man bei der korrekten Übertragung die Möglichkeit einer bewussten Störung in Betracht ziehen.
