Einblicke in den CustomPeerResolverService: Clientregistrierungen
Jeder Knoten im Netz veröffentlicht seine Endpunktinformationen für den Resolverdienst durch die Register-Funktion. Der Resolverdienst speichert diese Informationen als Registrierungsdatensatz. Dieser Datensatz enthält einen eindeutigen Bezeichner (RegistrationID) sowie Endpunktinformationen (PeerNodeAddress) für den Knoten.
Veraltete Datensätze und Ablaufzeit
Idealerweise ruft ein Knoten beim Verlassen des Netzes die Unregister- Funktion auf, wodurch der Registrierungseintrag vom Resolverdienst entfernt wird. Manchmal werden Knoten jedoch geschlossen oder nicht verfügbar, bevor Unregister aufgerufen wurde. Dadurch bleibt ein veralteter Registrierungsdatensatz zurück.
Veraltete Datensätze im Resolverdienst können zu fehlerhaften Verbindungen führen. Erhält ein Knoten beim Versuch, eine Verbindung mit einem Netz herzustellen, veraltete Verbindungsinformationen vom Resolverdienst, dauert es ggf. länger, bis er eine erfolgreiche Verknüpfung zu dem Netz herstellen kann. Veraltete Datensätze belegen zudem Speicherplatz. Ohne effizienten Bereinigungsprozess kann ein Überlauf des Zwischenspeichers auftreten, in dem die Registrierungen gespeichert werden, was den Absturz des Resolverdiensts zur Folge haben kann.
Der CustomPeerResolverService versieht jeden Datensatz mit einer Ablaufzeit (DateTime) und speichert diese Information zusammen mit dem Datensatz. Anhand der Ablaufzeit werden veraltete Datensätze durch den Dienst erkannt. Eine solche Vorgehensweise empfiehlt sich auch bei benutzerdefinierten Implementierungen.
RefreshInterval und CleanupInterval
Mit der RefreshInterval-Eigenschaft des CustomPeerResolverService wird die Gültigkeitsdauer von Registrierungsdatensätzen in der Registrierungssuchtabelle des Diensts definiert. Ist die für diese Eigenschaft angegebene Zeit für einen bestimmten Datensatz abgelaufen, ist dieser Datensatz veraltet und wird zum Löschen markiert.
Mithilfe der CleanupInterval-Eigenschaft des CustomPeerResolverService wird dem Dienst mitgeteilt, wie häufig veraltete Registrierungsdatensätze gesucht und gelöscht werden sollen. Das CleanupInterval sollte auf eine Zeit festgelegt werden, die mindestens dem für den Dienst festgelegten RefreshInterval entspricht.
Wenn Sie einen eigenen Resolverdienst implementieren möchten, müssen Sie eine Wartungsfunktion zum Entfernen veralteter Registrierungsdatensätze schreiben. Dafür stehen verschiedene Möglichkeiten zur Verfügung:
Periodische Wartung: Legen Sie einen periodischen Timer fest, und durchsuchen Sie den Datenspeicher, um alte Datensätze zu löschen. Dieser Ansatz wird vom CustomPeerResolverService verwendet.
Passives Löschen: Anstatt regelmäßig aktiv nach veralteten Datensätzen zu suchen, können veraltete Datensätze auch identifiziert und gelöscht werden, wenn vom Dienst gerade eine andere Funktion ausgeführt wird. Dadurch erhöht sich zwar möglicherweise die Antwortzeit für Anforderungen der Resolverclients, andererseits wird in diesem Fall kein Timer benötigt. Darüber hinaus ist diese Methode möglicherweise effizienter, wenn voraussichtlich nur wenige Knoten das Netz ohne Aufruf von Unregister verlassen.
RegistrationLifetime und Refresh
Wenn sich ein Knoten bei einem Resolverdienst registriert, erhält er vom Dienst ein RegisterResponseInfo-Objekt. Dieses Objekt besitzt eine RegistrationLifetime-Eigenschaft, mit der dem Knoten die verbleibende Zeit bis zum Ablauf der Registrierung und damit bis zur Entfernung durch den Resolverdienst angegeben wird. Beispiel: Beträgt die RegistrationLifetime zwei Minuten, muss durch den Knoten in weniger als zwei Minuten ein Aufruf von Refresh erfolgen, damit der Datensatz nicht als veraltet gilt und gelöscht wird. Erhält der Resolverdienst eine Refresh-Anforderung, sucht er den Datensatz und setzt die Ablaufzeit zurück. Durch die Refresh-Anforderung wird ein RefreshResponseInfo-Objekt mit einer RegistrationLifetime-Eigenschaft zurückgegeben.
Beispiele für Peerkanäle
Peer Channel Custom Peer Resolver