„Diskussion:Transmission Control Protocol“ – Versionsunterschied

Versionsgeschichte interaktiv durchsuchen

Inhalt gelöscht Inhalt hinzugefügt

Inline

Aktuelle Version vom 3. Dezember 2021, 13:54 Uhr



Zum Archiv

Timestamps

Letzter Kommentar: vor 6 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt

Im Artikel werden die Timestamp-Optionen nicht erwähnt.--2001:4CA0:309:0:2105:C6D6:91E2:B7FE 11:07, 3. Mai 2019 (CEST)Beantworten

Fujitsu

Letzter Kommentar: vor 12 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt

... will eine leistungsfähigere Alternative zu TCP erfunden haben. Noch namenlos (und unverstanden). --Itu (Diskussion) 08:28, 4. Feb. 2013 (CET)Beantworten

PSH-Flag

Letzter Kommentar: vor 12 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt

Der Abschnitt ueber das PSH-Flag ist etwas weitschweifig und unklar formuliert. Der erste PSH enthaltende Satz im ersten verlinkten RFC hat's dagegen gleich geklaert. Folgende zwei Punkte sollten mMn den vielen Text ersetzen:

PSH bedeutet push.
Bei _nicht_ gesetztem Flag _koennen_ Applikationsdaten vom TCP gepuffert werden, und zwar in beiden Senderichtungen. Wenn das Flag dagegen gesetzt ist, werden die Daten sofort durchgereicht (gepusht).

--217.111.33.4 15:04, 4. Mär. 2013 (CET)Beantworten

Syn-Flags, Ack-Flags bei bestehender Verbindung

Letzter Kommentar: vor 12 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt

Bei Transmission Control Protocol#Verbindungsaufbau und -abbau steht nicht, wie Pakete während der Verbindung aussehen... Da steht nur, wie Pakete beim Verbindungsaufbau(Syn-Flag, Ack-Flag) und beim Verbindungsabbau(Fin-Flag, Ack-Flag) aussehen... Wie Pakete während der Verbindung aussehen, steht nicht in dem Artikel... Das sollte vielleicht noch erklärt werden... Welche Flags sind während der Verbindung gesetzt?

- Es beginnt mit dem Verbindungsaufbau... dies ist im Artikel erklärt

- Dann ist die Verbindung aufgebaut und es werden Daten übertragen... dies ist im Artikel nicht erklärt

- Es endet mit dem Verbindungsabbau... dies ist im Arikel erklärt

(nicht signierter Beitrag von 88.70.127.22 (Diskussion) 13:30, 7. Mär. 2013 (CET))Beantworten

Urgent Pointer

Letzter Kommentar: vor 10 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt

Laut RFC 6093 zeigt der Urgent Pointer nicht auf das erste Byte nach den Urgent-Daten, sondern auf das letzte Byte der Urgent-Daten. Viele Stacks behandeln den Urgent Pointer jedoch immer noch so, dass er auf das erste Byte nach den Urgent-Daten zeigt (kommt von der Zweideutigkeit in RFC 793). Auf diese Zweideutigkeit sollte hingewiesen werden, oder? (nicht signierter Beitrag von 149.172.65.125 (Diskussion) 21:05, 19. Feb. 2015 (CET))Beantworten

