max Länge TCPIP

[AJ_Oldendorf]

Moin zusammen,
ich habe eine funktionierende Windows Anwendung welche ein Indy TCPServer beinhaltet.
Dann habe ich eine Anwendung auf einem Android Gerät entwickelt mit einem Indy TCPClient.
Beide Anwendungen kommunizieren und können sich Daten hin und her schicken (auch über Internet->feste IP und Port vom Server).

Mir ging es jetzt um das Verständnis TCPIP.
Laut Wiki ist eine maximale Telegramlänge auf 1452 Byte beschränkt.
https://de.wikipedia.org/wiki/Transm...ntrol_Protocol
Ich habe jetzt erwartet, dass bei einem kleinen Test, die Telegramme ab 1452 Byte Länge, auf n-Anzahl Telegramme aufgeteilt wird. Dem ist aber nicht so.
Ich kann sogar 2000 Byte in einem Rutsch übertragen und beim Client kommt das in einem Telegramm an.

Im Client wird der Datenabruf wie folgt in einem extra Thread gemacht:
Execute Funktion:

Delphi-Quellcode:

while not Terminated do
begin
  TCPClient.IOHandler.CheckForDataOnSource(100);
  if not TCPClient.IOHandler.InputBufferIsEmpty then
  begin
    tmpInt := TCPClient.IOHandler.InputBuffer.Size;
    SetLength(content, 0);
    TCPClient.IOHandler.ReadBytes(content, tmpInt, False);    //#$0d + #$0a immer noch am Ende

    tmpStr := 'In: ' + tmpInt.ToString + '->' + BytesToString(content);
    if tmpStr <> '' then
    begin
    if Assigned(OnThreadTCPReceive) then
      OnThreadTCPReceive(Self, tmpStr);
    end;
  end;
end;

Frage 1: Warum können 2000 Byte überhaupt übertragen werden in einem Telegramm? Das ganze geht auch mit 4000 Byte

Ich habe das ganze mal weitergetrieben und bis auf über 5000 Byte Länge gegangen und da bricht er mir manchmal die Telegramme auf 2 Empfangs-Telegramme auf, allerdings ist das erste Telegram nicht immer gleich lang. Es ist also nicht so, dass konstant nach 2000 Byte (fiktive Annahme) ein zweites Telegramm entsteht.

Frage 2: Woher weiß ich beim Empfang, welche Telegramme zusammengehören, wenn das ReceiveEvent mehrmals getriggert wird und immer an unterschiedlicher Stelle ein neues Telegramm erstellt wird?

PS: Ja ich verschicke mit Absicht Bytes und das soll auch so bleiben

[QuickAndDirty]

Indy liefert dir einen Datenstrom.
Das kommt zwar alles in TCP Paketen an und und wird in TCP Paketen gesendet, aber entweder das Betriebsystem oder Indy verstecken diese "Mechanik" in einer Blackbox.
z.B. werden pakete zurrück gehalten wenn sie früher eintreffen als ein vor ihnen abgeschicktes Paket, da TCP Pakete ja alle möglichen Wege durchs internet nehmen könnten.
Dann werden z.b. Datenmengen die kleiner sind als eine MTU oft nicht direkt abgeschickt sondern zurrückgehalten in der Hoffnung dass vielleicht noch mehr Daten verschickt werden die dann in dem selben TCP Paket landen können und somit höhere Datenraten sichern. (Nagel algorythmus)

TCP/IP tunnelt deine DATEN, darin musst du selver dein Protokoll bauen.+

z.b. das
AJ_OLDENDORF_TSTRINGS_Protokoll:
Jede Message fängt mit mit einem Zeichen an das nicht #10 ist.
Jede Message endet mit dem zeichen #10#13

oder das AJ_OLDENDORF_FESTELAENGE_Protokoll:
Jede Message ist 1000 zeichen lang.
Die ersten 4 Zeichen enthalten eine Prüfsumme für die folgenden 996 zeichen.

oder das AJ_OLDENDORF_FLEX_Protokoll:
Jede Message ist beginnt mit 4Byte in der die Länger der darauf folgenden Payload kodiert ist.

oder SOAP (= HTTP/HTTPS + XML + SOA Religion)

