Diskussion:Datenflusssteuerung

Diese Diskussionsseite dient dazu, Verbesserungen am Artikel „Datenflusssteuerung“ zu besprechen. Persönliche Betrachtungen zum Thema gehören nicht hierher. Für allgemeine Wissensfragen gibt es die Auskunft.

Füge neue Diskussionsthemen unten an:

Klicke auf Abschnitt hinzufügen, um ein neues Diskussionsthema zu beginnen.

• Diskussionsregeln
• Hilfe zu Diskussionsseiten
• Sei sachlich und freundlich!
• Greife niemanden persönlich an!
• Geh von guten Absichten aus.

Wikipedia Links (und falsch gewählte Begriffe)

Die vorhandenen Links in Wikipedia anderer Sprachen verweisen alle auf Handshake. Sollte das nicht besser auf Flow Control (im Englischen Wikipedia z.B.) geändert werden? --84.57.149.52 17:40, 22. Jun. 2007 (CEST)

Ich habe die Abschnittsüberschrift um die Klammer ergänzt, denn das Problem ist vor allem, dass die deutsche Wikipedia Handshake und Control Flow gleichsetzt. Das ist falsch, die Datenflusssteuerung ist kein Handshake, sondern etwas ganz anderes. Der Handshake ist Teil des Verbindungsaufbaus, elektronisch und softwareseitig. Im Handshake werden noch keine Nutzdaten übertragen. Die Datenflusssteuerung ist dagegen Teil des verwendeten Verbindungsprotokolls und steuert die Übertragung der Nutzdaten. In der englischen Wikipedia ist es korrekt: Handshaking vs Control Flow. Man betrachte bspw. die Begriffsverwendung in Abschnitt 7 von RFC 5246 (TLS Handshaking).

Aber bevor ein Edit War ausbricht, diskutiere ich das besser erstmal an. --Rolf b (Diskussion) 12:51, 5. Aug. 2021 (CEST)

Den folgenden Beitrag hatte ich am 12.Januar unter Wikipedia:Artikel zum gleichen Thema eingestellt:

Flusskontrolle

Handshake

Hardware-Protokoll

Software-Protokoll

XON/XOFF

beschreiben das gleiche. Das richtige Lemma wäre allerdings Datenflusskontrolle Data flow control, siehe ITU-T V.43.

Ich hab das ganze einmal zusammengefasst, berichtigt und ergänzt, hier zur Vorrausschau: Benutzer:Nightflyer/Datenflusskontrolle. Bestehen Bedenken dagegen, alle fünf Artikel zu redirecten? --Nightflyer 12:59, 12. Jan 2006 (CET)

Grundsätzlich ist es sinnvoll, die Artikel teilweise oder ev. ganz zusammenzulegen. Dein Artikelvorschlag ist leider arg theoretisch geworden. Dinge wie V.43 oder circuit 133 existieren in der Praxis nicht und bei Überschriften wie [...] oft fälschlich [...] RTS/CTS verliere ich den Faden: Möchtest du damit ausdrücken, dass die Wirklichkeit nicht existiert? Manchmal befürchte ich, dass die Hauptaufgabe der ITU-T darin besteht, Papiertiger zu produzieren. Es ist z.B. wenig sinnvoll, primär ITU-Leitungsnummern zu verwenden, wenn praktisch überall die Bezeichnungen aus TIA-232 stehen. Dadurch wird es dem Leser unnötig schwer gemacht, den Artikel zu verstehen. Ein anderer Punkt: Wenn der Leser z.B. von XON/XOFF her kommt (weil er Probleme in seinem Terminalprogramm hat), sollte er nach der Umleitung im Zielartikel innert nützlicher Frist eine Erklärung finden – das ist gegenwärtig nicht der Fall (und XON/XOFF ist eine der wichtigsten Varianten von Softwarehandshake). -- Stefan506 18:37, 15. Jan 2006 (CET)

die Sichtweise von Stefan06 kann ich nicht teilen :

