Identification Caching
The identification caching provides you an advantage especially when using remote user interfaces and distributed systems. Identification caching allows the identification to be sent as “delta” instead of the whole identification. Thus, only the changes are sent by the Data and the Dist managers.
Inkrementelle Identification Updates
Das Identification-Caching bietet einen Vorteil, besonders wenn abgesetzte Benutzeroberflächen und verteilte Systeme eingesetzt werden. Identification-Caching erlaubt es, die Identificationals "Delta" anstatt der ganzen Identification zu senden. Dadurch werden nur Änderungen von Data- und Dist-Managerngesendet. Das Senden von Deltas (nur Änderungen) beschleunigt den Prozess deutlich. Ein abgesetztes UI oder ein Dist-Manager erhält nur die Änderungen der Identification. Ein UI oder der Dist-Manager verwendet die Änderungen, um die Identification auf den neuesten Stand zu bringen. Anders gesagt, wenn ein Manager (ein Dist-Manager oder ein abgesetztes UI) eine nicht aktuelle Identification besitzt, kann diese durch "Deltas" aktualisiert werden. Die Deltas werden bei einem Verbindungsaufbau der Dist-Manager sowie beim Neustart eines abgesetzten UIs übertragen. Dadurch werden in einem verteilten System im Falle von Netzwerkausfall statt der ganzen Identification nur die Änderungen gesendet.
Identification-Caching
Der Begriff Identification -Caching umfasst nicht nur das Senden von "Deltas", sondern auch das Caching von Identification.
Was ist eine Identification
Eine Identification enthält die Struktur der Datentypen im "TypeContainer" und die Datenpunkt-Identificationen("DP IDs"). CNS und Zeitstempel sind wiederum ein Teil der DP ID. Pro System gibt es eine Identification.
Auch bei der Konfiguration eines verteilten Systems wird die Identifikation der Systeme ausgetauscht, um mit den DPs auf Fremdsystemen arbeiten zu können (siehe auch Prinzip und Funktionsweise bei verteilten Systemen). Die Identification bezieht ein Manager vom Data-Manager, der diese verwaltet (Ausnahme: bei der Verwendung des Identification-Caching wird die Identifikation in Dateien auf die Festplatte abgelegt).
Identification-Caching (abgesetztes UI):
Ein abgesetztes UI schreibt seine Identification auf die Festplatte und liest die gecachte Identification beim Hochlauf. Danach fordert das UI die Änderungen von Data-Manager an.
Identification -Caching - abgesetztes UI
Identification-Caching (Dist-Manager):
Wenn der Dist-Manager neu gestartet wird, aber der Data-Manager des Systems läuft weiterhin, erhält der Dist-Manager vom Data-Manager die notwendigen Informationen für alle Remote-Systeme, um von Remote-Systemen die Updates für diese Identificationen anzufordern.
Identification-Caching (Data manager):
Der Data-Manager speichert die Identification des eigenen Systems in der Datenbank aber die Identificationen von fremden Systemen bleiben nur im RAM. Wenn das System und dadurch der Data-Manager neu gestartet wird, gehen die Identificationen der fremden Systeme verloren. Wenn der Dist-Manager eine Verbindung zu einem fremden Dist-System baut, musste ohne "Identification Caching" die komplette Identification des spezifischen Systems erfordert werden. Mit der Identification Caching schreibt der Data-Manager die fremden Identificationen auf die Festplatte. Wenn das System und der Data-Manager neu gestartet werden, liest der Data-Manager die fremden Identificationen von der Festplatte. Dadurch besitzt das System alle Identificationen, die vorhanden waren, wenn das System gestoppt wurde. Folglich kann der Dist-Manager nur die Änderungen von einem fremden Dist-System verlangen, als ob das System gar nicht gestoppt wurde.
Identification-Caching bietet den Vorteil, dass es sofort für alle Manager verfügbar ist. Der Dist-Manager fordert nur Änderungen von anderen Systemen an. Dies reduziert die Zeit, die das System zum Hochfahren nach einem Neustart benötigt, sowie die Zeit beim Einsatz von langsamen Netzwerkverbindungen.
Funktionalität
Beide, der Dist-Manager und der Data-Manager, puffern die Änderungsnachrichten der Identification.
Die Identification jedes Systems enthält einen Zeitstempel. Der Zeitstempel ist ein Teil der DP-Identification. Jedes Mal wenn die Identification sich ändert, wird der Zeitstempel um eins erhöht. Wenn ein Dist-Manager eine Verbindung zu einem anderen System aufbaut, fordert der Dist-Manager die Änderungen entsprechend dem aktuellen Zeitstempel der Remote-Identification. Nur Änderungen ab dem aktuellen Zeitstempel werden gesendet.
Clients, welche die Identification auf die Festplatte cachen, kennen beim Start die Zeitstempel aller Identificationen und können dadurch nur die Änderungen anfordern, die nach diesen Zeitstempeln aufgetreten sind.
Konfiguration
Defaultmäßig ist das Identification-Caching deaktiviert. Das Identification-Caching schreibt die Identification auf die Festplatte, wenn ein Manager stoppt und liest diese von der Festplatte, wenn ein Manager startet. Um die "Identification-Caching" zu aktivieren, setzten Sie den Config-Eintrag useLocalIdentification = 1 in der [data]-Sektion der Config-Datei.
Mehrere Manager auf einem Client
Wenn Identification-Caching auf einem abgesetzten UI verwendet wird und auf diesem UI mehrere Manager (UI, CTRL oder API) gestartet werden sollen, müssen die Manager mit der Option -num gestartet werden.
Config-Einträge
Die folgenden Config-Einträge können für Identification-Caching verwendet werden.
Lokale Identification - Config-Eintrag "useLocalIdentification"
Speziell für langsame Verbindungen (z.B. abgesetzte UIs über Modem Verbindung) ist die Startphase eines Managers, wenn die ganze Identification übertragen wird, bei größeren Projekten mitunter sehr lang. Um das zu verbessern, kann die Identification am lokalen Rechner gespeichert werden. Die Identification Caching ist defaultmäßig deaktiviert. Um die Identification Caching zu aktivieren, verwenden Sie den Config-Eintrag useLocalIdentification, der in der [data]-Sektion der Config-Datei gesetzt werden kann.
Beim ersten Start des Managers (für den der Config-Eintrag gesetzt ist) wird die
Identification vom Data-Manager übertragen (da zu dieser Zeit die Dateien für die
lokale Identification noch nicht angelegt sind). Während der Manager läuft,
verarbeitet er ganz normal alle Änderungen. Beim Beenden schreibt er die aktuelle
Identification in die Dateien DpMsgTypeContainer.binund
DpMsgIdentification.bin. Diese Dateien werden
schließlich im Verzeichnis <proj_path>/dataangelegt.
Wenn ein Manager (abgesetztes UI, Dist) erneut startet, fordert er die Änderungen der Identification vom Data-Manager an.
Config-Eintrag maxUpdateMsgCount für die Data- und Dist-Manager
Immer wenn sich die Identification ändert, erstellt der Data-Manager eine Notifizierungsnachricht, z.B. DP_MSG_MANIP_DP, um über neue oder gelöschte Datenpunkte zu informieren, welche über den Event-Manager an alle Manager, die auf diesem System laufen, verteilt werden und über den Dist-Manager an alle anderen Systeme. Ein Manager der solche Nachrichten empfängt, aktualisiert die Identification und erhöht den Zeitstempel dieser Identification.
Die Data- und Dist-Manager puffern diese Nachrichten. Der Data-Manager puffert die Nachrichten für alle Systeme und der Dist-Manager nur für das eigene System.
Wenn ein Manager die Änderungen seit dem Zeitstempel verlangt, z.B. ein Client vom Data-Manager oder ein Dist-Manager von einem abgesetzten System, versuchen der Data-Manager oder der abgesetzter Dist-Manager die Anfragen über Notfizierungnachrichten aus dem Puffer zufrieden zu stellen. Die Nachrichten werden benötigt, um die Identification zu aktualisieren (d.h. nur die Notifizierungsnachrichten nach dem Zeitstempel in der Anfrage).
Um zu verhindern, dass der Puffer unbegrenzt wächst, ist die Anzahl der Notifizierungsnachrichten im Puffer limitiert. Die Größe kann über den Config-Eintrag maxUpdateMsgCount in der [data] oder [dist]-Sektion der Config-Datei angegeben werden.
Wenn der Data- oder der Dist-Manager die Anfrage nicht durch das Senden von Notifizierungnachrichten zufrieden stellen kann, d.h., wenn der Zeitstempel in der Anfrage zu alt ist, wird die ganze Identification gesendet.
Config-Eintrag " updateStatusForHiddenSystems"
Wenn der One-Way-Dist verwendet wird, wird es dem Dist-Manager ermöglicht, sich zwar zu allen gewünschten Systemen zu verbinden, die Identification aber nur von ausgewählten Systemen abzufragen (siehe Config-Eintrag distSystemIds). Somit ist den Systemen bzw. deren Managern immer noch bekannt, ob die Verbindung zum Partnersystem besteht, das betreffende System wird aber nicht im Systemübersichtspanel angezeigt bzw. kann auf dessen Datenpunkte nicht zugegriffen werden.
Der Config-Eintrag updateStatusForHiddenSystems kann für Systeme, welche nicht in der distSystemIds- Liste enthalten sind, verwendet werden. Mit dem Eintrag updateStatusForHiddenSystems aktivieren Sie die Status-Updates der Identification für diese Systeme.