oder REST (= HTTP/HTTPS + HTTP-Verbs + JSON + Restfull Philosophy + SOA Religion)

USW.

Fehler korrektur kannst Du Dir im Falle von TCP eigentlich sparen, da Reihenfolge und Störungsfreiheit der Daten schon in TCP abgehandelt werden.

[Mavarik]

QuickAndDirty hat schon die meisten Antworten geliefert.

Ich mache es immer so (bei reinem TCP/IP)...

While aContext.Connection.IOHandler.Connected do
ein Byte lesen... // ist mein Command_ID
Case Command_ID of

Im case kann ich dann auf verschiede Datenstrukturen oder Befehler zurückgreifen wie:
- Ein Word(len) dann Len Chars
- Ein Commando: Gib mit den File zurück mit dem Namen der zuletzt übermittelt wurde
- Gib mir die Anzahl der Dateien und die Größe zurück
- Welche Version hat Dein Protokoll
- Gib mir Deinen Public Key

usw.

Mavarik :coder:

[Hobbycoder]

Übertrag doch mal Text unverschlüsselt und schau dir auf der Windowsmaschine mit einem Packetsniffer die TCP-Pakete an. Da kannst du dann auch die Paketgrößen und den Header gut sehen, was in wievielen Paketen übertragen wird.

[AJ_Oldendorf]

Ok danke für die Anregungen / Tipps. Das sollte weiterhelfen

[skybibo]

Größere Datenpakete werden von Windows in kleinere Pakete zerteilt. Jedes Paket kann dabei maximal die Größe der MTU annehmen. Dies kann von System zu System leicht variieren. Für die eigene Daten Übertragung bedeutet dies, dass bei einem versenden von z.B. 2000 Byte in der Regel 2 Pakete auf der Empfangsseite ankommen. Diese müssen dann von deinem Programm wieder zusammengefügt werden. Ausnahmen sind spezielle Jumbo Pakete, die auch über 9000 Byte Groß sein können (wird im Switch und bei der Netzwerkschnittstelle konfiguriert. Jumbo Pakete werden in der Regel nur bei speziellen Video Kameras verwendet).

Je nach verwendeten Komponenten wird das zusammenfügen der Daten Pakete auch durch die Komponente erledigt(z.B. Datasnap und Webkomponenten).

Bei Verwendung von TClientSocket/TServerSocket (oder ähnliche z.B. von Indy) muss sich das Programm um das Zusammenführen der Daten Pakete kümmern.

[AJ_Oldendorf]

Ich muss doch nochmal nachfragen weil die Aussage von QuickAndDirty mir ein wenig komisch vorkam.
Liefern alle Indy nur einen Datenstrom oder hast du nur TCP/IP Client und Server gemeint?
Hintergrund:
Ich habe für ein ganz anderes Projekt erfolgreich UDP im Einsatz und dort kann ich mit folgenden Befehl

Delphi-Quellcode:

IdUDPClient.SendBuffer(IdUDPClient.Host, IdUDPClient.Port, outMsg);

direkt Telegramme von 32000 Byte verschicken und beim Empfänger kommt auch nur 1x das OnUDPRead Event mit 32000 Byte an.
Klar, dass Betriebssystem zerlegt die Telegramme noch aber fügt sie beim Empfang auch wieder zusammen, sodass ich nur 1x das OnUDPRead Event erhalte.
Das habe ich soeben getestet und ist auch wirklich so.

Bei TCPIP ist es allerdings so, dass ich vom Server (Windows Anwendung) ein 8000 Byte langes Telegramm abschicke und mit der in Post 1 beschrieben Lesefunktion, die Daten abrufe. Allerdings wird das Event mehrmals getriggert, nicht nur 1x. Je nach dem wie mir die Indy die Telegramme aufteilen. Ich hätte eigentlich gerne die gleiche Funktionalität wie bei UDP.
Dort gibt es auch beim Server die Eigenschaft BufferSize, die habe ich auch entsprechend gesetzt. Bei TCPIP gibt es diese nicht. Gibt es einen anderen Weg bei TCPIP, dass ich nur 1x Telegramm abschicke und nur 1x Empfangsevent erhalte, so wie bei UDP?

[fisipjm]