@@ Zeile 1: / Zeile 1: @@
+{{War AdT|1=13. März 2006}}
-Die Seite ist sehr unübersichtlich und chaotisch aufgebaut; Es fehlt der Aufbau des Protokoll-Datagramms und die Beschreibung zu den einzelnen Feldern.
+{{Archiv-Tabelle|Hilfe=0}}
+{{Autoarchiv
+|Alter             =365
+|Ziel              ='((Lemma))/Archiv'
+|Klein             =Nein
+|Mindestbeiträge   =2
+|Mindestabschnitte =3
+|Frequenz          =monatlich
+}}
+== Timestamps ==
-:Der [[TCP-Header]] hat einen eigenen Artikel, wie ich gerade sehe. Das halte ich eigentlich nicht für sinnvoll. Es hätte hier, in einem besser strukturierten TCP-Artikel, seinen Platz, finde ich. --[[Benutzer:Elwood j blues|Elwood j blues]] 17:14, 27. Mär 2005 (CEST)
+Im Artikel werden die Timestamp-Optionen nicht erwähnt.--[[Spezial:Beiträge/2001:4CA0:309:0:2105:C6D6:91E2:B7FE|2001:4CA0:309:0:2105:C6D6:91E2:B7FE]] 11:07, 3. Mai 2019 (CEST)
-== TCP-Header (Grafik) ==
+== Fujitsu ==
-Hallo! Ich habe mich mal ein bissi hingesetzt, und den Header in eine Grafik überführt. Ich wäre um eure Kritik (Meinung etc.) dankbar. --[[Benutzer:Wendelin|Wendelin]] 23:15, 11. Mai 2005 (CEST)
+... will eine [http://www.golem.de/news/fujitsu-tcp-alternative-macht-datenuebertragung-30-mal-schneller-1301-97246.html leistungsfähigere Alternative] zu TCP erfunden haben. Noch namenlos (und unverstanden). --[[Benutzer:Itu|Itu]] ([[Benutzer Diskussion:Itu|Diskussion]]) 08:28, 4. Feb. 2013 (CET)
-== Geschichtliches ==
+== PSH-Flag ==
-Ein bisschen ueber die Geschichte und Entwicklung von TCP fehlt noch.
+Der Abschnitt ueber das PSH-Flag ist etwas weitschweifig und unklar formuliert. Der erste PSH enthaltende Satz im ersten verlinkten RFC hat's dagegen gleich geklaert. Folgende zwei Punkte sollten mMn den vielen Text ersetzen:
-Der Teilsatz: "... Data Layer (beim Ethernet das statische MAC Protokoll)" ist inhaltlich falsch. Richtig: Nachzulesen unter den Stichworten LLC, MAC und Ethernet.
+* PSH bedeutet push.
+* Bei _nicht_ gesetztem Flag _koennen_ Applikationsdaten vom TCP gepuffert werden, und zwar in beiden Senderichtungen. Wenn das Flag dagegen gesetzt ist, werden die Daten sofort durchgereicht (gepusht).
+--[[Spezial:Beiträge/217.111.33.4|217.111.33.4]] 15:04, 4. Mär. 2013 (CET)
-== Problematik der Datenwiederholung ==
-Dieser Abschnitt ist ungenau und teilweise falsch.
-Hier sollte Slow Start, Congestion Avoidance Schwellenwert und Phase erwähnt werden, in der das Staufenster nach einer RTT nicht verdoppelt sondern nur um eine MSS erhöht wird. Nach einem Paketverlust (Timeout) wird der Schwellenwert neu definiert (= 1/2 * letzte Fenstergröße) und der Slow Start beginnt erneut.
+== Syn-Flags, Ack-Flags bei bestehender Verbindung ==
-Zu nennen wäre zudem Fast Retransmit und Fast Recovery.
+Bei [[Transmission Control Protocol#Verbindungsaufbau und -abbau]] steht nicht, wie Pakete während der Verbindung aussehen... Da steht nur, wie Pakete beim Verbindungsaufbau(Syn-Flag, Ack-Flag) und beim Verbindungsabbau(Fin-Flag, Ack-Flag) aussehen... Wie Pakete während der Verbindung aussehen, steht nicht in dem Artikel... Das sollte vielleicht noch erklärt werden... Welche Flags sind während der Verbindung gesetzt?
-Empfangsfenster für Flußkontrolle.
+:- Es beginnt mit dem [[Transmission Control Protocol#Verbindungsaufbau|Verbindungsaufbau]]... dies ist im Artikel erklärt
-Mir fehlt bei der Diskussion der Datenwiederholung auch die Nennung (Erläuterung und Problematik) des Begriffes "'''D'''enial '''o'''f '''S'''ervice (DoS)"; respektive eine Verlinkung. Meines Wissens ist es definiert, wann der Dienst verweigert werden ''muß''. Bitte hinzufügen. --[[Benutzer:Wendelin|Wendelin]] 13:58, 15. Mär 2005 (CET)
+:- Dann ist die Verbindung aufgebaut und es werden Daten übertragen... dies ist im Artikel nicht erklärt
+:- Es endet mit dem [[Transmission Control Protocol#Verbindungsabbau|Verbindungsabbau]]... dies ist im Arikel erklärt
+<small>(''nicht [[Hilfe:Signatur|signierter]] Beitrag von ''[[Spezial:Beiträge/88.70.127.22|88.70.127.22]] ([[Benutzer Diskussion:88.70.127.22|Diskussion]])<nowiki/> 13:30, 7. Mär. 2013 (CET))</small>
+== Urgent Pointer ==
-:Ja, Staukontrolle (Slow Start und seine Freunde) muss auf jeden Fall erwähnt werden. Ich bin gegen einen eigenen "Slow Start" Artikel, den die gegenwärtige Verlinkung vorsieht. --[[Benutzer:Elwood j blues|Elwood j blues]] 16:55, 27. Mär 2005 (CEST)
+Laut RFC 6093 zeigt der Urgent Pointer nicht auf das erste Byte nach den Urgent-Daten, sondern auf das ''letzte'' Byte der Urgent-Daten. Viele Stacks behandeln den Urgent Pointer jedoch immer noch so, dass er auf das erste Byte ''nach'' den Urgent-Daten zeigt (kommt von der Zweideutigkeit in RFC 793). Auf diese Zweideutigkeit sollte hingewiesen werden, oder? <small>(''nicht [[Hilfe:Signatur|signierter]] Beitrag von'' [[Spezial:Beiträge/149.172.65.125|149.172.65.125]] ([[Benutzer Diskussion:149.172.65.125|Diskussion]])<nowiki/> 21:05, 19. Feb. 2015 (CET))</small>
-== paketorientiert ==
-Was bitte hat UDP, was ja nur zu Transportschicht gehört, mit einem paketorientiertem Netzwerkkern zu tun? Das passt mMn nicht zusammen. UDP ist verbindungslos und TCP als Gegenstück dazu verbindungsorientiert, das hat jedoch nichts damit zu tun, ob ein Netzwerkkern leitungsvermittelt oder  paketvermittelt ausfgebaut ist.
-MfG
-:UDP hat nichts mit paketorientiert zu tun, das ist völlig richtig. Es gibt halt immer wieder sprachliche Ungenauigkeiten bei Leuten, die mit englischer Fachliteratur umgehen. Sie lesen "packet" und übersetzen das einfach als "Paket", weil sie die spezifische deutsche Fachsprache für Kommunikation nicht gut genug kennen. Korrigiere es doch einfach. [[Benutzer:213.6.50.126|213.6.50.126]] 00:25, 1. Mär 2005 (CET)
-== Fluss- und Staukontrolle ==
-Dass und wie TCP das Sliding Window-Verfahren einsetzt, fehlt noch. --[[Benutzer:Elwood j blues|Elwood j blues]] 17:14, 27. Mär 2005 (CEST)
-:Ich habe zu diesem Thema einen "Stub" eingefügt, der natürlich alles andere als aufschlussreich ist. So bekommt man aber ein wenig mehr Struktur in den Artikel. Ggf. nach Belieben ergänzen, bitte. --[[Benutzer:Elwood j blues|Elwood j blues]] 18:24, 27. Mär 2005 (CEST)
-== [[Transmission Control Protocol]], 17. Mai ==
-*'''pro''': durchaus umfassend. Jedoch könnte die Literatur zum Protokoll und die Erläuterung des Aufbauschemas ausführlicher sein. --[[Benutzer:Wendelin|Wendelin]] 21:42, 17. Mai 2005 (CEST)
-*'''contra''': der Artikel ist in seiner jetzigen Form zu fachlich. Wer kein Vorwissen mitbringt, der wird gar nichts verstehen. --[[Benutzer:Herr Schroeder|Herr Schroeder]] 08:52, 19. Mai 2005 (CEST)
-*'''contra''' Nur zwei Bücher unter Literatur, da fehlen ein paar Standardwerke (Databecka kann dafür vermutlich eher raus). An der Verständlichkeit des Artikels kann man noch arbeiten - er muss nicht für Oma verständlich sein, aber auch jemand, der sich bemüht, steigt nach kurzem Lesen aus. --[[Benutzer:Elian|Elian]] [[Benutzer Diskussion:Elian|&Phi;]] 17:20, 19. Mai 2005 (CEST)
-*'''contra''' ''Die TCP-Software ist eine Funktionssammlung zum Beispiel in der Winsock.dll oder im Kernel (je nach Betriebssytem unterschiedlich).  Die Anwendung ist zum Beispiel ein Webbrowser oder ein Webserver (zum Beispiel Apache).'' – Ich denke nicht, dass explizit Dateien genannt werden müssen.  Und wenn doch, bitte das zugehörige Betriebssystem dazu.  Außerdem sollte der Artikel besser formuliert werden (hier: ''zum Beispiel'' in zwei Sätzen dreimal).<br>
-:''Während der Datenübertragungsphase (''active open'') sind die Rollen von Client und Server (aus '''TCP'''-Sicht) vollkommen symmetrisch.'' – Die Datenübertragungsphase heißt nicht ''active open''.  ''active open'' ist, wenn ein Client-Prozess die Verbindung auf eigene Initiative hin öffnet, also ein SYN-Paket schickt.<br>
-:''Drei-Wege-Handshake'' – sollte man das vielleicht wie im englischen Three-Way-Handshake nennen?<br>
-:Insgesamt bin ich der Meinung, dass der Artikel in Review sollte, und dann nochmal gründlich überarbeitet werden soll. Im aktuellen Zustand ist der Artikel oft zu unpräzise. --[[Benutzer:Ww|Ww]] 00:40, 22. Mai 2005 (CEST)
-::@Ww: Ich bin ganz deiner Meinung. Mir ist sowieso schleierhaft wieso ein halbfertiger Artikel als "Kandidat" gesetzt wurde. Man sollte den Artikel eher ins Review setzen. Ich habe nur 3 Bücher über TCP. Davon kann man getrost "1,5" vergessen. Es wäre schön, wenn mehr Leute an diesem Artikel mitarbeiten würden. - [[Benutzer:Appaloosa|Appaloosa]] 01:37, 22. Mai 2005 (CEST)