TCP: Größe des Puffers bei Sementierung

[misterunknown]

Moin,

ich beschäftige mich gerade etwas mit TCP, weil ich beim Bewerbungsgespräch (siehe) da etwas auf dem Schlauch stand. Ich habe mir dazu die Wikipedia-Seite durchgelesen, die auch ganz aufschlussreich ist. Meine Frage, die noch bleibt:

Hier wird beispielhaft eine gestaffelte Datenübertragung dargestellt. Die Frage ist: Woher weiß der Client, wie viele Segmente es insgesamt gibt? Dementsprechend müsste ja da der Puffer angepasst werden. Ich habe erst vermutet, dass der Client ja sieht, wenn der Payload des "letzten" Pakets nicht "voll" ist. Gerade in diesem Beispiel funktioniert das aber nicht, da der Payload immer exakt gleich groß ist. Außerdem würde das sowieso nicht funktionieren, da ja der clientseitige Puffer u. U. nicht groß genug ist. Wer kann helfen?

Grüße Marco

PS: Ich hab den Job trotzdem *freu* :)

[Tom]

Hello Marco,

ich beschäftige mich gerade etwas mit TCP, weil ich beim Bewerbungsgespräch (siehe) da etwas auf dem Schlauch stand. Ich habe mir dazu die Wikipedia-Seite durchgelesen, die auch ganz aufschlussreich ist. Meine Frage, die noch bleibt:

Hier wird beispielhaft eine gestaffelte Datenübertragung dargestellt. Die Frage ist: Woher weiß der Client, wie viele Segmente es insgesamt gibt? Dementsprechend müsste ja da der Puffer angepasst werden. Ich habe erst vermutet, dass der Client ja sieht, wenn der Payload des "letzten" Pakets nicht "voll" ist. Gerade in diesem Beispiel funktioniert das aber nicht, da der Payload immer exakt gleich groß ist. Außerdem würde das sowieso nicht funktionieren, da ja der clientseitige Puffer u. U. nicht groß genug ist. Wer kann helfen?

TCP ist ein symmetrisches Protokoll. Es gibt allgemein betrachtet keinen dedizierten Server und Empfänger. Allerdings sind die Rollen während einer Verbindung schon festgelegt.

Eine Übertragung besteht im Wesentlichen aus drei teilen:

*1  Verbindungsaufbau

*2  Paketweise (segmentierte) Übertragung

*3  Verbindungsabbau

siehe auch http://www.elektronik-kompendium.de/sites/net/0812271.htm

Es ist hier leider auch nicht vollständig beschrieben.

Aus meiner Erinnerung:

Aber beim Verbindungsaufbau sendet der Sender dem Empfänger die Anzahl der zur Übertragung gewünschten Bytes. Der Empfänger antwortet beim ACK nit einer Window-Größe. In diesem Fenster muss sich die Größe der gesendeten Pakete befinden.

Kann der Empfänger die Daten (in der Menge) nicht entgegen nehmen, antwortet er mit einem NACK und einer Fenstergröße von 0.

Der Empfänger weiß also durch das erste Paket (Verbindungsaufbau), was auf ihn zukommt.

Grüße Marco

PS: Ich hab den Job trotzdem *freu* :)

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[misterunknown]

Moin,

TCP ist ein symmetrisches Protokoll. Es gibt allgemein betrachtet keinen dedizierten Server und Empfänger. Allerdings sind die Rollen während einer Verbindung schon festgelegt.

Stimmt, ich meine natürlich Empfänger statt Client.

Kann der Empfänger die Daten (in der Menge) nicht entgegen nehmen, antwortet er mit einem NACK und einer Fenstergröße von 0.
Der Empfänger weiß also durch das erste Paket (Verbindungsaufbau), was auf ihn zukommt.

Ok, soweit hab ich das verstanden. Bei Wikipedia war das Window-Feld im TCP-Header etwas umständlich umschrieben.

Was passiert aber, wenn große Datenmengen übertragen werden, beispielsweise 100 GB per FTP. Das ist zu groß für jeden Puffer. Schreibt die TCP-Software selbiges dann Übergangsweise auf die Festplatte oder wird der Inhalt der Segmente bei vollem Puffer schon an die Anwendung weitergeleitet und der Puffer geleert bevor weitere Pakete entgegengenommen werden?

