In RFC 813 steht auf Seite 5 etwas von 200 Byte, die das sendende TCP schicken kann. Es sendet aber erst 50 Byte und dann 150 Byte in je einem Segment. Warum??
Da steht, weil ein "Pushpoint" erreicht wurde. Was ist denn das? Warum sendet er nicht die vollen 200 Byte? Was veranlasst das TCP, so eigentümliche Segmentgrössen zu verwenden?
Das Push-Flag kann doch wohl damit nichts zu tun haben: Es teilt doch dem Empfänger nur mit, dass die Daten unverzüglich an den empfangenden Prozess weiterzuleiten sind (was heute wohl sowieso immer gemacht wird).
Heimnetzwerke - WIFI, LAN, Router und Co 16.539 Themen, 81.402 Beiträge
die erklärung ist relativ einfach, es handelt sich dabei nur um ein beispiel für das auftreten eines sws. mit pushpoint ist in dem fall gemeint, daß der sender nach den 50bytes sein zu schickendes window erfüllt hat und das nächste generiert. er schickt also, da 200byte freier buffer gemeldet werden die letzten 50 byte des bestehenden windows, danach die ersten 150 bytes des nächsten windows, da ja nach der letzten meldung nur 200byte freier buffer für das window gemeldet wurde, obwohl mittlerweile wieder 1000byte frei wären, wenn der algorithmus so ablaufen würde, wie zu anfang des beispiels beschrieben.
Danke für deine Antwort, aber ich verstehe es nicht.
Der Sender hat ein Fenster von 200 Byte. Er sendet 2 Segmente, eins mit 50 und eins mit 150 Byte. Soweit ist es klar - er nutzt halt sein Sendefenster voll aus.
Das Problem entsteht doch dadurch, dass er zwei Segmente sendet, was dann zum SWS führt (zumindest in dem Beispiel). Und das 50 Byte Segment verkleinert dann das Sendefenster, das ihm der Empfänger mit seinem ACK genehmigt.
Ich fage mich also, warum er nicht das 50er und das 150er zusammen in ein 200er packt, das wäre besser. Im Text heisst es, nach den 50 Byte wird ein Pushpoint erreicht, und der muss (offensichtlich) das Ende eines Segments erzwingen. Also sendet er das 50er und wartet auf das ACK. Weil noch ein 150er ansteht und es rein passt sendet er das auch. Soweit passt alles. Bist auf die Frage, warum nach den 50 Byte ein (angebliches) Segmentende erreicht ist. Das kapier ich nicht.Es werden ja Segmente bestätigt. Warum ist da ein Segment zu Ende? Das Fenster ist ja noch nicht voll.
Die Segmentgrösse wird doch durch die MSS festgelegt (beruht auf MTU etc.). Also packt der Sender immer soviel Daten in ein Segment wie in der MSS steht. Danach baut er ein neues Segment.So entstehen Segmente. 50 Byte ist bestimmt nicht die MSS. Also muss es irgendetwas geben, das ihn veranlasst ein Segmentende zu erzeugen (nach den 50 Bytes) und danach den Rest in ein neues Segment zu packen. Ich hab immer noch Probleme mit diesem ominösen "Pushpoint", ich habe gesucht aber nix gefunden. Also wirds wahrscheinlich doch eher was banales sein.
Es scheint nicht schierig zu sein, vielleicht hab ich nur ein Brett vor dem Kopf.
Noch Lust auf Diskussion? :-)
die sache ist die, daß es ja für das senden auch ein window gibt, das nicht nach und nach, sondern durch push gefüllt wird. die 50 byte stammen aus den ersten sendewindow, das mit dem senden dann geleert ist, die 150 stammen aus dem nächsten, jetzt erst gefüllten window. die beiden pakete können also nicht zusammen gesendet werden, da sie ja nicht im selben buffer existieren. das ganze kommt durch den erwähnten zeitversatz zwischen dem senden und der rückmeldung zustande, der sender erhält eben die meldung: noch 200 frei, er sieht, daß in seinem buffer noch 50 vorhanden sind, leert ihn, füllt ihn wieder und sendet die verbleibenden 150 nach, bevor eine weitere rückmeldung kommt.
ich hoffe, daß die erklärung verständlicher war, ich hab´s leider nicht so mit dem erklären, haben schon mehrere leute bemängelt ;o)...
Stimmt dann passt es. Ich glaub jetzt krieg ich die Kurve. So richtig gut ist das auch nicht erklärt in dem RFC. Die Autoren denken halt manchmal, man weiss schon alles. :-) Also Danke noch mal für Deine Antwort, hätte nicht gedacht, dass hier jemand auf so eine Frage eine Antwort weiss.
stimmt, ist etwas unklar formuliert, ist ja aber eigentlich nur als beispiel für das auftreten einer sws gedacht und rein theoretischer natur, da der algorithmus ja anderst arbeitet, um genau das zu verhindern...ist aber eigentlich immer so bei "fachliteratur" ;o), je fachlicher desto unverständlicher *gg*....
wie darf ich eigentlich das erstehen, daß du nicht gedacht hättest jemand hier könnte dir eine antwort geben? ;o)...du solltest nicht die standardpostings hier als maß der poster nehmen, es gibt hier schon einige leute mit richtig ahnung (zu denen ich mich nicht unbedingt zähle), einige von denen antworten auch anonym, nu rlanden hier eben hauptsächlich standardfragen auf dem board, bei denen sich niemand übermäßig anstrengt, da sie schon zigmal im archiv beantwortet wurden. gerade im netzwerkbereich gab es hier schon einige chracks wie dino und uwe richter, die sich leider selten gemacht haben.
darf ich mal fragen weswegen du dich mit protokollgrundlagen rumschlägst? interesse, beruf oder ausbildung?
naja... all zu viel möcht ich nicht über meine Person sagen, sonst könnte ich mich auch registrieren lassen (war ich früher mal)! Aber damit ist es wohl ein bisschen schwierig geworden hier wie man auf den Brettern sieht. Schade eigentlich, dass diese Seiten hier nicht richtig sauber gehalten werden.
Wenn man Traces macht, muss man das alles wissen, sonst kann man das nicht interpretieren. Und das ist ja erst der Anfang! Wenn ich da an die ganzen neueren Entwicklungen denke, z.B. Security im WLAN und sonstwo, Traffix Shaping, IPv6 etc. Beruflich brauch ich das auch, stimmt :-)
das mit dem schwierig sich zu registrieren versteh ich zwar nicht ganz, wie es gemeint ist, aber muß ja auch nicht sein ;o)...
es gibt sowas wie securitiy im WLAN? ist ja mal was neues ;o)...wäre auf jeden fall mal eine praktische neuerung...
bei IPv6 bin ich mir garnicht mal so ganz sicher, ob sich das wirklich letztendlich durchsetzen wird wie IPv4, oder ob nicht eine noch größere umstellung stattfinden wird, da ja IPv6 mehr oder weniger nur ein herumgedoktore an dem nicht mehr ausreichenden 4 ist. ich vermute mal eher, daß die entwicklung diesen schritt mehr oder weniger überspringen wird und das protokoll sich grundlegend ändern wird, mehr in richtung freenet als vorbild. nicht mehr mit festen adressen für knoten, sondern mit adressen für daten, die verteilt auf unzähligen systemen liegen. wer weiß, was da noch so alles kommt.
Was sollte Grösseres als IPv6 kommen? Das gibts doch schon länger unter Win und Linux. Adressen für Daten wär schon interessant, bisher hab ich nur was von Adressen für Wasserhähne gehört! :-) Im 6bone war ich schon drin, aber weit bin ich nicht gekommen! Trotzdem interessant. Was auch ganz nett ist: Mit Traces kann man sehen, wie sehr die Programmierer "vereinfacht" haben, wenn z.B. zig mal das gleiche Paket kommt! Schon witzig.
Mit der nicht vorhandenen Reg. das finde ich nicht so gut, habe deswegen schon viel Schwierigkeiten hier gehabt von wegen Pöbeln und so. Ich hab einfach keine Lust, mich von irgendeinem Hirni beschimpfen zu lassen. So bin ich nun mal. Aber es geht ja auch so. Manchmal.
Wer liest denn schon sowas?
Leute die TCP mit Tomaten Cetchup Pumuckl verwechseln, sollten vielleicht doch lieber die Computer-Blöd lesen. Viel Spass damit!
Cetchup? Noie doidsche Rächdschraibung?