Anhang C. Duplikaterkennung

Anhang C. Duplikaterkennung

Wie in Abschnitt 9.4 beschrieben, basiert die Duplikaterkennung von Accounting-Datensätzen auf Sitzungskennungen. Duplikate können aus verschiedenen Gründen auftreten:

• Failover zu einem alternativen Server. Ist nahezu Echtzeit-Leistung erforderlich, müssen Failover-Schwellen niedrig gehalten werden, was die Wahrscheinlichkeit von Duplikaten erhöhen kann. Failover kann beim Client oder innerhalb von Diameter-Agenten auftreten.

• Ausfall eines Clients oder Agenten nach dem Senden eines Datensatzes aus nichtflüchtigem Speicher, aber vor Empfang eines Anwendungs-ACK und Löschen des zu sendenden Datensatzes. Dies führt bald nach dem Neustart des Clients oder Agenten zur erneuten Übertragung des Datensatzes.

• Duplikate von RADIUS-Gateways. Da das Retransmissionsverhalten von RADIUS in [RFC2865] nicht definiert ist, variiert die Duplikatswahrscheinlichkeit je nach Implementierung.

• Implementierungsprobleme und Fehlkonfiguration.

Das T-Bit dient als Hinweis auf ein Retransmissionsereignis auf Anwendungsebene, z. B. durch Failover zu einem alternativen Server. Es ist nur für Anforderungsnachrichten von Diameter-Clients oder -Agenten definiert. Nach einem Neustart weiß ein Client beispielsweise möglicherweise nicht, ob er die Accounting-Datensätze im nichtflüchtigen Speicher vor dem Neustart bereits zu senden versucht hat. Diameter-Server DÜRFEN das T-Bit bei der Verarbeitung von Anfragen und der Erkennung doppelter Nachrichten unterstützen. Server, die dies tun, MÜSSEN jedoch sicherstellen, dass Duplikate auch dann gefunden werden, wenn die zuerst gesendete Anforderung nach der retransmitierten Anforderung am Server eintrifft. Es darf nur verwendet werden, wenn für eine Anforderung keine Antwort vom Server eingegangen ist und die Anforderung erneut gesendet wird (z. B. Failover zu einem alternativen Peer, Wiederherstellung des primären Peers oder erneutes Senden eines gespeicherten Datensatzes aus nichtflüchtigem Speicher nach Neustart eines Clients oder Agenten).

In manchen Fällen kann der Diameter-Accounting-Server Duplikaterkennung und Verarbeitung der Accounting-Datensätze bis zu einer Nachverarbeitungsphase verzögern. Dann werden Datensätze typischerweise nach dem enthaltenen User-Name sortiert, und die Duplikateliminierung ist einfach. In anderen Situationen kann eine Echtzeit-Duplikaterkennung nötig sein, z. B. bei Kreditlimits oder gewünschter Echtzeit-Betrugserkennung.

Im Allgemeinen können nur durch Failover oder erneutes Senden von Datensätzen im nichtflüchtigen Speicher entstehende Duplikate zuverlässig von Diameter-Clients oder -Agenten erkannt werden. In solchen Fällen kann der Client oder Agent die Nachricht durch Setzen des T-Bits als mögliches Duplikat markieren. Da der Diameter-Server für die Duplikaterkennung verantwortlich ist, kann er wählen, ob er das T-Bit zur Optimierung nutzt. Da das T-Bit die Interoperabilität nicht beeinflusst und manche Server es nicht brauchen, ist die Erzeugung des T-Bits für Diameter-Clients und -Agenten ERFORDERLICH, Diameter-Server DÜRFEN es jedoch implementieren.

Beispielsweise kann in der Regel angenommen werden, dass Duplikate innerhalb eines Zeitfensters der längsten erfassten Netzpartition oder Gerätestörung auftreten, vielleicht eines Tages. Daher müssen nur Datensätze in diesem Fenster rückwärts betrachtet werden. Zweitens können Hash-Techniken oder andere Verfahren, z. B. die Nutzung des T-Bits in empfangenen Nachrichten, eine vollständige Suche in dieser Menge außer in seltenen Fällen vermeiden.

Im Folgenden ein Beispiel, wie der Server das T-Bit zur Erkennung doppelter Anfragen nutzen kann.

Ein Diameter-Server DARF das T-Bit der empfangenen Nachricht prüfen, um festzustellen, ob der Datensatz ein mögliches Duplikat ist. Ist das T-Bit in der Anforderung gesetzt, sucht der Server in einem konfigurierbaren Duplikatszeitfenster rückwärts und vorwärts nach einem Duplikat. Damit wird die Datenbanksuche auf Datensätze mit gesetztem T-Bit begrenzt. In einem gut geführten Netz sind Netzpartitionen und Geräteausfälle vermutlich selten, sodass dies den Duplikaterkennungsprozess stark optimiert. Während eines Failovers kann der ursprüngliche Datensatz nach dem mit T markierten ankommen, weil sich die Netzverzögerungen auf dem Pfad unterscheiden. Die Wahrscheinlichkeit steigt, wenn das Failover-Intervall sinkt. Um auch außer der Reihe eintreffende Duplikate zu erkennen, sollte der Diameter-Server bei der Duplikatprüfung für T-markierte Anfragen rückwärts- und vorwärtsgerichtete Zeitfenster verwenden. Beispielsweise kann der Server die Verarbeitung von Datensätzen mit T-Bit verzögern, bis nach Schließen der ursprünglichen Transportverbindung die Zeit TIME_WAIT + RECORD_PROCESSING_TIME vergangen ist, damit der ursprüngliche Datensatz das Netz verlassen und vom Accounting-Server erfasst werden kann. Danach kann er T-markierte Datensätze mit der Datenbank abgleichen, mit relativer Sicherheit, dass ursprüngliche Datensätze – falls gesendet – empfangen und gespeichert wurden.