Grüße Marco

[unknown]

Was passiert aber, wenn große Datenmengen übertragen werden, beispielsweise 100 GB per FTP. Das ist zu groß für jeden Puffer. Schreibt die TCP-Software selbiges dann Übergangsweise auf die Festplatte

Das wäre dann ja auch ein Puffer, allerdings ein langsamer. Die TCP Stacks arbeiten eher nicht so.

oder wird der Inhalt der Segmente bei vollem Puffer schon an die Anwendung weitergeleitet und der Puffer geleert bevor weitere Pakete entgegengenommen werden?

Die Anwendung holt die Daten ab. Und das regelmäßig. Ist sie nicht schnell genug, läuft der Puffer des TCP Stacks voll. Dann nimmt dieser keine weiteren Pakete an, ehe die Anwendung nicht wieder Daten geholt und damit Platz geschaffen hat.

[misterunknown]

Moin,

oder wird der Inhalt der Segmente bei vollem Puffer schon an die Anwendung weitergeleitet und der Puffer geleert bevor weitere Pakete entgegengenommen werden?

Die Anwendung holt die Daten ab. Und das regelmäßig. Ist sie nicht schnell genug, läuft der Puffer des TCP Stacks voll. Dann nimmt dieser keine weiteren Pakete an, ehe die Anwendung nicht wieder Daten geholt und damit Platz geschaffen hat.

Alles klar. Danke euch beiden für die Infos.

Grüße Marco

[Tom]

Hello Marco,

wie sieht es denn mit deinen Englischkenntnissen aus?

ich habe hier noch einen Link für Dich, der das Ganze für Linux beschreibt.
http://www.ece.virginia.edu/cheetah/documents/papers/TCPlinux.pdf

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[unknown]

Woher weiß der Client, wie viele Segmente es insgesamt gibt?

Das weiss er nicht. Theoretisch sind das unendlich viele, bei einer Anwendung die unendlich läuft und zyklisch Daten empfängt.

Dementsprechend müsste ja da der Puffer angepasst werden.

http://de.wikipedia.org/wiki/TCP_Receive_Window

Ich habe erst vermutet, dass der Client ja sieht, wenn der Payload des "letzten" Pakets nicht "voll" ist.

http://de.wikipedia.org/wiki/Nagle-Algorithmus

[Tom]

Hello,

Woher weiß der Client, wie viele Segmente es insgesamt gibt?

Das weiss er nicht. Theoretisch sind das unendlich viele, bei einer Anwendung die unendlich läuft und zyklisch Daten empfängt.

Das betrifft die TCP-Socket-Verbindung. Die ist der Größe nach unlimitiert, hat aber üblicherweise ein Timeout. Wenn länger nix kommt, wird nachgefragt und/oder die Verbindung geschlossen.

Für die einzelne Datenübertragung (ich will das hier ruhig nochmal "Datei" nennen), wird schon vereinbart, wieviele Bytes der Sender zu übertragen wünscht. Der Empfänger muss dafür i.d.R. genügend Platz reservieren, weil nicht sichergestellt ist, in welcher Reihenfolge die Pakete zur Verfügung stehen werden. Erst wenn alle Pakete vollständig vorhanden sind, kann die Datei geschlossen werden. Es können aber alle Pakete bis zur Lücke aus dem Ringpuffer an das OS und damit vermutlich auch an die Applikation ausgeliefert werden. Das ist Sache des NICs. Übliche Größen sind hier heute zwischen 1 und 4 MB.

Wie das nun genau abläuft, dass da mehrere Verbindungen gleichzeitig abgewickelt werden können, weiß ich auch nicht mehr.

Wenn der zugewiesene Puffer im NIC überläuft, muss die Verbindung (für diese eine Übertragung) abgebrochen werden und der (Teil)Puffer wird geleert.

Die TCP-Sockets (aufgabe der OSse) sind davon aber erst einmal nicht betroffen. Die bleiben empfangs- und sendebereit.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[unknown]

Woher weiß der Client, wie viele Segmente es insgesamt gibt?

Das weiss er nicht. Theoretisch sind das unendlich viele, bei einer Anwendung die unendlich läuft und zyklisch Daten empfängt.

