Zusammenfassung

  • TCP- und UDP-Discard verwarfen auf Port 9 alle empfangenen Daten und antworteten nicht. Die TCP-Verbindung beendete der aufrufende Nutzer.
  • TCP-Verbindungs- und Bestätigungszustände liefern Transportbelege, aber keinen Nachweis eines bestimmten Lese- oder Verwerfschritts im Discard-Prozess.
  • UDP-Schweigen passt zugleich zu erfolgreicher Verarbeitung, Verlust, Filterung und fehlendem Dienst. Ohne unabhängigen Beobachter bleibt die Ursache offen.

Wenn Erfolg keinen Rückkanal hat

Discard entfernte aus einem Messtest die Antwortarbeit. Der Empfänger musste nichts spiegeln, berechnen oder darstellen. Das machte den Dienst als kontrollierte Senke für Fehlersuche und Messung interessant.

Der Preis war fehlende Anwendungsbeobachtung. RFC 863 sagte: Wenn Daten eintreffen, werden sie verworfen und es wird nicht geantwortet. Daraus folgt nicht: Wenn keine Antwort eintrifft, wurden die Daten verworfen. Die Umkehrung verwechselt eine Serverregel mit Fernwissen des Clients.

TCP bestätigt Verantwortung in Schichten

Der TCP-Server hörte auf Port 9, verwarf nach Verbindungsaufbau empfangene Daten und schwieg, bis der aufrufende Nutzer die Verbindung beendete. Ein freiwilliger Erfolgsabschluss durch den Server gehörte nicht zum Ablauf.

Der Handshake zeigt, dass ein entfernter TCP-Endpunkt die Verbindung zu diesem Zeitpunkt angenommen hat. ACKs und Sequenzzustand können den Fortschritt eines Bytestroms belegen. RFC 9293 setzt jedoch eine Grenze: Der empfangende TCP-Endpunkt bestätigt, wenn er Verantwortung für die Übergabe an seinen Nutzer übernimmt. Das ist keine Erklärung des Discard-Prozesses, dass ein konkreter Leseaufruf oder Zähler abgeschlossen ist.

Auch der lokale Rückgabewert kann nur die lokale Warteschlange betreffen. RFC 9293 beschreibt Schnittstellen, die SEND lokal bestätigen, bevor der entfernte TCP-Endpunkt das Segment bestätigt hat. Erst späterer Zustand kann die Aussage erweitern.

Wer den Verbrauch im entfernten Prozess beweisen muss, braucht Prozessmetrik, kontrollierte Aufnahme oder einen getrennten Kontrollkanal. Dieser Beleg wird vom Versuchsaufbau hinzugefügt; RFC 863 liefert ihn nicht.

UDP gibt mehreren Ursachen dasselbe Erscheinungsbild

Der UDP-Server verwarf jedes auf Port 9 empfangene Datagramm ohne Antwort. RFC 768 garantiert weder Zustellung noch Duplikatschutz. Erfolg, Pfadverlust, Richtlinienfilter und fehlender Listener können deshalb am Sender alle als Stille erscheinen.

RFC 8085 warnt außerdem, dass ICMP durch Zwischensysteme gefiltert wird und UDP-Anwendungen nicht auf seine Zustellung angewiesen sein dürfen. Ein validierter Fehler ist ein Signal; kein Fehler ist kein Gegenbeweis.

Eine belastbare Messung kontrolliert eine zweite Stelle: Empfangszähler, Paketaufnahme und feste Beobachtungsfrist. Ohne sie misst „null Antworten“ nur Antworten, nicht Zustellung.

Die Abgrenzung zu Echo und Chargen

Echo sendet Eingaben zurück, Character Generator erzeugt Antworten. Discard entfernt die Anwendungsantwort und kann daher nicht denselben Echo/Chargen-Rückkopplungszyklus bilden. Die geschlossenen Quellen belegen weder aktuelle Missbrauchshäufigkeit noch universelle Leistungswerte.

Eine stille Senke verbraucht trotzdem Bandbreite, Puffer und gegebenenfalls Verbindungszustand. Das operative Urteil betrifft Lastgenehmigung, Kapazitätsgrenzen und Attribution, nicht eine erfundene Reflexionszahl.

Portzuweisung und laufender Prozess

IANA führt discard für TCP und UDP auf Port 9 sowie weitere Zeilen für SCTP und DCCP. RFC 863 definiert TCP und UDP unmittelbar. Der Eintrag bewahrt eine Namenskonvention, startet aber keinen Dienst.

RFC 6335 ordnet Port 9 den System Ports zu und unterscheidet zugewiesene, freie und reservierte Werte. Zugewiesen ist ein Registry-Zustand. Er beweist weder Listener noch Konformität, Identität, Berechtigung oder sinnvolle öffentliche Erreichbarkeit.

Gerade bei UDP kann das Register die fehlende Antwort nicht ersetzen. Bei TCP ist eine Verbindung stärker als der Registereintrag, doch auch sie authentifiziert nicht automatisch den Prozess hinter der Nummer.

Die Aussage bestimmt das Messgerät

Lokale Pufferannahme, entfernte TCP-Verantwortung, Lesevorgang des Prozesses und UDP-Zustellrate sind vier verschiedene Aussagen. Sie benötigen lokale API-Daten, ACK-Zustand, Empfängermetrik beziehungsweise kontrollierte Ankunftszähler.

Ein Bericht sollte Transport, Tupel, Zeit, Bytes, Wiederholungen, Fehler, Schließinitiator und Beobachtungsort erhalten. Kommt unerwartet eine Anwendungsantwort, wird sie gesichert: Der Endpunkt verhält sich nicht wie RFC-863-Discard. Der Portname allein erklärt nicht, welcher Dienst geantwortet hat.

Quellen und Grenzen

Der Mechanismus stammt aus RFC 863, die elective-Einstufung aus RFC 880. TCP-Grenzen liefert RFC 9293. UDP-Grundlagen kommen aus RFC 768, heutige ICMP- und Anwendungshinweise aus RFC 8085.

Die Nummernverwaltung folgt RFC 6335 und dem IANA-Register. Diese Quellen messen keine heutige Bereitstellung, Leistung, Last oder Angriffe und identifizieren keinen lebenden Server.