Ich bin mir nicht 100% sicher, aber UDP ist ja vom Grundprinzip Verbindungslos, also etwas völlig andere wie TCP.
TCP sorgt dafür das deine Daten auf jeden Fall ankommen, oder du eine Rückmeldung bekommst das dein TCP Paket nicht übermittelt werden konnte. Deswegen müssen auch Headerinformationen und Informationen über die Reigenfolge mit geschickt werden.
UDP Verhält sich das komplett anders. UDP macht "friss oder stirb". Das Paket wird Adressiert und abgeschickt.
Ob der Empfänger existiert, egal.
Ob der Empfänger das Paket erhält, egal.
Welche Reihenfolge, egal.
Hauptsache schnell und da es hier auch keine Fehlerkorrekturen bei Paket Verlusten, Reihenfolgen usw. gibt, kann man das einzelne Paket auch direkt größer schnüren. Deshalb ist die Maximale Paketgröße eines UDP Pakets 65.535

vG
PJM

[AJ_Oldendorf]

Hi fisipjm,
du hast mit allen UDP Informationen Recht bzgl UDP.
Mir ist nur nicht klar, warum diese Überprüfungen und Mechanismen bei TCPIP im Hintergrund nicht möglich sind und am Ende dann dennoch nur ein Telegramm im ReceiveEvent ausgelöst wird. Die Handlingsschicht dazwischen weiß doch, dass es das eine Telegramm auf 3 aufgesplittet hat und kann diese beim Empfang auch wieder zusammensetzen

[QuickAndDirty]

Zitat:

Zitat von AJ_Oldendorf (Beitrag 1546871)

Ich muss doch nochmal nachfragen weil die Aussage von QuickAndDirty mir ein wenig komisch vorkam.
Liefern alle Indy nur einen Datenstrom oder hast du nur TCP/IP Client und Server gemeint?
Hintergrund:
Ich habe für ein ganz anderes Projekt erfolgreich UDP im Einsatz und dort kann ich mit folgenden Befehl

Delphi-Quellcode:

IdUDPClient.SendBuffer(IdUDPClient.Host, IdUDPClient.Port, outMsg);

direkt Telegramme von 32000 Byte verschicken und beim Empfänger kommt auch nur 1x das OnUDPRead Event mit 32000 Byte an.
Klar, dass Betriebssystem zerlegt die Telegramme noch aber fügt sie beim Empfang auch wieder zusammen, sodass ich nur 1x das OnUDPRead Event erhalte.
Das habe ich soeben getestet und ist auch wirklich so.

Bei TCPIP ist es allerdings so, dass ich vom Server (Windows Anwendung) ein 8000 Byte langes Telegramm abschicke und mit der in Post 1 beschrieben Lesefunktion, die Daten abrufe. Allerdings wird das Event mehrmals getriggert, nicht nur 1x. Je nach dem wie mir die Indy die Telegramme aufteilen. Ich hätte eigentlich gerne die gleiche Funktionalität wie bei UDP.
Dort gibt es auch beim Server die Eigenschaft BufferSize, die habe ich auch entsprechend gesetzt. Bei TCPIP gibt es diese nicht. Gibt es einen anderen Weg bei TCPIP, dass ich nur 1x Telegramm abschicke und nur 1x Empfangsevent erhalte, so wie bei UDP?

TIDTCPClient, TIDTCPServer, TIDUDPClient und TIDUDPServer liefern einfach nur einen Datenstrom.
Die SOAP Clients und Soap Server von INDY liefern naturlich SoapRequest und SoapResponses...
http clients und http server liefern HttpRequests und HttpResponses.

Ich weiß nicht genau wann OnUDPRead gefeuert wird, aber ich vermute mal das passiert wenn der Readbuffer eine bestimmte zeit nicht mehr gefüllt wurde oder Voll ist. So würde ich es machen. Da UDP eine paketlänge codiert kann es natürlch sein, dass deine Message genau ein einziges OnUDPRead event auslöst sobald ein Paket vollständig gelesen wurde...aber es muss nicht zwinged so sein das eine Payload nur in einem einzigen UDP paket gesendet wird!
Bei TCP wird die länge/größe der Pakete dynamisch an die Qualität der Leitung angepasst.
Ich würde mich in keinem Fall auf Mechanismen der darunter liegenden Protkolle verlassen!