„Diskussion:Transmission Control Protocol“ – Versionsunterschied

Die Seite ist sehr unübersichtlich und chaotisch aufgebaut; Es fehlt der Aufbau des Protokoll-Datagramms und die Beschreibung zu den einzelnen Feldern.

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. --Elwood j blues 17:14, 27. Mär 2005 (CEST)

TCP-Header (Grafik)

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. --Wendelin 23:15, 11. Mai 2005 (CEST)

Geschichtliches

Ein bisschen ueber die Geschichte und Entwicklung von TCP fehlt noch.

Der Teilsatz: "... Data Layer (beim Ethernet das statische MAC Protokoll)" ist inhaltlich falsch. Richtig: Nachzulesen unter den Stichworten LLC, MAC und Ethernet.

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.

Zu nennen wäre zudem Fast Retransmit und Fast Recovery.

Empfangsfenster für Flußkontrolle.

Mir fehlt bei der Diskussion der Datenwiederholung auch die Nennung (Erläuterung und Problematik) des Begriffes "Denial of Service (DoS)"; respektive eine Verlinkung. Meines Wissens ist es definiert, wann der Dienst verweigert werden muß. Bitte hinzufügen. --Wendelin 13:58, 15. Mär 2005 (CET)

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. --Elwood j blues 16:55, 27. Mär 2005 (CEST)

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. 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. --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. --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. --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. --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. --Elian Φ 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).
  

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.

Drei-Wege-Handshake – sollte man das vielleicht wie im englischen Three-Way-Handshake nennen?

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. --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. - Appaloosa 01:37, 22. Mai 2005 (CEST)

Transmission Control Protocol, 21. Juni

aus dem Review:

• Dafür: Umfangreiche Erläuterung des Protokolls. -- Dishayloo [ +] 01:14, 21. Jun 2005 (CEST)
• contra: der Artikel ist für Laien nicht verständlich, dies sollte bei einem exzellenten Artikel aber der Fall sein. Außerdem enthält der Artikel Abschnitte, die doppelt vorkommen. fehlende Verknüpfung: RFC, Socket, Fullduplex/Halfduplex, Handshake, Paket. --Atamari 17:35, 21. Jun 2005 (CEST)

Für den Artikel TCP sind gute Netzwerkgrundkenntnisse Voraussetzung. Wenn man den Artikel für jeden Laien verständlich machen wollte, wäre der Artikel - übertrieben gesagt - mindestens 100 Seiten lang und 80 Seiten davon würden nicht TCP betreffen.

Dies betrifft auch naturwissenschaftliche Bereiche bei Wikipedia, wie zum Beispiel die Gentechnik oder die höhere Mathematik. Man kann höchstens per Links den Leser etwas helfen.

BtW: Der Artikel Überlagerungsempfänger ist zum Beispiel exzellent. Ich kann ihn ja mal meiner Mutter vorlegen und sie fragen, ob sie ihn verstanden hat. ;)

- MfG Appaloosa 00:33, 22. Jun 2005 (CEST)

Oh schön, eine Grundsatzdiskussion ;)! Nun kenne ich deine Mutter nicht (schönen Gruß unbekannterweise!), aber ich könnte mir vorstellen, dass sie nach Lektüre der Einleitung von Überlagerungsempfänger doch verstanden hat, worum es im Prinzip geht, warum es so etwas gibt, und dass sie sich selbst vermutlich nicht näher damit beschäftigen muss. Die Einleitung zu TCP lässt da zu wünschen übrig, weil sie mit jedem zweiten Wort, auch wenn's verlinkt ist, spezielles Vorwissen voraussetzt. Dazwischen gibt es dann Namen und Jahreszahlen, deren Relevanz für die Sache man an diesem Punkt nicht einordnen kann. Eine für den interessierten Laien verständliche Einleitung kann man über alles schreiben; ich sehe nicht ein, warum Naturwissenschaft und Technik da Sonderrechte haben sollen. Dass sich der Hauptteil dann eher an Eingeweihte richtet, geht in Ordnung. Mir gefällt der Artikel im Ganzen übrigens; daher: abwartend. T.a.k. 01:14, 22. Jun 2005 (CEST) Jetzt pro T.a.k. 00:24, 28. Jun 2005 (CEST)

• Abwartend: Ganz abgesehen von obiger Diskussion, müssten etwas mehr Fachbegriffe verlinkt werden. Es weiß ja z.B. nicht jeder automatisch, was eine DLL ist. Weitere Begriffe, die nicht verlinkt sind: Virtueller Kanal, Fullduplex, Winsock.dll beziehungsweise wsock32.dll,

SYN und ACK, Flags, Buffers. Gruß Boris Fernbacher 17:34, 23. Jun 2005 (CEST)

• pro habe etwas an der Einleitung gefeilt, als Referenz an alle Großmütter. @Ein Artikel kann trotzdem exzellent sein, auch wenn er in weiten Teilen Fachwissen voraussetzt.--Heliozentrik 19:03, 26. Jun 2005 (CEST)

• pro schöner Artikel :) -- da didi | Diskussion 18:18, 30. Jun 2005 (CEST)
• abwartend, mag sich noch jemand die rel. (optisch) unschönen Textblöcke ansehen? (... Wie kann man mit einem 1460 Byte großen Nutzdatenfeld 10 Kilobyte Daten versenden? Ganz einfach, man teilt die Daten auf (Segmentierung), fügt ...). Darkone (¿!) 1. Jul 2005 10:41 (CEST)
• pro - absolute Laienmeinung, aber wenn ich einen solchen Text schon versteh ... -- Achim Raschka 5. Jul 2005 08:31 (CEST)

• Abwartend - Der Artikel ist gut, aber sicher nicht exzellent.

• So fehlt z.B. in der Einleitung einer kurze Beschreibung der Eigenschaften des Kommunikationskanals (bi-direktional, full-duplex, reihenfolgeerhaltend, byte-orientiert, fehlerkompensierend, etc.)
• Bei der Geschichte fehlt ein Hinweis darauf, daß TCP und IP anfangs ein Protokoll waren
• Es fehlt ein Hinweis darauf, daß die überwältigende Mehrheit der Anwendungsprotokolle im Internet auf TCP aufbaut
• Der "Teardown" (Verbindungsabbau) ist ungenau beschrieben (FINs zählen wie SYNs eine ACK-Nummer)
• Die Beschreibung der TCP-Flags ist unglücklich/missverständlich
• Wenn schon TCP Vegas erwähnt wird, dann sollten auch TCP Reno und TCP Tahoe erwähnt werden
• Wo die "TCP-Software" steckt (DLL, etc.) ist nicht so wichtig, viel wichtiger ist wie man sie anspricht (=die Schnittstelle). Das sich hier die Berkeley Sockets API durchgesetzt hat (mit der man übrigens nicht nur TCP, UDP und IP ansprechen kann, sondern auch alle möglichen anderen Protokolle) ist sicherlich interessant. Es gibt aber auch andere APIs für TCP.
• Ein kurzer Hinweis auf die Sicherheit von TCP (Stichwort "session hijacking") fehlt
• Hinweis über die "Fairness" von TCP fehlt
• Vor- und Nachteile von TCP sollten beleuchtet werden -- beos 7. Jul 2005 12:26 (CEST)