• Die Flußkontrollverfahren aus der V.43 sind in Ländern, die dedizierte Datennetze haben, gängige und eingeführte Technik. Datennetze in anderen Ländern bieten oft eine wesentlich höhere Qualität als das Telefonnetz dort. Deutschland braucht kein eigenes dediziertes Datennetz, weil das ISDN schon eine sehr hohe Qualität hat. Voll synchron bis zum Schreibtisch. Andere Länder haben sich sowas teures nicht zugelegt, die machen eben eigene Datennetze mit hoher Qualität für ihre Geschäftskunden auf, was billiger ist, als das gesamte Telefonnetz zu erneuern. Wer heute Ausschreibungen für SDSL-Modems für solche Datennetze liest, wird immer V.43 als Forderung finden (das ist meine Berufserfahrung). notabene: auch den XON/XOFF-Handshake findet man in der V.43, die laut Stefan506 "in der Praxis nicht existiert". In Datenmodems ist es wichtig, dass dieses Verfahren abschaltbar ist, weil eventuell XON/XOFF auch vom Endgerät gemacht wird. Dann muß das Modem aber ein alternatives Verfahren zur Flußkontrolle bieten, auf das umgeschaltet werden kann.
• einfach wär das Leben, wenn überall nur Leitungsbezeichnungen aus der EIA-232 stünden. Das ist aber nicht der Fall. Die einzigen Bezeichnungen, die wirklich international sind, sind die von der ITU-T. In Asien z.B. kommst Du mit der EIA nicht sehr weit. Im Artikel V.24 ist das vorbildlich gelöst, das steht für jede Leitung, wie sie von ITU-T, DIN und EIA genannt werden. Sowas braucht ein Praktiker. Das kann man auch in einem Artikel Datenflusskontrolle so machen.
• Artikel sollten nicht für den DAU geschrieben werden, der gerade mal ein Problem hat. Hier geht es um eine Enzyklopädie und nicht um FAQs für den Bastler. Also ruhig die verstreuten Kleinartikel zusammenfassen.
• Nightflyer soll seinen Artikel ruhig einstellen, das Lemma ist schließlich noch frei. Dann kann man den Artikel wenigstens verbessern, ihn beispielsweise besser gliedern und die verwirrende Leitung 133 wieder rausnehmen. Dass zwei logische Leitungen auf demselben Steckerpin sitzen, muß man nun nicht wissen. Fink 22:53, 19. Jan 2006 (CET)

Bitte die Diskussion ab jetzt hier weiterführen. --Nightflyer 21:31, 20. Jan 2006 (CET)

"sliding" bedeutet, dass die Fenstergröße mittels des Steuerungsdialoges nach oben oder unten geregelt werden kann. Ist das richtig? Ist es nicht vielmehr so dass sich das sliding darauf bezieht dass das Fenster über die zu sendenden Daten slidet? Siehe auch http://en.wikipedia.org/wiki/Sliding_window

Kontrolle oder Steuerung

Hi. Ist nicht „Kontrolle“ schlicht eine Fehlübersetzung der englischen control? Ich schlage daher vor, den Artikel in „Datenflusssteuerung“ umzubenennen und die „Datenflusskontrolle“ als Alternativbezeichnung zu erwähnen. Einverstanden? --jpp ?! 11:24, 17. Dez. 2007 (CET)

Beide Lemmas führen zum gleichen Artikel. Vor einer Änderung: Was sagen die deutschen Normen? Gruss --Nightflyer 00:03, 20. Dez. 2007 (CET)

Ich denke auch, daß die "Kontrolle" hier ein false friend ist. Googletreffer sind annähernd gleich, mit leichter Bevorzugung der Steuerung. Wenn niemand Einwände hat, werde ich den Artikel verschieben. --ulm 02:13, 11. Aug. 2010 (CEST)

Fehler in der Beschreibung?

>>>> Das Übertragungsgerät muss einen Sendespeicher von mindestens 2000 Byte haben. Ist dieser Speicher zur Hälfte gefüllt, soll es Leitung CTS ausschalten. Die Endeinrichtung sollte daraufhin so schnell wie möglich das Senden von Daten unterbrechen, bis CTS wieder eingeschaltet wird.<<<<

Sollte das nicht vielleicht Empfangsspeicher statt Sendespeicher heißen? Denn es macht wenig Sinn, daß der Sender aufhört zu senden, wenn sein Sendespeicher weniger als halb voll ist, so wird er nämlich niemals fertig.

Stimmt schon so. Originalzitat der V.43, Ausgabe 2/98:

Flow control by use of V.24 interchange circuits

a) Use of circuit 106 – Ready for sending

The DCE not-ready condition is indicated by turning circuit 106 OFF, and cleared by turning circuit 106 ON.

This method should be the preferred one because it is unambiguous and is applicable to any kind of data communication. However, many DTEs will not immediately recognize the OFF condition on circuit 106 and will not cease transmitting at the end of the present character. Instead, these DTEs will complete the present frame which may be up to some thousand octets long, and only then detect the OFF condition on circuit 106.

It is therefore suggested that the remaining buffer capacity inside the DCE be kept large enough to cope with this condition. A reasonable remaining buffer size suggested may be between 2000 and 4000 octets, so that the minimum total buffer size may be between 4000 octets (DCE not-ready condition is indicated to the DTE when the buffer is half-full) and 10 000 octets (DCE not-ready condition is indicated to the DTE when about 80% of the buffer is full).

Es werden Daten schneller an den Sender geliefert, als dieser tatsächlich übertragen kann. Diese Daten werden im Sendespeicher in der DCE zwischengespeichert. Während der Übertragungspause zwischen DTE und DCE sendet die DCE den Inhalt des Sendspeichers. Gruss --Nightflyer 20:59, 21. Jan. 2008 (CET)

Nach meinem Verständnis sagt der englische Text, dass das Endgerät (DTE) nicht sofort bemerkt, dass die Übertragungseinrichtung (DCE) Circuit 106 (CTS) gelöscht hat und deshalb weitersendet. Deshalb braucht das DCE einen großen Puffer, um die zusätzlich gesendeten Daten zu empfangen, also einen Empfangspuffer. Ich ändere es im Artikel entsprechend ab. --Bobbl (Diskussion) 12:36, 24. Apr. 2019 (CEST)

