Zusammenfassung

  • RFC 2013 definierte vier schreibgeschützte Counter32 für die gesamte UDP-Implementierung: an UDP-Nutzer übergebene Datagramme, Datagramme ohne Anwendung am Zielport, andere Eingabefehler und von der Einheit gesendete Datagramme.
  • Die udpTable indexierte Listener nur über lokale IPv4-Adresse und lokalen Port. Eine Zeile nannte weder entfernte Gegenstelle noch Betriebssystemprozess, Socket-Instanz oder einzelnes Datagramm.
  • RFC 4113 ergänzte lokale und entfernte Adresstypen, Adressen und Ports, einen Instanzwert und eine Prozesskennung. Das verbesserte die Endpoint-Identität, bewies aber keine Anwendungsverarbeitung oder Dienstwirkung.

Vier Kilometerzähler ohne Fahrtenbuch

Die vier UDP-Skalare in RFC 2013 haben präzise Bedeutungen. udpInDatagrams zählt die an UDP-Nutzer gelieferten Datagramme. udpNoPorts erfasst empfangene Datagramme ohne Anwendung am Zielport. udpInErrors sammelt andere Gründe, aus denen eine Eingabe nicht geliefert werden konnte. udpOutDatagrams zählt Sendungen aus der verwalteten Einheit.

Das ist eine nützliche Trennung innerhalb der UDP-Engine. Trotzdem bleibt jeder Wert eine Gesamtsumme. Kein Zähler trägt einen Endpoint-Index, eine entfernte Adresse, einen Prozess, einen Zeitpunkt oder eine Beziehung zwischen Ein- und Ausgabe. Gleichzeitige Bewegungen können zu einer Geschichte passen; sie identifizieren diese Geschichte nicht.

RFC 1902 begrenzte Counter32 zusätzlich: Er steigt bis 2^32−1 und läuft dann über, hat keinen festgelegten Anfangswert und eine einzelne Ablesung besitzt im Allgemeinen keinen Informationsgehalt. Eine Neuinitialisierung kann die Reihe unterbrechen. Für eine Rate braucht man daher zwei Zeitpunkte und Kontinuität. Auch eine korrekte Differenz bleibt eine Differenz der ganzen Einheit.

Die Tabelle endete an der lokalen Tür

udpTable enthielt UDP-Endpunkte, an denen eine lokale Anwendung gerade Datagramme annahm. Der Index bestand aus udpLocalAddress und udpLocalPort. 0.0.0.0 bedeutete, dass ein Listener Datagramme für jede lokale Schnittstelle akzeptierte; die Portnummer lag zwischen 0 und 65535.

Damit konnte ein Manager belegen, dass der Agent zu einem Abfragezeitpunkt eine lokale IPv4-Koordinate als Listener darstellte. Die Zeile hatte kein Feld für eine entfernte Adresse oder einen entfernten Port. Sie nannte keinen Prozess, unterschied keine mehrfach genutzten Sockets und führte keine Zähler je Zeile.

Aus „Anwendung nimmt Datagramme an“ folgt noch kein Anwendungsergebnis. Die Zeile zeigt nicht, ob ein bestimmtes Datagramm den Puffer verließ, syntaktisch gültig war, autorisiert wurde oder eine Aktion auslöste. Sie zeigt weder die Antwort noch deren Ankunft. Eine offene Tür ist keine Niederschrift des Gesprächs hinter ihr.

Die Übergabe an UDP-Nutzer war ein Zwischenbeleg

udpInDatagrams sagt mehr als Paketpräsenz auf einer Schnittstelle: Die Datagramme wurden an UDP-Nutzer übergeben. Diese Transportgrenze ist real und darf nicht verwischt werden. Sie ist aber nicht die Grenze der Anwendung.

Der Zähler belegt nicht, dass Programmcode die Bytes gelesen, verstanden oder verarbeitet hat. udpNoPorts belegt für seine Gesamtmenge das Fehlen einer Anwendung am Zielport, bewahrt aber keinen Absender. udpInErrors fasst sonstige Nichtlieferungen zusammen. udpOutDatagrams endet beim Senden aus der Einheit, nicht beim Empfang im entfernten System.

Für ein Gespräch braucht man deshalb eine Verbindung außerhalb der MIB: Datagramm- oder Ereignisidentität, Endpoint-Zustand, Prozesslebenszyklus, Anwendungsbestätigung und eine Beobachtung des Ergebnisses.

RFC 4113 machte die Identitätslücke sichtbar

RFC 4113 ersetzte RFC 2013 im Jahr 2005. Es behielt die vier Basiszähler, ergänzte Hochkapazitätszähler und verwarf die alte Tabelle aus zwei Gründen: Sie war auf IPv4 begrenzt und konnte „verbundene“ UDP-Endpunkte nicht beschreiben. Der erste Punkt gehört nicht zur Hauptthese dieses Beitrags. Der zweite zeigt, warum eine rein lokale Koordinate für Verantwortlichkeit zu dünn war.

Die udpEndpointTable kann einen Listener mit beliebiger Gegenstelle oder einen Endpoint mit bestimmter entfernter Adresse und Port darstellen. Ihr Index enthält lokale und entfernte Adresstypen, Adressen und Ports sowie udpEndpointInstance. Die Instanz unterscheidet mehrere Prozesse auf demselben Tupel, etwa bei SO_REUSEADDR und SO_REUSEPORT. udpEndpointProcess nennt die Betriebssystemprozess-ID oder null und erlaubt die Korrelation mit Host- oder Anwendungs-MIBs.

Diese Felder beantworten besser, welcher Endpoint und welcher lokale Prozess gemeint sind. Sie machen aus UDP weder eine zuverlässige Sitzung noch aus der Zeile ein Transaktionsprotokoll. Eine PID kann fehlen, wiederverwendet werden und ist nur in ihrem Systemkontext aussagekräftig. Ein konfigurierter Remote-Wert beweist keinen tatsächlich übertragenen Datensatz.

Die größere Sichtbarkeit ist zugleich sensibler: RFC 4113 warnt, dass Endpoint-Indizes offene Ports verraten können. Beobachtung ist kein Eingriff wie der TCP-Schalter in RFC 2012, aber der Zugang zur Beobachtung bleibt zu schützen.

Eine belastbare Aussage behält ihre Maßeinheit

RFC 2013 versprach kein Gesprächsbuch. Falsch wäre erst die spätere Überdehnung: ein Einheitszähler wird einem Dienst zugeschrieben, ein lokaler Port wird zum Gegenüber, „gesendet“ wird zu „zugestellt“, und UDP-Übergabe wird zu Geschäftserfolg.

Die stärkste quellengetreue Aussage lautet: Zwischen zwei kontinuierlichen Messungen änderte sich dieser Zähler der Einheit; zu diesem Zeitpunkt zeigte der Agent jenen lokalen Listener. Eine Zuordnung verlangt Paket- oder Ereignisdaten. Verarbeitung verlangt einen Anwendungsbeleg. Fernzustellung verlangt eine entfernte Beobachtung. Erfolg verlangt eine Messung auf Dienstebene.

Der Port ist eine Koordinate, der Zähler ein Nenner, das Gespräch eine attribuierte Ereigniskette. RFC 4113 erweiterte die Kette. Es erfand ihren Ausgang nicht.

Quellen

Beweisgrenzen

Die Quellen belegen Dokumentgeschichte, Objektdefinitionen, Zählersemantik und Nachfolgemodell. Sie belegen keine Herstellerimplementierung, Verbreitung, aktuelle Voreinstellung, Schwachstelle, Störung, SLA, gemessene Last oder erledigte Anwendungstransaktion.