Das betrifft die TCP-Socket-Verbindung. Die ist der Größe nach unlimitiert, hat aber üblicherweise ein Timeout. Wenn länger nix kommt, wird nachgefragt und/oder die Verbindung geschlossen.

Ich kann dir nicht ganz folgen, bzw. nicht einordnen, worauf du hinaus willst.
Das betrifft TCP Pakete. Wenn eine Anwendung lange genug läuft, kann sie unendlich viele empfangen.

Der Empfänger muss dafür i.d.R. genügend Platz reservieren, weil nicht sichergestellt ist, in welcher Reihenfolge die Pakete zur Verfügung stehen werden.

Deswegen kann der Sender nur soviele Daten schicken, wie der Empfänger Platz reserviert hat.

Erst wenn alle Pakete vollständig vorhanden sind, kann die Datei geschlossen werden.

Aber die Anwendung kann schon vorher Daten vom TCP Stack abholen und in eine Datei schreiben.

Es können aber alle Pakete bis zur Lücke aus dem Ringpuffer an das OS und damit vermutlich auch an die Applikation ausgeliefert werden. Das ist Sache des NICs.

Das ist Sache der Anwendung. Diese liest die Daten. Liest sie keine, läuft der Puffer voll.

Wenn der zugewiesene Puffer im NIC überläuft, muss die Verbindung (für diese eine Übertragung) abgebrochen werden und der (Teil)Puffer wird geleert.

Wenn du jetzt noch den Puffer der Netzwerkkarte selbst ins Spiel bringst, hast du noch einen weiteren Puffer. Ob der TCP-Stack diesen bereit stellt, keine Ahnung.

Die TCP-Sockets (aufgabe der OSse) sind davon aber erst einmal nicht betroffen. Die bleiben empfangs- und sendebereit.

Warum? Diese haben nur einen begrenzten Puffer.

[Matthias Apsel]

Om nah hoo pez nyeetz, misterunknown!

PS: Ich hab den Job trotzdem *freu* :)

Meinen Glückwunsch, möge dir die Arbeit Spaß machen und neue Horizonte für dich eröffnen.

Matthias

[Tom]

Hello,

PS: Ich hab den Job trotzdem *freu* :)

Meinen Glückwunsch, möge dir die Arbeit Spaß machen und neue Horizonte für dich eröffnen.

Auf dass Marco viele erfolgreiche Verbindungen bekommt :-))

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[1UnitedPower]

Meine Herren!

PS: Ich hab den Job trotzdem *freu* :)

Von mir auch alles Gute, auf dass du viel Spaß und Erfolg bei deiner neuen Stelle hast ;)

[Der Martin]

Hallo,

Hier wird beispielhaft eine gestaffelte Datenübertragung dargestellt. Die Frage ist: Woher weiß der Client, wie viele Segmente es insgesamt gibt?

das weiß er nicht, er muss nehmen was kommt (oder ablehnen).

Dementsprechend müsste ja da der Puffer angepasst werden. Ich habe erst vermutet, dass der Client ja sieht, wenn der Payload des "letzten" Pakets nicht "voll" ist. Gerade in diesem Beispiel funktioniert das aber nicht, da der Payload immer exakt gleich groß ist.

So wie ich die Wikipedia-Erklärungen verstehe, signalisiert das FIN-Flag im TCP-Header, dass dies der letzte Block einer Übertragung ist.

PS: Ich hab den Job trotzdem *freu* :)

Glückwunsch! :-)
Womit mal wieder bewiesen ist: Es macht gar nichts, wenn man bei einem Bewerbungsgespräch nicht auf alle Fragen sofort eine Antwort hat, oder auch mal Lücken zugeben muss. Nobody's perfect. Viel wichtiger ist, dass man das generelle Verständnis für die Materie erkennen lässt, und die Motivation, Defizite rasch aufzuholen, wenn sie sich zeigen.

Gilt übrigens sinngemäß auch für Referate, Fachvorträge oder mündliche Prüfungen an Schule oder Uni.

Ciao,
 Martin

[misterunknown]

Moin,

ich danke euch für eure Antworten und Glückwünsche.

@Tom:
Meine Englischkenntnisse sind recht ordentlich, dank Englisch-Leistungskurs^^ Danke für den Link.

@Der Martin:
So ähnlich hat das auch der Chef dort gesagt.

Grüße Marco