Socket C&S

[tomkupitz]

Puffer zusammenpacken ist an sich kein Problem. Nur der Bezug zum Socket war mir wichtig.

Es sieht so aus, als wäre die max. Größe eines Blocks ein High(Word). Ich werde versuchen schon beim Versenden diese max. Blockgröße nicht zu überscheiten.

[stahli]

Vielleicht hilft Dir der Thread noch etwas weiter: http://www.delphipraxis.net/190482-s...ockettest.html

[Zacherl]

Zitat von tomkupitz:

Es sieht so aus, als wäre die max. Größe eines Blocks ein High(Word). Ich werde versuchen schon beim Versenden diese max. Blockgröße nicht zu überscheiten.

Versuch dein Glück, wenn du auf Redeemer und mich nicht hören willst, aber erwarte nicht, dass es zuverlässig funktioniert.

Die 65k bzw. mitlerweile meisten 256k, von denen man öfters mal liest, beziehen sich auf die Größe des internen Empfangs-Buffers unter Windows und nicht auf die MTU. Die EINZIGE zuverlässige Methode bei TCP ist eine eigene Pakettrennung. Denn selbst, wenn du es schaffen würdest dich immer korrekt an der MTU zu orientieren, dann schützt dich das weiterhin nicht davor, dass mehrere kleine Pakete zu einem großen Datenblock auf Empfängerseite zusammengefügt werden.

Mein Beispiel verwendet zwar keine Sockets, simuliert aber beide der primären Situationen, die beim Versand von Daten per TCP Socket auftreten und ist demnach absolut das, was du haben möchtest. Die Recv Methode kannst du praktisch 1 zu 1 übernehmen und mit den Daten des Sockets füllen und beim Send schickst du halt schnell einen UInt32 mit der Gesamtdatenmenge des Pakets vorweg. Ist kein großer Aufwand.

[tomkupitz]

Zitat:

Versuch dein Glück, wenn du auf Redeemer und mich nicht hören willst, aber erwarte nicht, dass es zuverlässig funktioniert.

Alles gut. Ich habe eure Beispiele probiert. Danke dafür.

Ergebnis meiner Tests: Es scheint ein Zeitproblem zu geben. Baue ich eine Pause nach jedem

Code:

if ServerSocket.Socket.ActiveConnections>0 then
  ServerSocket.Socket.Connections[0].SendBuf(...);

ein kommt auch alles an.

[Zacherl]

Zitat von tomkupitz:

Ergebnis meiner Tests: Es scheint ein Zeitproblem zu geben. Baue ich eine Pause nach jedem

Sorry, aber ... Die "Pause" löst dein Problem in keinster Weise.

[himitsu]

Zitat von Zacherl:

Zitat von tomkupitz:

Ergebnis meiner Tests: Es scheint ein Zeitproblem zu geben. Baue ich eine Pause nach jedem

Sorry, aber ... Die "Pause" löst dein Problem in keinster Weise.

Ist das Netz langsamer als deine Pause, dann mußt du die Pause weiter vergrößern, sonst knallt es wieder.
Und hängt es mal noch mehr, ...


Besser du baust sicherheitshalber gleich ein Sleep(3600000); ein.

[tomkupitz]

Zitat:

Sorry, aber ... Die "Pause" löst dein Problem in keinster Weise.

Genau so sehe ich das auch. Bisher habe ich aber noch keine "saubere" Übertragung für meinen Kontext gefunden.

[jfheins]

TCP ist immer ein "Stream", das heißt die Daten können schlimmstenfalls byteweise ankommen. (Bytes kommen aber immer ganz oder gar nicht an, darauf kann man sich zum Glück verlassen )

Ich habe das damals so gelöst, dass ich einen struct/record mit den Nutzdaten verschickt habe (konstante Länge). Auf Empfangsseite habe ich einen passend dimensionierten Puffer vorgehalten. Immer, wenn was angekommen ist, habe ich die Daten (in einer Schleife, solange neue Daten da waren!) ein Byte nach links geschoben, ein Byte neue Daten hinten angehängt und geprüft ob das ein gültiges Paket ist. (Konstante prüfen plus Checksumme)
Bei einem gültigen Paket wurde ein Callback ausgelöst.

Du kannst auch immer einen Längenwert vor die Daten schreiben. Oder ein Trennzeichen (Zeilenumbruch) zwischen die Daten. Du brauchst irgendein Verfahren, um deine Daten in einen kontinuierlichen Stream zu schreiben und (kniffeliger) sie aus einem kontinuierlichen Stream wieder herauszufischen.

Ich bin mir nicht sicher, was du mit "sauberer Übertragung" meinst. Um noch deine ursprüngliche Frage zu beantworten:

Zitat:

Wie groß darf buf max. sein? Oder kann erzwingen das alles komplett empfangen werden kann?

Ein Byte. Alles über einem Byte kann zerstückelt ankommen.

[stahli]

Du kannst halt nie sicher sagen, wann welche Paketteile auf der anderen Seite ankommen.

Wenn Du etwa sendest:
---
Dies
ist
Paket
1
---
Jetzt
kommt
Paket
2
---

kann auf der anderen Seite ankommen:
---
Dies
ist
Paket
1
Jetzt
kom
---
mt
Paket
2
---

oder alles in einem Block oder in 3 Blöcken.

Du musst also die Eingangsdaten puffern und selbst ermitteln, ob ein vollständiges Paket vorliegt, welches Du verarbeiten kannst.
Dabei können aber auch schon Daten für 2 und 1/4 weitere Pakete im Puffer vorliegen.

Dabei ist auch noch zu beachten, dass Daten von unterschiedlichen Clients reinkommen können. Also brauchst Du den o.g. Puffer ggf. pro Client.

[Zacherl]

Zitat von tomkupitz:

Zitat:

Sorry, aber ... Die "Pause" löst dein Problem in keinster Weise.

Genau so sehe ich das auch. Bisher habe ich aber noch keine "saubere" Übertragung für meinen Kontext gefunden.

Eine Möglichkeit (Längenprefix) - die du wirklich 1 zu 1 übernehmen kannst - habe ich dir doch schon gegeben. Die weiteren Varianten (feste Größe pro "Paket" und Trennzeichen) hat jfheins dir jetzt auch genannt. Alle diese Verfahren sind absolut sauber und bieten keinen Spielraum für inkorrekt übertragene Daten (sofern korrekt implementiert natürlich). Welches Verfahren man nimmt, ist Geschmackssache. Trennzeichen sind problematisch bei Binärdaten und durch Pakete mit fester Größe hat man natürlich Probleme bei dynamischen Daten z.b. String mit variabler Länge, etc. Deshalb bevorzuge ich das Längenprefix.