Ich mach es rückgängig. Die Empfangsdaten kommen von der anderen Seite der Verbindung. Also Sendespeicher im Modem.Gruss --Nightflyer (Diskussion) 13:55, 24. Apr. 2019 (CEST)

Mit CTS=0 signalisiert das Modem (DCE), dass es keine Daten mehr aufnehmen kann. Da es sein kann, dass der PC (DTE) sehr spät darauf reagiert und bis zum Ende des aktuellen Frames weiter sendet, muss der DCE-Speicher noch ca 2000 Bytes aufnehmen können. Es ist also ein Empfangsspeicher im DCE (Übertragungsgerät).--Bobbl (Diskussion) 12:35, 25. Apr. 2019 (CEST)

Sorry, jetzt habe ich das Problem verstanden. Wenn man (wie ich) die Verbindung DTE-DCE betrachtet, ist es ein Empfangspuffer. Betrachtet man die Verbindung DTE-Außenwelt, so schreibt der DTE in den Sendepuffer des DCE, der es dann ins Netzwerk schickt. Ich würde den ganzen Abschnitt umformulieren, damit man um Sende- bzw. Empfangspuffer ganz herum kommt. Etwa so:

• Wenn das Übertragungsgerät keine Daten vom Endeinrichtung mehr empfangen kann, schaltet es die Leitung CTS aus. Erst wenn es wieder Daten aufnehmen kann wird CTS eingeschaltet.
• Symmetrisch dazu schaltet die Endeinrichtung RFR aus, wenn es keine Daten vom Übertragungsgerät empfangen kann und ein, wenn es wieder aufnahmefähig ist.
• Da es sein kann, dass das jeweils sendende Gerät verzögert auf das Ausschalten von CTS bzw. RCR reagiert und weitere Bytes sendet, bevor es die Übertragung unterbricht, sollte das empfangende Gerät CTS bzw. RCR bereits ausschalten, bevor sein Puffer ganz gefüllt ist. In V.43 wird die verzögerte Reaktion der Endeinrichtung auf CTS extra erwähnt und eine verbleibende Puffergröße von mindestens 2000 Bytes im Übertragungsgerät empfohlen. --Bobbl (Diskussion) 13:04, 25. Apr. 2019 (CEST)

Bobbl mach es einfach. Gefällt mir. Gruss --Nightflyer (Diskussion) 22:21, 25. Apr. 2019 (CEST)

Toter Weblink

• http://ftp.tiaonline.org/tr-8/tr812/Working/2001April/TSB-102%20modifications%20DA.doc (archive)
  • In Datenflusskontrolle on 2009-01-16 20:21:24, 401 Access Denied
  • In Datenflusskontrolle on 2009-03-02 20:22:05, 401 Access Denied

Die Webseite wurde vom Internet Archive gespeichert. Bitte verlinke gegebenenfalls eine geeignete archivierte Version: [1]. --SpBot 21:13, 2. Mär. 2009 (CET)

Datenflusssteuerung und Überlastkontrolle differenzieren

Dieser Artikel und der Artikel über Überlastkontrolle überschneiden sich teilweise. Die Unterschiede müssen besser hervorgehoben werden. In der Netzwerktechnik hat die Datenflusssteuerung (flow control) das Ziel, den Empfänger nicht zu überlasten, die Überlastkontrolle (congestion control) hat dagegen das Ziel, das Netzwerk nicht zu überlasten. Die Einführung macht den Eindruck, dass nur verschiedene Datenflusssteuerungs-Verfahren eingesetzt werden. --2A01:C22:3434:1D00:13F3:1FD6:4E0D:F4CA 14:17, 11. Feb. 2019 (CET)

Artikel veraltet, beschreibt im wesentlichen Nicht-LAN-Flusssteuerung

Es fehlen Themen wie IEEE 802.2x (Flow Control in Gigabit-Ethernet-Netzwerken) etc. (nicht signierter Beitrag von Tom.stein (Diskussion | Beiträge) 13:03, 13. Jan. 2020 (CET))

Dem muss ich beipflichten, ich bin auch gerade deswegen hier gelandet, weil ich wissen wollte, was Flow Control bei Ethernet eigentlich genau bedeutet. Evtl. kann das ja mal jemand ergaenzen, der da Bescheid weiss? Veraltet finde ich den Artikel dagegen nicht, die ganzen seriellen Angelegenheiten stimmen ja nach wie vor und sind auch vielfach im Einsatz. --Real-snake (Diskussion) 15:32, 23. Jun. 2023 (CEST)

Im ersten Abschnitt "Datenflusssteuerung auf Protokollebene" wird die Flusskontrolle für Netzwerke thematisiert. Der Abschnitt ist jedoch tatsächlich noch ausbaufähig. Detaillierter ist das in separaten Artikeln wie Sliding Window und ARQ-Protokoll (dessen Link ich gerade in den Artikel hinzufügte) beschrieben. --Uweschwoebel (Diskussion) 17:08, 24. Jun. 2023 (CEST)