DE112015004699T5

DE112015004699T5 - Über mehrere Sites verteiltes Sicherheitssystem

Info

Publication number: DE112015004699T5
Application number: DE112015004699.2T
Authority: DE
Inventors: P. Marlatt Shaun; W. Chiang Avery; Tomer Goldenberg; J. Adam Matthew; E. B. Grieman Jonathan
Original assignee: Avigilon Corp
Current assignee: Motorola Solutions Inc
Priority date: 2014-10-15
Filing date: 2015-10-15
Publication date: 2017-08-24
Also published as: CA2964485C; US20160110993A1; CA2964485A1; US10810863B2; WO2016061407A1

Abstract

Ein physisches Sicherheitssystem, das Sites, verbunden mit Kameras, definieren kann. Sites können als eine Child Site entfernt von einer Parent Site hinzugefügt werden, um eine Site Family zu bilden. Nach Rang geordnete Benutzer- und Gruppenprivilegien können, nachdem sie eingestellt wurden, an die Child Sites übertragen und von der Parent Site kontrolliert werden. Die Child Sites können weiterhin lokale Benutzer und Gruppen definieren, damit die Child Site den Betrieb fortsetzen kann, wenn die Verbindung zur Parent Site unterbrochen wird.

Description

HINTERGRUND
Bei einem physischen Sicherheitssystem handelt es sich um ein System, das Maßnahmen durchführt, um unbefugte Personen daran zu hindern, sich physisch Zugang zu einem Vermögensgegenstand, wie z. B. einem Gebäude, einer Anlage oder vertraulichen Informationen zu verschaffen. Als Beispiele für physische Sicherheitssysteme können Überwachungssysteme genannt werden, wie z. B ein System, in dem Kameras eingesetzt werden, um den Vermögensgegenstand und in seiner Nähe befindliche Personen zu überwachen, Zugangskontrollsysteme, wie z. B. ein System, das RFID-Karten verwendet, um den Zugang zu einem Gebäude zu kontrollieren, Einbruchmeldesysteme, wie z. B. Haus- oder Einbruchsalarmsysteme sowie Kombinationen der vorstehend genannten Systeme.
Ein physisches Sicherheitssystem umfasst meist auch Computer. In dem Umfang, in dem diese Art von physischem Sicherheitssystem wächst, steigt auch die für den Betrieb des Systems benötigte Rechnerleistung. So steigt die erforderliche Rechnerleistung beispielsweise mit der Anzahl der in einem Überwachungssystem eingesetzten Kameras, um die Speicherung von zusätzlichen Videoaufzeichnungen und die gleichzeitige Verwendung und Handhabung einer höheren Anzahl von Kameras zu ermöglichen. Die Kontrolle und der Schutz solcher Computer und des physischen Sicherheitssystems in seiner Gesamtheit stellen ein wichtiges Thema dar.
ZUSAMMENFASSUNG
Durch ein physisches Sicherheitssystem können mit Sicherheitskameras, Zugangskontrollfeldern, Sensorsteuerungsmonitoren und anderen ähnlichen Überwachungsgeräten verbundene Sites definiert werden. Eine Site kann eine Anzahl von Knoten umfassen, die synchronisiert sein können. Eine Site kann als Parent Site konfiguriert sein, und mehrere Sites können kommunikativ an diese Parent Site gekoppelt sein, um eine „Site Family“ zu bilden, die nachfolgend als solche bezeichnet wird. In einer konfigurierten Site Family können nach Rang geordnete Benutzer- und Gruppenprivilegien auf die Child Sites verlagert und durch die Parent Site kontrolliert werden. Die Child Sites können weiterhin lokale Benutzer und Gruppen definieren, damit die Child Site den Betrieb fortsetzen kann, wenn die Verbindung zur Parent Site unterbrochen wird.
Serverknoten/Speicherknoten/Kameras/Geräte können in eine Site mit einer Reihe von Benutzern gruppiert werden, die eine Zugangsberechtigung für die Geräte auf dieser Site haben. Eine Site kann sich an einem einzigen Ort befinden, wie beispielsweise in einem durch physische Sicherheitsprodukte geschützten Gebäude. Eine Site kann ein Cluster von Servern umfassen, die für Redundanz sorgen. Bei einer Site Family kann es sich um eine Gruppe von Sites handeln, wie beispielsweise mehrere Gebäude, die nahe beieinander liegen müssen und die kollektiv als „Site Families“ bezeichnet werden. Site Families können hierarchische und gruppierte Benutzerrechte mit gruppierten Zugangsberechtigungen oder -attributen zulassen.
Das Sicherheitspersonal, das die jeweilige Site betreibt, kann verschieden sein und unterschiedlich verwaltet werden, bzw. unterschiedliches Vertrauen genießen. Das Site Families Feature ermöglicht es einer Parent Site, die Berechtigungen jeder Site in der Familie unterschiedlich zu handhaben, indem Attribute für alle Mitglieder einer Site angewendet oder geändert werden, ohne dass eine Änderung der Attribute anderer Sites stattfindet. Das Konzept des „Rangs“ entscheidet, welche Benutzer die Berechtigungen (oder die Attribute von Berechtigungen) anderer Benutzer ändern dürfen.
Darüber hinaus können die Child Sites durch die Parent Sites konfiguriert werden. Diese Konfiguration kann Regeln, Alarme, Benutzer und Gruppen, Netzwerkendpunkte für Fernzugang, Standardgeräteeinstellungen, Standardaufzeichnungspläne und andere Systemstandards umfassen. Auf diese Weise kann der Zeitaufwand reduziert werden, der für das manuelle Einrichten der Child Site erforderlich ist. Hinsichtlich der Konfiguration der Child Site kann zur Notfallwiederherstellung und für den einfachen Austausch von Sites und Servern auf der Parent Site ein Backup erstellt werden.
Hierarchische Zugangsberechtigungen können für physische Sicherheitssysteme verwendet werden, bei denen die Parent Sites eine größere Kontrolle ermöglichen. Eine verteilte Berechtigungsdatenbank kann so synchronisiert werden, dass eine lokale Site zuverlässig weiter betrieben werden kann, falls es zu einem länger andauernden Netzwerkausfall oder zu einem Verbindungsausfall zwischen den Sites kommt. Eine Benutzerhierarchie in Baumstruktur kann auf einer grafischen Benutzeroberfläche (GUI) angezeigt werden, wobei die Möglichkeit besteht, Child Sites hinzuzufügen oder zu entfernen.
Die Sites (einschließlich der Child Sites) können Knoten umfassen, die kommunikativ gekoppelt und in der Lage sind, hierin beschriebene Programme und Nicht-Knoten-Geräte, Sensoren und mit diesen Knoten verbundene und von ihnen verwaltete Aktuatoren auszuführen. Bei den Knoten kann es sich um handelsübliche Computer, Kameras, Zugangskontrollfelder, Netzwerkschalter und andere geeignete Geräte handeln. Knoten können mit anderen (Nicht-Knoten)-Geräten wie Kameras, Zugangskontrollfeldern, Bewegungssensoren, Zahlungsverkehrsquellen, Sensoren oder anderen Geräten, die nicht in der Lage sind, die hierin beschriebenen Programme durchzuführen, gekoppelt werden. Ein verteiltes Site Management System kann das Management von Überwachungssystemen, Zugangskontrollsystemen sowie von hybriden Video- und Zugangskontrollsystemen erleichtern.
Diese Zusammenfassung beschreibt nicht notwendigerweise den gesamten Umfang aller Aspekte. Andere Aspekte, Eigenschaften und Vorteile werden für Fachleute bei der Durchsicht der folgenden Beschreibung konkreter Ausführungsformen offensichtlich sein.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
1 ist ein Diagramm, das ein beispielhaftes System veranschaulicht, in dem Sites eine Anzahl von Knoten aufweisen.
2 ist ein Blockdiagramm einer beispielhaften Protokollsuite für das System in 1.
3 ist ein beispielhaftes Unified Modeling Language(UML)Sequenzdiagramm, das veranschaulicht, wie das System von 1 Einstellungen zwischen verschiedenen Systembenutzern teilt.
4 ist ein UML-Sequenzdiagramm, das veranschaulicht, wie das System von 1 einen Zustand zwischen verschiedenen Systembenutzern teilt.
5 ist ein UML-Sequenzdiagramm, das veranschaulicht, wie das System von 1 eine Ansicht zwischen verschiedenen Systembenutzern teilt.
6 ist ein UML-Sequenzdiagramm, das veranschaulicht, wie das System von 1 Streams zwischen verschiedenen Systembenutzern teilt.
7 ist ein Beispiel für eine vom System von 1 zur Verfügung gestellte Benutzerschnittstelle.
8 veranschaulicht ein Flussblockdiagramm einer Methode zum Teilen von Daten in einem physischen Sicherheitssystem gemäß einer anderen Ausführungsform.
9 veranschaulicht ein Flussblockdiagramm einer Methode zum automatischen Wiederaufrufen einer Site gemäß einer anderen Ausführungsform.
10 ist ein Diagramm, das einen beispielhaften Knoten in einem Sicherheitssystem veranschaulicht.
11A ist ein Diagramm, das ein physisches Modell einer Site für eine Video Management System (VMS) Anwendung veranschaulicht.
11B ist ein Diagramm, das eine beispielhafte Systemarchitektur für ein Kameraüberwachungs- und Zugangskontrollsystem veranschaulicht.
12 ist ein Diagramm, das eine Site-to-Site-Kommunikationshierarchie für eine Site Family mit drei Child Sites veranschaulicht, die über ein Weitverkehrsnetz (wide-area network) mit der Parent Site verbunden sind.
13 ist ein Diagramm, das eine Benutzerschnittstelle für das Site-Management einer Child Site veranschaulicht.
14 ist eine Nachrichtenabfolgetabelle, die den Ablauf für die Verbindung einer Site mit einer Parent Site veranschaulicht.
15 ist ein Diagramm, das eine Benutzerschnittstelle für das Site-Management von Parent Sites veranschaulicht.
16 ist ein Diagramm, das den Rang als Baumstruktur veranschaulicht.
17 ist ein Diagramm von Objekten, denen ein Rang zugewiesen wurde.
18 ist ein Diagramm, das eine Benutzerschnittstelle für das Hinzufügen oder Bearbeiten einer Gruppe von Child-Knoten veranschaulicht.
19 ist ein Diagramm, das eine Benutzerschnittstelle für das Einrichten von Benutzern und Gruppen auf dem Parent veranschaulicht.
20 ist eine Nachrichtenabfolgetabelle, die ein von der Child Site verwendetes Fernauthentifizierungsverfahren veranschaulicht.
DETAILLIERTE BESCHREIBUNG VON VERANSCHAULICHENDEN
AUSFÜHRUNGSFORMEN
„Sicherheitssoftware“ kann eine Softwareplattform sein, die auf jeder Netzwerk-Hardware installiert werden kann, die in der Lage ist, ein Softwareprogramm auszuführen. Beispiele für solche Hardware sind Netzwerk-Videorecorder (NVR), Schalter und IP-Kameras. Weitere Beispiele für solche Hardware sind Schalter, Zugangskontrollfelder, Näherungsleser, Smartcardleser, Fingerabdruckleser und Magnetstreifenleser. Wenn sie in der Netzwerk-Hardware installiert wird, kann die Sicherheitssoftwareplattform die Geräte in logischen Systemen organisieren, die in der Lage sind, anwendungsspezifische Aufgaben durchzuführen.
Hardwaresysteme (eine Sammlung von Sensoren, Kameras, NVR und Schaltern) können in Videomanagementsystemen organisiert werden. Andere Anwendungen, wie z. B. Business Intelligence und Zugangskontrolle, können ebenfalls unterstützt werden. Diese Anwendungen können gleichzeitig auf der gleichen Plattform unterstützt werden, sodass die Hardwareressourcen effizienter genutzt werden.
1–9 beschreiben ein beispielhaftes innerhalb einer Site mit mehreren Knoten verteiltes Sicherheitssystem. 10–20 veranschaulichen ein zwischen mehreren Sites verteiltes Sicherheitssystem.
1 zeigt ein verteiltes physisches Sicherheitssystem in Form eines Überwachungssystems 100 gemäß einer Ausführungsform. Das System 100 umfasst drei Clients 102a–c (erster Client 102a bis dritter Client 102c und zusammen „Clients 102“), sechs Server 104a–f (erster Server 104a bis sechster Server 104f und zusammen „Server 104“), drei Serverknotenkameras 106a–c (erste Knotenkamera 106a bis dritte Knotenkamera 106c und zusammen „Knotenkameras 106“) und fünf Nicht-Knoten-Kameras 114.
Jede der Knotenkameras 106 und jeder der Server 104 umfasst einen Prozessor 110 und einen Speicher 112, die kommunikativ miteinander verbunden sind, wobei auf dem Speicher 112 Angaben und Anweisungen kodiert sind, die den Prozessor 110 veranlassen, jegliche Ausführungsformen der hierin beschriebenen Methoden durchzuführen. Die Server 104 und die Knotenkameras 106 sind in drei Sites 108a–c (zusammen „Sites 108“) gruppiert: die ersten bis dritten Server 104a–c sind kommunikativ aneinander gekoppelt, um eine erste Site 108a zu bilden; die vierten bis sechsten Server 104d–f sind kommunikativ aneinander gekoppelt, um eine zweite Site 108b zu bilden; und die drei Knotenkameras 106 sind kommunikativ aneinander gekoppelt, um eine dritte Site 108c zu bilden. Die ersten bis dritten Server 104a–c werden als „Mitglieder“ der ersten Site 108a bezeichnet; die vierten bis sechsten Server 104d–f werden als „Mitglieder“ der zweiten Site 108b bezeichnet; und die ersten bis dritten Knotenkameras 106a–c werden als „Mitglieder“ der dritten Site 108c bezeichnet. Andere Sensoren als die Kameras 106 und 114 können auch mit Knoten und Sites assoziiert werden.
Bei den Servern 104 und den Knotenkameras 106 handelt es sich um „Serverknoten“, da jeder/jede davon die Anwesenheit der anderen Mitglieder seiner/ihrer Site 108 erkennt und jeder/jede Daten an die anderen Mitglieder seiner/ihrer Site 108 senden kann; im Gegensatz dazu handelt es sich bei den Nicht-Knoten-Kameras 114 um Nicht-Serverknoten, da sie nur die Server 104a–f erkennen, an die sie direkt angeschlossen sind. In der abgebildeten Ausführungsform erkennen die Serverknoten alle anderen Mitglieder der Site 108, da sie Zugang zu Mitgliedsinformationen der Site haben, die alle Serverknoten von Site 108 auflisten. Die Mitgliedsinformationen der Site werden ständig und lokal auf jedem der Serverknoten gespeichert, sodass jeder der Serverknoten seiner Site 108 automatisch wieder beitreten kann, falls er neu gestartet wird, während das System 100 in Betrieb ist.
Die verschiedenen Sites 108 können wie unten beschrieben Daten miteinander teilen. Bei der abgebildeten Ausführungsform sind die Server 104 handelsübliche Server, und die Kameras 106, 114 wurden von der Avigilon^TM Corporation aus Vancouver, Kanada, hergestellt; in alternativen Ausführungsformen können jedoch auch andere geeignete Arten von Servern 108 und Kameras 106, 114 verwendet werden.
Jeder der Knoten kann Dienste ausführen, die es jedem der Knoten ermöglichen, miteinander gemäß einer Protokollsuite zu kommunizieren, um es jedem Knoten zu ermöglichen, Daten unabhängig davon, ob es sich bei diesen Daten um Ansichten, Video, Systemereignisse, Benutzerzustände, Benutzereinstellungen oder andere Daten handelt, durch verteiltes Rechnen, d. h. ohne Einsatz eines zentralen Servers, mit jedem anderen Knoten zu teilen. Jeder der Knoten kann Zugang zu Mitgliedschaftsinformationen der Site haben, die alle Knoten identifizieren, die Teil der gleichen Site 108 sind; durch den Zugang zu diesen Site-Mitgliedschaftsinformationen können Daten zwischen allen Knoten von Site 108 geteilt und synchronisiert werden.
Die Knoten/Server 104 sind mit Sensoren wie den Kameras 114 assoziiert. Eine Site 108 kann ein verteiltes physisches Sicherheitssystem sein, wie z. B. ein Überwachungssystem, das automatisch Daten wie Ansichten, Video, Systemereignisse, Benutzerzustände und Benutzereinstellungen zwischen zwei oder mehreren Knoten 140a–c im System teilen kann, ohne auf einen zentralen Server wie einen Gateway- oder Management-Server zurückgreifen zu müssen. Benutzer können sich über die Clients 102a–b mit den Knoten 104a–c verbinden, um Zugang zu Netzwerk-Videorecordern und Kameras zu erhalten. Jeder der Knoten 104a–c in der Site 108a kann Daten mit den anderen Serverknoten in der Site teilen. Um diese Daten zu teilen, kann jeder der Knoten 104a–c Dienste ausführen, die Daten auf der Grundlage einer Protokollsuite zwischen den Knoten auf verschiedene Arten austauschen, abhängig davon, ob es sich bei den Daten um Ansichten, Video, Systemereignisse, Benutzerzustände oder Benutzereinstellungen handelt.
Jeder Knoten 104a–c in der betreffenden Site ist in der Lage, als Host für ein Front-End zu dienen, das die Site gegenüber verbundenen Clients als eine einzige logische Einheit modelliert. Ein Client muss lediglich eine Verbindung mit einem einzigen Knoten in der Site haben, um alle Funktionen der Site nutzen zu können, da Knoten-Knoten-Service und Daten-Routing unterstützt werden.
Bei Sites kann vorausgesetzt werden, dass sie einen Satz von Geräten, die sich gemeinsam an einem einzigen physischen Standort befinden, logisch modellieren. Beispielsweise ein Ladengeschäft, einen Flughafen, ein Casino oder einen Firmenhauptsitz.
2 zeigt ein Blockdiagramm der Protokollsuite 200, die von den Knoten des Systems 100 verwendet wird. Die Protokollsuite 200 ist in drei Schichten aufgeteilt und umfasst die folgenden Protokolle, wie in Tabelle 1 zusammengefasst: TABELLE 1
Es folgt eine Beschreibung der Funktion und des Einsatzes jedes der Protokolle der Protokollsuite 200.
Transportschicht
Die Transportschicht entspricht Schicht 4 des OSI-Modells für die Kommunikation offener Systeme und ist für die Bereitstellung eines zuverlässigen Datenübertragungsdienstes zwischen den Knoten und dem Site Support, der Datensynchronisation und den Anwendungsschichten zuständig. Die Transportschicht im System 100 umfasst die UDP 202 und TCP/HTTP 204 Protokolle.
Site-Support-Schicht
Die Site-Support-Schicht (auch als „Cluster-Unterstützungsschicht“ bekannt) umfasst die Protokolle, die zur Erkennung der Knoten, zur Verifizierung des Vorhandenseins der Knoten, zur Prüfung der Aktivität der Knoten, zur Feststellung, ob ein Knoten ein Mitglied einer der Sites 108 ist, und zur Festlegung des Routings von Daten zwischen den Knoten verwendet werden.
1. Discovery-Protokoll 206
Das Discovery-Protokoll 206 basiert auf Version 1.1 des von der Organization for the Advancement of Structured Information Standards (OASIS) veröffentlichten WS-Discovery-Protokolls, das in seiner Gesamtheit durch Verweis hiermit einbezogen wird. In der abgebildeten Ausführungsform wird die in dem veröffentlichten Standard verwendete XML-Formatierung durch Google^TM Protobuf-Verschlüsselung ersetzt.
Das Discovery-Protokoll 206 ermöglicht es jedem Knoten im System 100, die anderen Knoten im System 100 durch Multicasting von Sondierungsnachrichten an diese anderen Knoten und Abwarten der Reaktion zu identifizieren. Ein Knoten kann als Alternative eine Hallo-Nachricht aussenden, wenn er dem System 100 beitritt, um die anderen Knoten über seine Anwesenheit zu informieren, sodass diese anderen Knoten nicht zuerst ein Multicasting der Sondierungsnachricht durchführen müssen. Sowohl die Sondierungs- als auch die Hallo-Nachrichten können das von OASIS veröffentlichte WS-Discovery-Protokoll als Modell verwenden.
2. Gossip-Protokoll 208
Bei dem Gossip-Protokoll 208 handelt es sich um ein epidemisches Protokoll, das Daten von einem Knoten aus an alle Knoten einer Site 108 verbreitet, indem es einen zufälligen Datenaustausch zwischen den Knotenpaaren der Site 108 durchführt. Das Gossip-Protokoll 208 kommuniziert Aktivität durch den Austausch von Heartbeat-Daten in Form einer Heartbeat-Zählung für jeden Knoten, die es den Knoten ermöglicht, festzustellen, ob einer der Knoten in Site 108 unerwartet verschwunden ist (z. B. aufgrund eines Server-Ausfalls). Das Gossip-Protokoll 208 kommuniziert auch Daten über den Anwendungszustand, wie z. B. Hashes der obersten Ebene, die vom Übereinstimmungsprotokoll 216 verwendet werden, sowie Status-Einheitsidentifikatoren und deren Versionsnummern, die vom Statusprotokoll 218 verwendet werden, um festzulegen, wann Daten zwischen den Knoten synchronisiert werden. Dies wird nachfolgend genauer erläutert. Die unter Verwendung des Gossip-Protokolls 208 verbreiteten Daten werden schließlich durch regelmäßigen Knoten-zu-Knoten-Austausch auf alle Knoten in Site 108 verteilt.
Ein Datenaustausch zwischen zwei beliebigen Knoten der Site 108 unter Verwendung des Gossip-Protokolls 208 umfasst, wie nachfolgend beschrieben, die Durchführung zweier Remote Procedure Calls (RPCs) von einem ersten Knoten („Knoten A“) an einen zweiten Knoten („Knoten B“) in der gleichen Site 108. Das folgende Verfahren kann auf Knoten- oder Site-Ebene angewendet werden, wobei ein Knoten ein einzelnes Gerät oder eine Netzwerkeinheit darstellen und eine Site mehrere Knoten darstellen oder umfassen kann, beispielsweise an einem spezifischen physischen Standort oder in einer logischen Gruppe, die möglicherweise nicht einem einzelnen physischen Standort entspricht. In manchen Fällen kann ein Knoten auf eine Site verweisen und umgekehrt. In einem Beispiel umfasst der Datenaustausch Folgendes:

1. Knoten A schickt eine GreetingReq-Nachricht, die eine Liste von Zusammenfassungen für alle Knoten in der Site 108 umfasst, die von Knoten A erkannt werden, an Knoten B. Für jeden Knoten enthält eine Zusammenfassung einen individuellen Knoten-Identifier und Versionsinformationen, die jedes Mal hochgezählt werden, wenn sich der Heartbeat-Zustand oder der Anwendungszustand dieses Knotens ändert (z. B. über einen Heartbeat-RPC, der von einer Child Site zu einer Parent Site gesendet wird, und der der Parent Site anzeigt, dass die Child Site noch online ist). Bei der Versionsinformation kann es sich beispielsweise um eine eindimensionale Versionsnummer oder einen mehrdimensionalen Versionsvektor handeln. Die Verwendung eines Versionsvektors ermöglicht es der Zusammenfassung, den Verlauf der Zustandsänderungen des Knotens zusammenzufassen.
2. Knoten B schickt eine GreetingRsp-Nachricht an Knoten A, die Folgendes enthält: a. eine Liste von Zusammenfassungen für Knoten, über die Knoten B weitere Informationen von Knoten A erhalten möchte, was Knoten B anhand der an ihn in der GreetingReq-Nachricht übermittelten Versionsinformationen festlegt; b. eine Liste von Zusammenfassungen für Knoten, die Knoten A nicht kennt, und die einen Teil von Site 108 bilden; c. eine Liste einer oder beider Heartbeat- und Anwendungszustände, die Knoten A in Bezug auf Knoten, für die er veraltete Informationen hat, auf den neuesten Stand bringt; und d. eine Liste von Knoten, die nach Ansicht von Knoten A Teil der Site 108 sind, von denen Knoten B jedoch weiß, dass sie von Site 108 entfernt wurden.
3. Knoten A schickt dann eine ClosureReq-Nachricht an Knoten B, in der Knoten A Folgendes schickt: a. (a) eine Liste von Zusammenfassungen für die Knoten, über die Knoten A von Knoten B weitere Informationen wünscht (Knoten A kann z. B. Informationen für Knoten anfordern, die Knoten A nicht bekannt waren, bis Knoten B die GreetingRsp-Nachricht an Knoten A geschickt hat); b. (b) eine Liste der Zustände, die Knoten B in Bezug auf Knoten, für die er veraltete Informationen hat, auf den neuesten Stand bringt; und
4. (c) eine Liste von Knoten, die nach Ansicht von Knoten B Teil der Site 108 sind, von denen Knoten A jedoch weiß, dass sie von Site 108 entfernt wurden.
5. Knoten B schickt dann eine ClosureRsp-Nachricht an Knoten A, in der Knoten B Folgendes schickt: a. eine Liste von Zuständen, die Knoten A als Antwort auf die Anfrage von Knoten A in ClosureReq in Bezug auf Knoten, für die er veraltete Informationen hat, auf den neusten Stand bringt; und b. eine Liste von Knoten, die seit der GreetingRsp von Site 108 entfernt wurden.

Nachdem Knoten A und B RPCs ausgetauscht haben, verfügen sie über identische Listen über aktive Knoten, die die neuesten Versionen des Heartbeat-Zustands und des Anwendungszustands für alle Knoten in der Site 108 umfassen, von denen beide vor den RPCs wussten, und die nicht von Site 108 entfernt wurden.
3. Knotenprotokoll 210
Das Knotenprotokoll 210 ist für die Erstellung einer Ansicht der Netzwerktopologie von System 100 für jeden Knoten verantwortlich, die jedem Knoten eine Netzwerkkarte zur Verfügung stellt, die es ihm ermöglicht, mit jedem anderen Knoten im System 100 zu kommunizieren. In einigen Ausführungsformen ist die Netzwerkkarte eine Leitwegtabelle. Die Netzwerkkarte zeigt Kommunikationsendpunkte auf, bei denen es sich um eine Adresse (IP/FQDN), eine Portnummer und ein Protokoll handelt, durch das ein Knoten über das IP-Netzwerk erreicht werden kann, das die Knoten verbindet.
Das Knotenprotokoll 210 macht dies auf drei Arten:

1. über einen „Poke Exchange“, der nachfolgend im Detail beschrieben ist;
2. über das Discovery-Protokoll 206, das das Knotenprotokoll 210 benachrichtigt, wenn ein Knoten dem System 100 beitritt oder es verlässt. Wenn ein Knoten dem System 100 beitritt, wird mit diesem Knoten ein „Poke Exchange“ durchgeführt; und
3. manuell, als Reaktion auf eine Benutzereingabe.

Ein Poke Exchange beinhaltet die regelmäßige Durchführung der folgenden RPCs zum Zweck der Erstellung von Netzwerkkarten für die Knoten:

1. eine Poke-Anfrage, bei der Knoten A eine Knoten A Selbstansicht an Knoten B schickt, und eine Liste der anderen Knoten A bekannten Knoten, woraufhin Knoten B seine Netzwerkkarte anhand dieser Informationen aktualisiert; und
2. eine Poke-Antwort bei der Knoten B eine Knoten B Selbstansicht an Knoten A schickt, und eine Liste der anderen Knoten B bekannten Knoten, woraufhin Knoten A seine Netzwerkkarte anhand dieser Informationen aktualisiert.

Bei manchen Aspekten werden RPCs über das TCP/HTTP-Protokoll 204 durchgeführt. Um den Einsatz von Bandbreite zu reduzieren, dürfen die Knoteninformationen nur zwischen den Knoten A und B ausgetauscht werden, wenn sich die Knoteninformationen seit dem letzten Austausch geändert haben.
Ein Poke Exchange wird durchgeführt, nachdem das Discovery-Protokoll 206 das Knotenprotokoll 210 darüber informiert hat, dass ein Knoten dem System 100 beigetreten ist, da das Discovery-Protokoll 206 die Kommunikationsendpunkte eines Knotens angibt, jedoch nicht garantiert, dass der Knoten mithilfe dieser Kommunikationsendpunkte erreicht werden kann. So ist es beispielsweise möglich, dass die Endpunkte wegen einer Firewall nicht verwendet werden können. Die Durchführung eines Poke Exchange an einem Knoten, der mithilfe des Discovery-Protokolls 206 identifiziert wurde, bestätigt, ob die Kommunikationsendpunkte tatsächlich benutzt werden können.
Das Knotenprotokoll 210 kann außerdem bestätigen, ob ein angegebener UDP-Kommunikationsendpunkt erreichbar ist; das Knotenprotokoll 210 in der abgebildeten Ausführungsform führt jedoch keinen Poke Exchange über das UDP-Protokoll 202 durch.
Für jeden beliebigen Knoten in einer Site 108 gibt die Netzwerkkarte Knotenidentifikatoren an Kommunikationsendpunkten für jeden der Knoten in der gleichen Site 108 an. Entsprechend können die anderen Protokolle im Protokollstack 200, die mit dem Knotenprotokoll 210 kommunizieren, Nachrichten an jeden anderen Knoten in Site 108 senden, indem sie einfach den Knotenidentifikator dieses Knotens verwenden.
4. Mitgliedschaftsprotokoll 212
Das Mitgliedschaftsprotokoll 212 ist dafür verantwortlich, zu gewährleisten, dass jeder Knoten von Site 108 Site-Mitgliedschaftsinformationen für alle Knoten von Site 108 enthält, und es den Knoten zu ermöglichen, mittels RPCs der Site 108 beizutreten und sie zu verlassen. Site-Mitgliedschaftsinformationen werden zwischen Knoten der Site 108 mithilfe des Statusprotokolls 218 geteilt. Jeder Knoten in der Site 108 enthält seine eigene Version der Site-Mitgliedschaftsinformationen und lernt über das Statusprotokoll 218 die Site-Mitgliedschaftsinformationen, die sich im Besitz der anderen Knoten in Site 108 befinden. Wie nachstehend eingehend erläutert, ist es möglich, dass die Versionen der Site-Mitgliedschaftsinformationen zweier verschiedener Knoten nicht übereinstimmen, da die Version der Site-Mitgliedschaftsinformationen, die auf einem kürzlich aktualisierten Knoten gespeichert sind, möglicherweise noch nicht mit anderen Mitgliedern der Site 108 synchronisiert wurden.
Die Site-Mitgliedschaftsinformationen umfassen für jeden Knoten Folgendes:

1. Eine Mitgliedschaftsliste aller Knoten von Site 108, in der jeder Knoten wie folgt vertreten ist: (a) durch den Knotenidentifikator, der unter allen Knoten im System 100 einzigartig ist; (b) durch den Status des Knotens, der einer der folgenden ist: i. Erkannt: der Knoten ist ein Mitglied von Site 108, wurde aber seit seinem Neustart nicht mit anderen Mitgliedern der Site 108 synchronisiert; ii. Tritt bei: der Knoten ist im Begriff, der Site 108 beizutreten; iii. Synchronisiert: der Knoten ist dabei, mithilfe der Synchronie-, Übereinstimmungs- und Statusprotokolle 214, 216 und 218 Daten mit der Site 108, der er gerade beigetreten ist, zu synchronisieren; iv. Gültig: der Knoten hat die Synchronisierung der Site-Mitgliedschaftsinformationen beendet und ist ein gültiger Knoten von Site 108; und v. Abgelaufen: der Knoten reagiert nicht mehr und ist kein aktives Mitglied von Site 108 mehr (der Knoten bleibt ein Mitglied der Site 108, bis er von einem Benutzer entfernt wird); (c) durch einen Session-Token; (d) durch die Versionsnummer der Site-Mitgliedschaftsinformationen, als der Knoten Site 108 beigetreten ist; und i. e) durch die Versionsnummer der Site-Mitgliedschaftsinformationen bei der letzten erfolgten Änderung.
2. Eine Gravestone-Liste aller Knoten, die von Site 108 entfernt wurden, in der jeder entfernte Knoten wie folgt vertreten ist: (a) durch den Knotenidentifikator dieses Knotens; und (b) durch die Versionsnummer der Site-Mitgliedschaftsinformationen zum Zeitpunkt der Entfernung des Knotens.

In der abgebildeten Ausführungsform ist ein Knoten stets ein Mitglied von Site 108, die mindestens ihn selbst umfasst; eine Site 108 mit einem Knoten wird als „Singleton-Site“ bezeichnet. Außerdem können die Mitgliedschaftsinformationen, während sie in der abgebildeten Ausführungsform die Mitgliedschaftsliste und die Gravestone-Liste wie oben beschrieben enthalten, in alternativen Ausführungsformen (nicht abgebildet) auf andere Weise zusammengesetzt sein; so fehlt beispielsweise in einer solchen alternativen Ausführungsform in den Mitgliedschaftsinformationen eine Gravestone-Liste, während in einer anderen solchen Ausführungsform der Status des Knotens anders als oben beschrieben werden kann.
Wenn Knoten A als neuer Serverknoten auftreten und Site 108, die Knoten B umfasst, beitreten möchte, kommuniziert er mit Knoten B, und Folgendes findet statt:

1. Knoten A schickt ein Site Secret an Knoten B, bei dem es sich in der abgebildeten Ausführungsform um einen Schlüssel handelt, den Knoten B benötigt, bevor er zulässt, dass ein anderer Knoten seiner Site 108 beitritt. Einer der Clients 102 stellt das Site Secret für Knoten A bereit. Da Knoten B den Zugang von Knoten A zu Site 108 kontrolliert, agiert Knoten B als ein „Mitgliedschaftskontrollknoten“.
2. Die Knoten A und B tauschen ihre Mitgliedschaftsinformationen aus. Die Versionen der Mitgliedschaftsinformationen auf Knoten A und B werden aktualisiert, um die Knotenidentifikatoren von Knoten A und aller Knoten von Site 108 zu aktualisieren, der Knoten A beitritt.
3. Der Status von Knoten A wird in „Tritt bei“ geändert, wenn Knoten A der Site beitritt.
4. Nach dem Beitritt wird der Status von Knoten A in „Synchronisiert“ geändert, während Daten zwischen Knoten A und der Site 108, der er gerade beigetreten ist, ausgetauscht werden. Knoten B aktualisiert unter Verwendung des Statusprotokolls 218 ebenfalls die Version der Mitgliedschaftsinformationen, die auf allen anderen Knoten der Site 108 gespeichert sind. Der Prozess der Aktualisierung der über Knoten A und alle Mitglieder von Site 108, der Knoten A beitritt, gespeicherten Versionen der Mitgliedschaftsinformationen wird als „Synchronisieren“ der Versionen der auf all diesen Knoten gespeicherten Mitgliedschaftsinformationen bezeichnet.
5. Wenn die Synchronisation abgeschlossen ist, wechselt der Status von Knoten A auf „Gültig“.

Datensynchronisationsschicht
Die Datensynchronisationsschicht umfasst die Protokolle, die es ermöglichen, Daten zwischen den Knoten in einer Site mit verschiedenen Bestellgarantien und Leistungskompromissen zu senden. Die Protokolle in der Datensynchronisationsschicht verwenden direkt Protokolle in den Transport- und Site-Support-Schichten.
1. Synchronieprotokoll 214
Das Synchronieprotokoll 214 wird verwendet, um Daten in Form von Nachrichten von Knoten A an Knoten B im System 100 zu schicken, sodass die Nachrichten bei Knoten B in einer Reihenfolge ankommen, die Knoten A kontrollieren kann, wie beispielsweise die Reihenfolge, in der Knoten A die Nachrichten sendet. Dienste, die Daten unter Verwendung des Synchronieprotokolls 214 übertragen, werden über zugehörige I/O-Service-Threads mit hoher Priorität betrieben.
In der abgebildeten Ausführungsform basiert das Synchronieprotokoll 214 auf einer Anwendung virtueller Synchronie, die als Totem-Protokoll bekannt ist, siehe die Beschreibung in Agarwal D A, Moser L E, Melliar-Smith P M, Budhia R K, „The Totem Multiple-Ring Ordering and Topology Maintenance Protocol“, ACM Transactions on Computer Systems, 1998, S. 93–132, das in seiner Gesamtheit hiermit als Referenz integriert wird. Im Synchronieprotokoll 214 werden Knoten in Gruppen gruppiert, die nachfolgend in dieser Beschreibung als „Synchronitätsringe“ bezeichnet werden, und ein Knoten eines beliebigen Synchronitätsrings kann vollständig geordnete Nachrichten an die anderen Knoten des gleichen Rings senden. Das Synchronieprotokoll 214 modifiziert das Totem-Protokoll wie folgt:

1. Das Synchronieprotokoll 214 verwendet sowohl einen Dienstidentifikator als auch einen Ringidentifikator, um einen Synchronitätsring zu identifizieren. Der Dienstidentifikator identifiziert sämtliche Fälle eines gegebenen Synchronitätsrings, wohingegen der Ringidentifikator einen bestimmten Fall eines gegebenen Synchronitätsrings identifiziert. So ändert sich beispielsweise jedes Mal, wenn ein Knoten einem Synchronitätsring beitritt oder ihn verlässt, der Ringidentifikator dieses Rings, aber nicht sein Dienstidentifikator. Der Dienstidentifikator ermöglicht es einem Knoten, vollständig geordnete Nachrichten als Multicast an die Gruppe von Knoten zu senden, die den gleichen Dienstidentifikator haben (z. B. die Gruppe von Knoten, die zum gleichen Synchronitätsring gehören).
2. In dem Totem-Protokoll stellt der von den Knoten gesehene Synchronitätsring in manchen Fällen, wenn die Knoten keine Nachrichten schicken, nicht die endgültige Ringkonfiguration dar, die sich zusammenschließt, wenn die Knoten mit dem Versenden von Nachrichten beginnen. Das Synchronieprotokoll 214 ermöglicht es Knoten, Sondierungsnachrichten aneinander zu schicken und so die Synchronitätsringe zu veranlassen, sich vor dem Senden der Nicht-Sondierungsnachrichten zusammenzuschließen.
3. Das Totem-Protokoll lässt das Versenden von geordneten Nachrichten nur an Knoten zu, die Teil eines Synchronitätsrings sind. Im Gegensatz dazu verwendet das Synchronieprotokoll 214 ein Versandmodul, das die Netzwerkschicht vom Synchronieprotokoll 214 abstrahiert, indem es eine Schnittstelle zur Übertragung an alle erreichbaren Knoten im System 100 zur Verfügung stellt; Multicast an jede Gruppe von Knoten im System 100 mithilfe einer Liste von Zielknotenidentifikatoren; und Unicast an einen einzelnen Knoten im System 100 mithilfe seines Knotenidentifikators. Das Versandmodul unterstützt ebenfalls das Multiplexing von Diensten am gleichen IP-Port mithilfe von Nachrichtenfilterung und Routing nach Dienstidentifikator. Von einem Knoten ausgehende Nachrichten werden zu einer Untergruppe von Knoten geschickt, die den gleichen Dienstidentifikator haben, außer bei Multicast.
4. Das Synchronieprotokoll 214 verwendet fragmentierte Nachrichten und Benutzer-Payload-Chunking und -Coalescing, um die Probleme zu bewältigen, die sich aus der maximalen Übertragungseinheitsgröße von 1500 Byte ergeben.
5. Das Synchronieprotokoll 214 modifiziert die Art, in der Knoten Beitrittsnachrichten verwenden, bei denen es sich um Nachrichten handelt, die Knoten im Totem-Protokoll verwenden, um einem Synchronitätsring beizutreten: a. Beitrittsnachrichten werden von Knoten nur dann gesendet, wenn sie den niedrigsten Knotenidentifikator in der aktuellen Gruppe von im Betrieb befindlichen Knoten im Synchronitätsring haben. b. Knoten, die nicht den niedrigsten Knotenidentifikator in ihrer Betriebsgruppe haben, senden Nachrichten mit Unicast an die Knoten mit dem niedrigsten Knotenidentifikator in ihrer Betriebsgruppe. c. Beitrittsnachrichten enthalten den Dienstidentifikator, und Knoten, die nicht Teil des entsprechenden Synchronitätsrings sind, antworten nicht. In Relation zum Totem-Protokoll tragen diese Modifikationen dazu bei, die von den Knoten für den Beitritt zu Synchronitätsringen genutzte Gesamtbandbreite zu reduzieren.
6. Das Synchronieprotokoll 214 erkennt und sperrt Knoten, die aufgrund von bestimmten Netzwerkfehlkonfigurationen nicht in der Lage sind, einem Synchronitätsring beizutreten. So erscheint es beispielsweise den anderen Knoten, als ob ein Knoten, der nur in der Lage ist, Nachrichten an die anderen Knoten zu senden, jedoch keine von ihnen empfangen kann, lediglich Sondierungsnachrichten sendet, da alle anderen Nachrichten in der vorliegenden Ausführungsform angefordert sind, und er wird dementsprechend gesperrt werden.
7. Das Synchronieprotokoll 214 führt eine Payload-Verschlüsselung und eine Authentizitätsverifizierung von Nachrichten durch.
8. Das Synchronieprotokoll 214 begrenzt die Zeit, für die jeder Knoten den im Totem-Protokoll verwendeten Token halten kann; in der abgebildeten Ausführungsform kann jeder Knoten den Token 15 ms lang halten.
9. Das Synchronieprotokoll 214 implementiert einen TCP-freundlichen Überlastungsvermeidungsalgorithmus.

Wie nachfolgend im Detail erläutert, verwendet das System 100 das Synchronieprotokoll 214 für die Geteilte-Ansichten- und Zusammenarbeitsanwendung 222 und die Geteilte-Ansichten- und Alarme-Anwendung 224; die zwischen den Mitgliedern einer Site 108 in diesen Anwendungen 222 geteilten Daten sind nicht-persistent und werden vorteilhaft schnell in einer bekannten Reihenfolge geteilt.
2. Übereinstimmungsprotokoll 216
Das Übereinstimmungsprotokoll 216 wird verwendet, um automatisch und regelmäßig Daten über sämtliche Knoten von Site 108 hinweg zu teilen, sodass die Daten, die unter Verwendung des Übereinstimmungsprotokolls 216 geteilt werden, schließlich auf allen Knoten in der Site 108 synchronisiert sind. Die Arten von Daten, die unter Verwendung des Übereinstimmungsprotokolls 216 geteilt werden, werden nachfolgend in den Abschnitten über die Geteilte-Einstellungen-Anwendung 226 und die Geteilte-Benutzerobjekte-Anwendung 228 eingehender erläutert. Durch das Übereinstimmungsprotokoll 216 geteilte Daten werden in einer Datenbank auf jedem der Knoten gespeichert, und jeder Eintrag in die Datenbank umfasst ein Schlüsselwertpaar, in dem der Schlüssel den Wert eindeutig identifiziert und die Schlüssel voneinander unabhängig sind. Das Übereinstimmungsprotokoll 216 synchronisiert Daten über die Knoten hinweg, während es parallele Modifizierungen klärt, die verschiedene Knoten an verschiedenen Datenbanken vornehmen können. Wie nachfolgend genauer erläutert, erreicht das Übereinstimmungsprotokoll 216 dies, indem es erstens darüber informiert wird, dass die Datenbanken nicht synchronisiert sind; zweitens herausfindet, welche Datenbankeinträge nicht synchronisiert sind; und drittens herausfindet, welche Version des Eintrags die neueste, synchronisierteste und gepflegteste ist.
Um parallele Modifikationen zu klären, die festlegen, wann Änderungen an Datenbanken vorgenommen werden, wird jedem Knoten, der einer Site 108 beitritt, ein Kausalitätsversionierungsmechanismus zugeordnet, um aufzuzeichnen, wann dieser Knoten Änderungen an Daten vornimmt, und um festzustellen, ob Änderungen vor oder nach den Änderungen vorgenommen wurden, die von anderen Knoten in der Site 108 an den gleichen Daten vorgenommen wurden. In der vorliegenden Ausführungsform verwendet jeder der Knoten eine Interval Tree Clock (ITC) als Kausalitätsversionierungsmechanismus. In alternativen Ausführungsformen können jedoch andere Versionierungsmechanismen wie Vektor-Uhren und Versionsvektoren verwendet werden. Das System 100 verwendet auch eine UTC-Uhr (universal time clock), die zwischen verschiedenen Knoten mithilfe eins Netzwerkzeitprotokolls synchronisiert wird, um die Reihenfolge festzulegen, in der Änderungen vorgenommen werden, wenn die ITCs von zwei oder mehreren Knoten identisch sind. ITCs werden eingehender erläutert in: P. Almeida, C. Baquero, und V. Fonte, „Interval tree clocks: a logical clock for dynamic systems,“ Princi. Distri. Sys., Lecture Notes in Comp. Sci., Band 5401, S. 259–274, 2008, das in seiner Gesamtheit hiermit als Referenz integriert wird.
Das Verzeichnis, das das Übereinstimmungsprotokoll 216 zwischen den Knoten synchronisiert, ist in Bereiche aufgeteilt, von denen jeder als eine Endgültige Übereinstimmungsdomäne (EÜD) bezeichnet wird. Das Übereinstimmungsprotokoll 216 synchronisiert jede der EÜDs unabhängig von den anderen EÜDs. Jeder Datenbankeintrag innerhalb einer EÜD wird als Endgültiger Übereinstimmungseintrag (EÜE) bezeichnet. Jeder EÜE enthält einen Schlüssel; einen Zeitstempel von ITC und UTC, die beide aktualisiert werden, wenn der EÜE modifiziert wird; einen Hash-Wert des erstellenden EÜE, für den beispielsweise eine Murmurhash-Funktion verwendet wird; die Daten an sich; und einen Gravestone, der hinzugefügt wird, wenn der EÜE gelöscht wird.
Der Hash-Wert wird verwendet, um entsprechende EÜDs und EÜEs auf zwei verschiedenen Knoten zu vergleichen, um festzustellen, ob sie identisch sind. Wenn zwei entsprechende EÜDs verglichen werden, werden die Hashs der oberen Ebene dieser EÜDs verglichen. Ein Hash der oberen Ebene für eine EÜD auf einem bestimmten Knoten wird erzeugt, indem alle EÜEs innerhalb dieser EÜD gehasht werden. Falls die Hashs der oberen Ebene übereinstimmen, sind die EÜDs identisch; ansonsten stellt das Übereinstimmungsprotokoll 216 fest, dass die EÜDs voneinander abweichen. Um festzustellen, welche EÜEs in den EÜDs voneinander abweichen, werden Hashs von sukzessive abnehmenden Bereichen der EÜEs auf beiden Knoten genommen. Die Intervalle, über die die Hashs genommen werden, schrumpfen letztendlich genug, damit die EÜEs, die zwischen den Knoten voneinander abweichen, isoliert und identifiziert werden. Eine bidirektionale Skip-List kann beispielsweise verwendet werden, um die Hash-Werte von EÜD-Intervallen festzulegen und zu vergleichen.
Zwei Knoten, die unter Verwendung des Übereinstimmungsprotokolls 216 kommunizieren, können die folgenden RPCs verwenden:

1. SetEntries: SetEntries überträgt neue oder aktualisierte EÜEs an einen Knoten, der sie in die entsprechenden EÜDs einfügt.
2. GetEntries: GetEntries übermittelt einen Schlüssel oder eine Reihe von Schlüsseln an einen Knoten, der die EÜEs zurücksendet, die diesen einen oder mehreren Schlüsseln entsprechen.
3. SynEntries: SynEntries übermittelt einen Schlüssel oder eine Reihe von Schlüsseln an einen Knoten, und die beiden Knoten vergleichen dann wie oben beschrieben Hashs von sukzessive abnehmenden Bereichen der EÜEs, um festzulegen, welche EÜEs zwischen den beiden Knoten voneinander abweichen. Falls die EÜEs voneinander abweichen, verschmelzen die Knoten ihre EÜEs, sodass die gleichen EÜEs auf den Knoten gespeichert werden, indem die ITC-Zeitstempel verglichen werden; falls die ITC-Zeitstempel übereinstimmen, vergleichen die Knoten die mit den EÜEs assoziierten UTC-Zeitstempel. Diese Zeitstempel dienen als Versionsinformationen, die es den beiden Knoten ermöglichen, die EÜEs zu übernehmen, die wie durch die Versionsinformationen dieser EÜEs ersichtlich, zuletzt modifiziert wurden.

Wenn ein Knoten EÜEs ändert, ruft dieser Knoten in der Regel SynEntries auf, um die anderen Knoten in der Site 108 darüber zu informieren, dass die EÜEs geändert wurden. Falls einige der Knoten in der Site 108 nicht verfügbar sind (sie sind z. B. offline), wird das Gossip-Protokoll 208 anstelle von SynEntries verwendet, um Hashs der oberen Ebene an die nicht verfügbaren Knoten zu kommunizieren, sobald sie wieder online gehen. Wie bereits oben im Abschnitt über das Gossip-Protokoll 208 in Site 108 erwähnt, hält jeder Knoten seinen Hash der oberen Ebene, der unter Verwendung des Gossip-Protokolls 208 zusammen mit dem Knotenidentifikator, den Versionsinformationen und dem Heartbeat-Zustand an die anderen Knoten weitergegeben wird. Wenn ein anderer Knoten diesen Hash erhält, vergleicht er den erhaltenen Hash der oberen Ebene mit seinem eigenen Hash der oberen Ebene. Falls die Hashs der oberen Ebene identisch sind, stimmen die EÜEs beider Knoten überein; andernfalls weichen die EÜEs voneinander ab.
Falls die EÜEs voneinander abweichen, synchronisiert der Knoten, der SynEntries ausführt, oder der den Hash der oberen Ebene erhält, die EÜEs unabhängig davon, ob dies durch Verwendung von SynEntries oder des Gossip-Protokolls 208 festgestellt wird.
3. Statusprotokoll 218
Wie oben erläutert teilt das Gossip-Protokoll 208 über die Site 108 hinweg Einheitsidentifikatoren und deren Versionsnummern („Statuseinheitspaar“) für Knoten in der Site 108. Beispielhafte Statuseinheitsidentifikatoren können beispielsweise verschiedene Arten von Statusdaten in Form von Statuseinträgen repräsentieren, wie z. B. wie viel Speicher auf dem Knoten verfügbar ist; welche Geräte (wie z. B. die Nicht-Knoten-Kameras 114) an diesen Knoten angeschlossen sind; welche Clients 102 an diesen Knoten angeschlossen sind; sowie Site-Mitgliedschaftsinformationen. Wenn einer der Knoten diese Daten über das Gossip-Protokoll 208 empfängt, vergleicht er die Versionsnummer des Statuseinheitspaars mit der Versionsnummer des entsprechenden Statuseintrags, den er lokal gespeichert hat. Falls die Versionsnummern voneinander abweichen, beginnt das Statusprotokoll 218 mit einem RPC („Sync RPC“) mit dem Knoten, von dem das Statuseinheitspaar stammt, um den entsprechenden Statuseintrag zu aktualisieren.
Ein unter Verwendung des Statusprotokolls 218 synchronisierter Statuseintrag wird durch den Pfad und den Knotenidentifikator eindeutig identifiziert. Im Gegensatz zu den Daten, die unter Verwendung des Übereinstimmungsprotokolls 216 synchronisiert wurden, handelt es sich bei dem Knoten, den der Statuseintrag beschreibt, um den einzigen Knoten, dem es erlaubt ist, den Statuseintrag oder das Statuseintragspaar zu modifizieren. Entsprechend handelt es sich im Gegensatz zu den unter Verwendung von Übereinstimmungsprotokoll 216 synchronisierten EÜDs und EÜEs bei dem lokal auf Knoten A gespeicherten Statuseintrag für Knoten A stets um die neueste Version dieses Statuseintrags.
Falls Knoten A mehrere Statuseinträge gleichzeitig modifiziert, synchronisiert das Statusprotokoll 218 alle modifizierten Statuseinträge gemeinsam an Knoten B, wenn Knoten B den Sync RPC aufruft. Entsprechend können die gleichzeitig geänderten Einträge voneinander abhängig sein, da sie gemeinsam an Knoten B zur Analyse gesendet werden. Im Gegensatz dazu wird jeder der unter Verwendung des Übereinstimmungsprotokolls 216 synchronisierten EÜEs unabhängig von den anderen EÜEs synchronisiert, sodass EÜEs nicht voneinander abhängig sein können, da Knoten B sich nicht darauf verlassen kann, Einträge in einer bestimmten Reihenfolge zu erhalten.
Anwendungen
Jeder der Knoten im System 100 führt Dienste aus, die die oben beschriebene Protokollsuite 200 implementieren. Während in der abgebildeten Ausführungsform für jedes der Protokolle 202–218 ein Dienst verwendet wird, können in alternativen Ausführungsformen (nicht abgebildet) mehr oder weniger Dienste verwendet werden, um die Protokollsuite 200 zu implementieren. Jeder der Knoten implementiert die Protokollsuite 200 selbst; folglich wird das System 100 verteilt und ist weniger anfällig beim Ausfall eines einzelnen Knotens, was im Gegensatz zu herkömmlichen physischen Sicherheitssystemen steht, bei denen ein zentralisierter Server verwendet wird. Falls beispielsweise einer der Knoten (oder eine der Sites, wie z. B. eine Child Site oder eine Parent Site) im System 100 ausfällt („ausgefallener Knoten“), stellt der Dienst, der das Statusprotokoll 218 ausführt („Statusdienst“), fest, dass der ausgefallene Knoten offline ist, indem er den Heartbeat-Zustand des ausgefallenen Knotens überwacht, und wird diesen Ausfall an den Dienst melden, der das Knoten- und Mitgliedschaftsprotokoll 210, 212 auf jedem der anderen Knoten ausführt („Knotendienst“ bzw. „Mitgliedschaftsdienst“). Die Dienste auf jedem Knoten, die die Synchronie- und Übereinstimmungsprotokolle 214, 216 („Synchroniedienst“ bzw. „Übereinstimmungsdienst“) implementieren, stellen daraufhin den Datenaustausch mit dem ausgefallenen Knoten ein, bis der ausgefallene Knoten wieder online kommt und seiner Site 108 wieder beitritt.
Im Folgenden werden die verschiedenen Anwendungen 220–230 beschrieben, die das System 100 implementieren kann. Die Anwendungen 220–230 sind verschiedene Ausführungsformen der in 8 gezeigten beispielhaften Methode zum Teilen von Daten 800. Die Methode 800 beginnt bei Block 802 und geht weiter zu Block 804, wo ein erster Knoten des Systems 100 auf einen Knotenidentifikator zugreift, der einen anderen Knoten im System 100 identifiziert. Sowohl die ersten als auch die zweiten Knoten sind Mitglieder der gleichen Server-Site 108. Der Knotenidentifikator, auf den der erste Knoten zugreift, ist Teil der Site-Mitgliedschaftsinformationen, die alle Mitglieder der Site 108 identifizieren. Auf die Site-Mitgliedschaftsinformationen können alle Mitglieder der Site 108 zugreifen. Bei den abgebildeten Ausführungsformen speichert jedes Mitglied der Site 108 seine eigene Version der Site-Mitgliedschaftsinformationen dauerhaft und lokal; in alternativen Ausführungsformen (nicht abgebildet) können die Site-Mitgliedschaftsinformationen von den Knoten sowohl entfernt als auch an einem zentralen Ort gespeichert werden. Nach dem Zugriff auf den Knotenidentifikator für den zweiten Knoten sendet der erste Knoten die Daten an den zweiten Knoten bei Block 806, woraufhin die Methode 800 bei Block 808 endet. So sind beispielsweise die auf dem ersten Knoten ausgeführten Synchronie- und Übereinstimmungsdienste bei Verwendung des oben beschriebenen Knotendienstes in der Lage, die Daten an den zweiten Knoten zu senden, indem sie den Knotenidentifikator des zweiten Knotens verwenden, und indem sie dem Knotendienst die Verantwortung für die Assoziierung des Kommunikationsendpunkts des zweiten Knotens mit seinem Knotenidentifikator übertragen. Das Senden von Daten vom ersten Knoten an den zweiten Knoten bei Block 806 kann Bestandteil eines bidirektionalen Datenaustauschs sein, wie z. B. wenn Daten gemäß dem Gossip-Protokoll 208 ausgetauscht werden.
1. Geteilte-Einstellungen-Anwendung 226 und Geteilte-Benutzerobjekte-Anwendung 228
Während des Betriebs des Systems 100 werden ständig gespeicherte Informationen zwischen den Knoten einer Site 108 übertragen. Beispiele für diese Echtzeit-Informationen, die die Geteilte-Einstellungen- und die Geteilte-Benutzerobjekte-Anwendungen 226, 228 zwischen den Knoten teilen, umfassen geteilte Einstellungen, wie z. B. Regeln für die Implementierung als Reaktion auf Systemereignisse wie einen Alarmgeber, und Benutzerobjekte, wie z. B. Benutzernamen, Passwörter und Themen. Diese Art von Daten („Übereinstimmungsdaten“) werden zwischen Knoten geteilt, die das Übereinstimmungsprotokoll 216 verwenden; allgemein handelt es sich bei Übereinstimmungsdaten um Daten, die nicht in Echtzeit oder kompletter Ordnung geteilt werden müssen, und die von jedem der Knoten persistent gespeichert werden. In alternativen Ausführungsformen (nicht abgebildet) können Übereinstimmungsdaten jedoch möglicherweise nicht-persistent gespeichert werden.
3 zeigt ein UML-Sequenzdiagramm 300, in dem Übereinstimmungsdaten in Form von Benutzereinstellungen zwischen ersten und zweiten Benutzern 302a, b (gemeinsam als „Benutzer 302“ bezeichnet) geteilt werden. Die Benutzer 302 („User 1“ und „User 2“ in 3), die ersten und zweiten Clients 102a, b und die ersten und zweiten Server 104a, b, bei denen es sich in diesem Beispiel um die ersten und zweiten Knoten handelt, sind Objekte im Diagramm 300. Die Server 104a, b sind Bestandteil der gleichen Site 108a. Da die Server 104a, b, mit denen die Clients 102a, b kommunizieren, nicht direkt aneinander angeschlossen sind, wird das Übereinstimmungsprotokoll 216 verwendet, um Daten zwischen den beiden Servern 104a, b und so zwischen den beiden Benutzern 302 zu übertragen. Obwohl die abgebildete Ausführungsform geteilte Einstellungen beschreibt, können die Benutzer 302 in einer alternativen Ausführungsform (nicht abgebildet) möglicherweise Benutzerobjekte analog teilen.
Das Diagramm 300 hat zwei Rahmen 332 a, b. Im ersten Rahmen 332a, weist der Benutzer 302a den ersten Client 102a an, ein Einstellungsfenster (Nachricht 304) zu öffnen, und der Client 102a führt daraufhin die SettingsOpenView( )-Prozedur (Nachricht 306) durch, die die Einstellungen an den ersten Server 104a überträgt. Gleichzeitig weist der zweite Benutzer 302b den zweiten Client 102b analog an (Nachrichten 308 und 310). Im zweiten Rahmen 332 b bearbeiten die Benutzer 302 gleichzeitig ihre Einstellungen. Der erste Benutzer 302a bearbeitet seine Einstellungen, indem er den ersten Client 102a veranlasst, UIEditSetting( ) auszuführen (Nachricht 312), woraufhin der erste Client 102a die auf dem ersten Server 104a gespeicherten Einstellungen aktualisiert, indem er den ersten Server 104a veranlasst, SettingsUpdateView( ) auszuführen (Nachricht 314). Der erste Server 104a führt dann ConsistencySetEntries( ) aus (Nachricht 316), das die SetEntries-Prozedur durchführt und die vom ersten Benutzer 302a eingegebenen Einstellungen auf den zweiten Server 104b überträgt. Der zweite Server 104b sendet dann die übertragenen Einstellungen an den zweiten Client 102b, indem er SettingsNotifyViewUpdate( ) aufruft (Nachricht 318), woraufhin der zweite Client 102b den zweiten Benutzer 302b aktualisiert (Nachricht 320). Gleichzeitig modifiziert der zweite Benutzer 302b analog die Einstellungen und sendet diese Einstellungen unter Verwendung des Übereinstimmungsprotokolls 216 (Nachrichten 322, 324, 326, 328 und 330) an den ersten Server 104a. Jeder der Server 104a, b speichert die Benutzereinstellungen ständig, sodass sie nicht zwischen den Servern 104a, b erneut synchronisiert werden müssen, falls einer der Server 104a, b neu gestartet wird.
2. Geteilte-Ereignisse- und Alarme-Anwendung 224
Während des Betriebs des Systems 100 werden während der Laufzeit erstellte Echtzeitinformationen zwischen den Knoten einer Site 108 übertragen. Beispiele für diese Echtzeitinformationen, die die Geteilte-Ereignisse- und Alarme-Anwendung 224 zwischen Knoten teilt, sind Alarmzustand (d. h. ob ein Alarm im System 100 ausgelöst wurde); Systemereignisse wie erkannte Bewegung, ob ein Gerät (wie die Knotenkameras 106) digitale Daten an den Rest des Systems 100 schickt, ob ein Gerät (wie ein Bewegungsmelder) an das System 100 angeschlossen ist, ob ein Gerät aktuell aufzeichnet, oder ob ein Alarm stattgefunden hat oder von den Benutzern 302 bestätigt wurde, ob einer der Benutzer 302 eine Prüfung des Systems 100 durchführt, ob an einem der Server 104 ein Fehler aufgetreten ist, ob an einem am System angeschlossenen Gerät ein Fehler aufgetreten ist, ob eine Verkaufspunkt-Texttransaktion stattgefunden hat; und Serverknoten-an-Client-Mitteilungen, wie z. B. ob Einstellungen/Daten sich geändert haben, aktueller Aufzeichnungszustand, ob ein Zeitrahmen aktualisiert wird und Ergebnisse von Datenbankanfragen. In der vorliegenden Ausführungsform werden die unter Verwendung des Synchronieprotokolls 214 zwischen den Knoten übertragenen Daten als „Synchroniedaten“ bezeichnet, während der Laufzeit generiert und nicht ständig von den Knoten gespeichert.
4 zeigt ein UML-Sequenzdiagramm 400, in dem eine Alarmmitteilung unter Verwendung des Synchronieprotokolls 214 zwischen den Servern 104 geteilt wird. Bei den Objekten im Diagramm 400 handelt es sich um die Nicht-Knoten-Kameras 114, die drei Server 104 in der ersten Site 108a und den zweiten Client 102b, der an einen der Server 104c in der ersten Site 108a angeschlossen ist.
Auf den ersten drei Rahmen 402 des Diagramms 400 tritt jeder der Server 104 einem Synchronitätsring mit der Bezeichnung „ServerState“ bei, sodass der Zustand aller Server 104 an jeden der anderen Server 104 übermittelt werden kann; in der abgebildeten Ausführungsform ist der Zustand, der übermittelt werden wird, „AlarmStateTriggered“, was bedeutet, dass ein Alarm an einem der Server 108 durch ein von der Nicht-Knoten-Kamera 114 („Camera 1“ in 4) erkanntes Ereignis ausgelöst wurde. Auf Rahmen 404 wird der zweite Server 104b zum „Master“ der Alarme-Anwendung ausgewählt; dies bedeutet, dass es der zweite Server 104b ist, der entscheidet, ob der Input von der Nicht-Knoten-Kamera 114 die Kriterien für den Übergang in den AlarmStateTriggered-Zustand erfüllt, und der eine Nachricht an die anderen Server 104a, c im Synchronitätsring sendet, damit diese ebenfalls in den AlarmStateTriggered-Zustand übergehen.
Der Benutzer 302a meldet sich beim dritten Server 104c an, nachdem die Server 104 dem Synchronitätsring ServerState beigetreten sind (Nachricht 406). Nachdem sich der Benutzer 302a angemeldet hat, tritt der dritte Server 104c einem weiteren Synchronitätsring mit Namen „ClientNotification“ bei; wie nachfolgend genauer erörtert wird, dient dieser Ring dazu, dem Benutzer 302a Systemzustände zu übermitteln, während der Synchronitätsring ServerState nur der Übermittlung zwischen den Servern 104 dient. Die Nicht-Knoten-Kamera 114 sendet eine digitale Eingabe, wie z. B. eine Anzeige, dass eine Tür oder ein Fenster geöffnet wurde, an den ersten Server 104a (Nachricht 410); danach prüft der erste Server 104a, ob diese digitale Eingabe eine Reihe von Regeln erfüllt, um zu bestimmen, ob ein Alarm im System 100 (Nachricht 412) ausgelöst werden soll. In der abgebildeten Ausführungsform stellt der erste Server 104a fest, dass ein Alarm ausgelöst werden soll, und ruft dementsprechend AlarmTrigger( ) auf (Nachricht 414), was den zweiten Server 104b darauf aufmerksam macht, den Zustand zu wechseln. Der zweite Server 104 wechselt den Zustand dann zu AlarmStateTriggered (Nachricht 416) und schickt eine Nachricht an den Synchronitätsring ServerState, der die beiden anderen Server 104a, c anweist, den Zustand ebenfalls zu AlarmStateTriggered zu wechseln (Frame 418). Nach Anweisung der anderen Server 104a, c führt der zweite Server 104b AlarmTriggerNotification( ) aus (Nachricht 420), was den zweiten Server 104b veranlasst, ebenfalls dem Synchronitätsring ClientNotification beizutreten (Frame 422) und eine Nachricht an den Synchronitätsring ClientState zu übermitteln, was den dritten Server 104c, der der andere Server am Synchronitätsring ClientState ist, veranlasst, in einen Zustand „NotifyAlarmTriggered“ zu wechseln (Frame 424). Sobald der dritte Server 104c in diesen Zustand wechselt, informiert er direkt den zweiten Client 102b, dass der Alarm ausgelöst wurde, der diese Nachricht an den Benutzer 302a weitergibt und auf die Alarmbestätigung durch den Benutzer 302a wartet (Nachricht 426). Nach der Bestätigung des Alarms durch den Benutzer 302a wechselt der zweite Server 104b entsprechend in den Zustand „AlarmStateAcknowledged“ (Nachricht 428) und schickt dann eine Nachricht an den Synchronitätsring ServerState, sodass die beiden anderen Server 104a, c den Zustand ebenfalls entsprechend wechseln (Frame 430). Der zweite Server 104b wechselt anschließend erneut den Zustand zu „NotifyAlarmAcknowledged“ (Nachricht 432) und schickt eine Nachricht an den dritten Server 104c über den Synchronitätsring ClientNotification, um ihn zu veranlassen, entsprechend den Zustand zu wechseln (Frame 434). Der dritte Server 104c meldet dann dem Client 102b, dass das System 100 den Alarm bestätigt hat (Nachricht 436), wodurch diese Nachricht an den Benutzer 302a weitergegeben wird (Nachricht 438).
In einer alternativen Ausführungsform (nicht abgebildet), in der der zweite Server 104b ausfällt und nicht mehr als Master für den Synchronitätsring agieren kann, wählt das System 100 automatisch einen der anderen Server 104, der als Master für den Ring agieren soll. Der Master des Synchronitätsrings ist der einzige Server 104, der alle anderen Knoten des Rings veranlassen darf, den Zustand zu wechseln, wenn der Synchronitätsring dazu verwendet wird, die Alarmmeldungen unter den Knoten zu teilen.
7 zeigt eine beispielhafte Ansicht/Benutzerschnittstelle 700, die den Benutzern 302 angezeigt wird, wenn sie einen Alarmzustand entsprechend dem Diagramm 400 von 4 bestätigen. Die Ansicht 700 umfasst Video-Panels oder Bereiche 702a–c (kollektiv „Panels 702“), die ein Echtzeit-Streaming-Video von der Nicht-Knoten-Kamera 114 zeigen, Warnungen 704, die anzeigen, dass ein Alarm aufgrund der Aufzeichnungen der Nicht-Knoten-Kamera 114 ausgelöst worden ist, und eine Schaltfläche Bestätigen 706, die der Benutzer 302a anklickt, um den ausgelösten Alarm zu bestätigen.
3. Geteilte-Ansichten- und Zusammenarbeitsanwendung 222
Die Benutzer 302 des Systems 100 möchten möglicherweise auch ihre Ansichten 700 untereinander teilen und miteinander zusammenarbeiten, beispielsweise indem sie sich gegenseitig Nachrichten schicken und, während sie die Ansichten 700 teilen, über das System 100 miteinander sprechen. Durch diese Geteilte-Ansichten und Zusammenarbeitsanwendung 222 sind die Benutzer 302 entsprechend in der Lage, Daten, wie zum Beispiel den Ansichtenzustand, und Meldungen von Server zu Client, wie zum Beispiel Benutzernachrichten und Teilungsanfragen, zu teilen. Bei dieser Datenart handelt es sich um Synchronitätsdaten, die in Echtzeit geteilt werden.
5 zeigt ein UML-Sequenzdiagramm 500, in dem die Ansichten 700 zwischen den Benutzern 302 mit Hilfe des Synchronieprotokolls 214 geteilt werden. Das Diagramm 500 umfasst sechs Objekte: den ersten und den zweiten Benutzer 302a, b, den ersten und den zweiten Client 102a, b, mit denen der erste und der zweite Benutzer 302a, b jeweils verbunden sind, und den ersten und den zweiten Server 104a, b, mit denen der erste und der zweite Client 102a, b jeweils verbunden sind.
Der erste Benutzer 302a („User 1“ in 5) meldet sich am ersten Server 104a über den ersten Client 102a an (Nachricht 502), woraufhin der erste Server 104a dem Synchronitätsring ClientNotification beitritt (Frame 504). Ebenso meldet sich der zweite Benutzer 302b („User 2“ in 5) am zweiten Server 104b über den zweiten Client 102b an (Nachricht 506), woraufhin der zweite Server 104b dem Synchronitätsring ClientNotification ebenfalls beitritt (Frame 508).
Der erste Benutzer 302a unterrichtet dann den ersten Client 102a, dass er seine Ansicht 700 mit ihm teilen möchte. Der erste Benutzer 302a erreicht dies, indem er eine Schaltfläche Teilen anklickt (Nachricht 510), was den ersten Client 102a veranlasst, die zu teilende Ansicht 700 („geteilte Ansicht 700“) auf dem ersten Server 104a zu öffnen (Nachricht 512). Der erste Server 104a erstellt eine Geteilte-Ansichten-Sitzung (Nachricht 514) und schickt dann den Sitzungsbezeichner an den ersten Client 102a (Nachricht 516).
Bei einem ersten Frame 518 tritt jeder der Clients 102 einem Synchronitätsring bei, der es ihnen ermöglicht, die geteilte Ansicht 700 zu teilen. Der erste Server 104a tritt dem Synchronitätsring SharedView1 beim Frame 520 bei. Gleichzeitig weist der erste Client 102a den ersten Server 104a an, dem anderen Server 104b über das Synchronieprotokoll 214 zu melden, dass die Ansicht 700 des ersten Benutzers 302a durch Übermitteln einer Benutzerliste und des Sitzungsbezeichners an den ersten Server 104a geteilt werden kann (Nachricht 522). Der erste Server 104a erreicht dies, indem er eine Nachricht über den Synchronitätsring ClientNotify an den zweiten Server 104b schickt, die den zweiten Server 104 veranlasst, in den Zustand NotifyViewSession zu wechseln. Im Zustand NotifyViewSession veranlasst der zweite Server 104b den zweiten Client 102b, den zweiten Benutzer 302b aufzufordern, die Ansicht 700 des ersten Benutzers 302a zu teilen (Nachricht 526 und 528), wobei die positive Antwort des zweiten Benutzers 302b zurück zum zweiten Server 104b übermittelt wird (Nachricht 530 und 532). Der zweite Server 104b tritt anschließend dem Synchronitätsring SharedView1 bei (Nachricht 534), der zum Teilen der Ansicht 700 des ersten Benutzers 302a dient.
Bei einem zweiten Frame 519 aktualisieren die Benutzer 302 jeweils die geteilte Ansicht 700, wobei die Aktualisierungen automatisch untereinander geteilt werden. Der erste Benutzer 302a zoomt in ein erstes Panel 702a in der geteilten Ansicht 700 hinein (Nachricht 536) und der erste Client 102a informiert den ersten Server 104a über das Hineinzoomen des ersten Benutzers 302a in das erste Panel 702a (Nachricht 538). Der erste Server 104a teilt die Angaben über den Zoomvorgang mit dem zweiten Server 104b, indem er sie entlang dem Synchronitätsring SharedView1 weitergibt (Frame 540). Der zweite Server 104b aktualisiert entsprechend die geteilte Ansicht 700 gemäß der Anzeige auf dem zweiten Client 102b (Nachricht 542) und die aktualisierte geteilte Ansicht 700 wird dann dem zweiten Benutzer 302b angezeigt (Nachricht 544). Gleichzeitig schwenkt der zweite Benutzer 302b ein zweites Panel 702b in der geteilten Ansicht 700 (Nachricht 546) und der zweite Client 102b informiert den zweiten Server 104b über das Schwenken dieses Panels 702b durch den zweiten Benutzer 302b (Nachricht 548). Der zweite Server 104b teilt dann die Angaben über den Schwenkvorgang mit dem ersten Server 104a, indem er sie über den Synchronitätsring SharedView1 weitergibt (Frame 550). Der erste Server 104a aktualisiert entsprechend die geteilte Ansicht 700 gemäß der Anzeige auf dem ersten Client 102b (Nachricht 552) und die aktualisierte geteilte Ansicht 700 wird dann dem ersten Benutzer 302a angezeigt (Nachricht 554).
Nach dem zweiten Frame 519 schließt der erste Benutzer 302a seine Ansicht 700 (Nachricht 556), was dem ersten Server 104a mitgeteilt wird (Nachricht 558). Der erste Server 104a verlässt daraufhin den Synchronitätsring SharedView1 (Nachricht und Frame 560). Der zweite Benutzer 302b schließt ebenso seine Ansicht 700, was den zweiten Server 104b veranlasst, den Synchronitätsring SharedView1 zu verlassen (Nachricht 562 und 564 sowie Nachricht und Frame 566).
Im Beispiel von 5 schwenken die Benutzer 302 die geteilte Ansicht 700 und zoomen in sie hinein. In alternativen Ausführungsformen (nicht abgebildet) können die Benutzer 302 die geteilten Ansichten 700 auf andere Weise modifizieren. Beispielsweise können die Benutzer 302 jeweils den Aufbau der Panels 702 ändern, auswählen, ob das Video live oder im Playback-Modus angezeigt werden soll, wobei die Benutzer 302 in diesem Fall das Video anhalten, abspielen oder durchsuchen können, und Benutzerobjekte, wie Abbildungen oder Webseiten, zusammen mit Informationen über das Benutzerobjekt, wie ein Änderungsprotokoll, anzeigen. In diesen alternativen Ausführungsformen umfassen Beispiele zusätzlicher Zustandsinformationen, die über einen Synchronitätsring synchron geschaltet werden, Angaben darüber, ob ein Video abgespielt, angehalten oder durchsucht wird, sowie das Änderungsprotokoll des Benutzerobjekts.
4. Site-Streams-Anwendung 220
Möglicherweise möchte auch einer der Benutzer 302 ein Video von einer der Kameras 106, 114 streamen, wenn zwischen dem Benutzer 302 und der Kamera 106, 114 keine Festverbindung vorhanden ist; diese Funktionalität wird durch die Site-Streams-Anwendung 220 ermöglicht. 6 zeigt ein UML-Sequenz-Diagramm 600, in dem ein Video von der Nicht-Knoten-Kamera 114 über den ersten und den zweiten Server 104a, b und den ersten Client 102a zum ersten Benutzer 302a („User 1“ in 6) gestreamt wird. Das UML-Diagramm weist fünf Objekte auf: den ersten Benutzer 302a, den ersten Client 102a, den ersten und den zweiten Server 104a, b und die Nicht-Knoten-Kamera 114 („Camera 2.1“ in 6). Der erste Client 102a kann direkt mit dem ersten Server 104a, jedoch nicht direkt mit dem zweiten Server 104b kommunizieren (siehe 6: „Client 1 can’t communicate with Server 2“). Dagegen können der erste und der zweite Server 104a, b direkt miteinander kommunizieren. Außerdem können zwar der zweite Server 104b und die Nicht-Knoten-Kamera 114 direkt miteinander kommunizieren, der erste Server 104a und die Nicht-Knoten-Kamera 114 können aber nicht direkt kommunizieren.
Der zweite Server 104b baut zunächst eine Sitzung mit der Nicht-Knoten-Kamera 114 auf, sodass ein Video von der Nicht-Knoten-Kamera 114 zum zweiten Server 104b gestreamt wird. Der zweite Server 104b richtet zunächst eine RTSP-Sitzung (Real Time Streaming Protocol) mit der Nicht-Knoten-Kamera 114 ein (Nachricht 602 und 604) und weist die Nicht-Knoten-Kamera 114 an, ihm ein Video zu schicken (Nachricht 606 und 608). Die Nicht-Knoten-Kamera 114 beginnt anschließend mit dem Streamen (Nachricht 610).
Der erste Benutzer 302a stellt eine Verbindung mit dem ersten Client 102a her (Nachricht 612) und weist dann den ersten Client 102a an, ein Fenster zu öffnen, welches das streamende Video anzeigt (Nachricht 614). Der erste Client 102a ruft dann LookupRoute() auf (Nachricht 616), um zu ermitteln, mit welchem Server 104 er sich verbinden muss; da sich der erste Client 102a nicht direkt mit dem zweiten Server 104b verbinden kann, richtet er eine RTSP-Verbindung mit dem ersten Server 104a ein (Nachricht 618). Der erste Server 104b ruft dann LookupRoute() auf, um zu ermitteln, mit welchem Knoten er sich verbinden muss, um auf das Echtzeit-Video zuzugreifen, und stellt fest, dass er sich mit dem zweiten Server 104b verbinden soll (Nachricht 620). Der erste Server 104a richtet anschließend eine RTSP-Verbindung mit dem zweiten Server 104b ein (Nachricht 622) und der zweite Server 104b sendet einen Sitzungsbezeichner an den ersten Server 104a zurück (Nachricht 624). Der erste Server 104a übermittelt den Sitzungsbezeichner an den ersten Client 102a (Nachricht 626). Mit Hilfe des Sitzungsbezeichners weist der erste Client 102a den zweiten Server 104b an, mit dem Abspielen des RTSP-Videos zu beginnen (Nachricht 628 bis 634), und der zweite Server 104b streamt anschließend das Video über den zweiten Server 104b, dann den ersten Server 104a und dann den ersten Client 102a zu dem ersten Benutzer 302a (Nachricht 636 bis 640).
Während in 6 das Video von einer der mit einem der Server 104 in einer Site 108 verbundenen Nicht-Knoten-Kameras 114 zu anderen Servern 104 in der gleichen Site 108 geleitet wird, kann in alternativen Ausführungsformen (nicht abgebildet) das Video auch von einer der Knoten-Kameras 106 in einer Site 108 über die anderen Knoten-Kameras 106 in der gleichen Site 108 geleitet werden.
Neustart
In der vorliegenden Ausführungsform werden die Informationen über die Site-Zugehörigkeit dauerhaft lokal auf jedem der Knoten gespeichert. Bei einem Neustart eines der Knoten tritt dieser Knoten automatisch erneut der Site 108 bei, zu der er vor dem Neustart gehört hat. Dies ist in dem in 9 gezeigten beispielhaften Verfahren 900 dargestellt. Nach Durchführung des Blocks 806 erfolgt ein Neustart einer der Knoten in der Site 108 (Block 902). Beim Neustart greift dieser Knoten auf die dauerhaft gespeicherten Informationen über die Site-Zugehörigkeit zu, die die Site 108 kennzeichnen, zu der er vor dem Neustart gehörte (Block 904), und tritt anschließend dieser Site 108 erneut bei (Block 906), bevor er wieder zu Block 808 zurückkehrt. Es ist von Vorteil, die Knoten nach einem Neustart einer Site 108 automatisch erneut beitreten zu lassen, da dies bei der Wiederherstellung des Systems 100 nach einem Neuanlauf eines oder mehrerer seiner Server hilfreich ist. Da jeder der Knoten die Konsistenzinformationen dauerhaft speichert, werden bei einem erneuten Beitreten zu der Site 108 nur die Konsistenzinformationen, die sich verändert haben, seit der Knoten zuletzt die Site 108 verlassen hat, erneut synchronisiert, wodurch Bandbreite gespart wird.
Auch wenn die 1 bis 9 einen beispielhaften Betrieb von Knoten und Sites beschreiben, ist die spezielle Umsetzung der in den 1 bis 9 beschriebenen Knoten und Sites nicht als einschränkend zu betrachten.
Knotenbeispiel
10 zeigt ein Diagramm, das einen beispielhaften Knoten 1002 veranschaulicht. Der Knoten 1002 kann als physische Hardware gelten, auf der eine physische Sicherheitssoftware läuft, die eine CPU 1004, einen Speicher 1006 und Netzwerkfähigkeiten 1008 enthält. Der Knoten 1002 kann außerdem Sensoren 1010 (wie z. B. CMOS-Bildgebungssensoren (Complementary Metal Oxide Semiconductor), CCD-Bildgebungssensoren (Charged Coupled Device), Thermofühler, weitere Kameras (wie z. B. die Kameras 114 von 1) und Mikrofone usw.) umfassen, wobei der Speicher 1012 sowie die Sonderverarbeitungseinheiten 1014 die Effizienz intensiver CPU-Aufgaben verbessern.
VMS-Anwendungsmodell (Video Management Software)
In einem VMS-Anwendungsmodell (Video Management Software) präsentieren die Front-Ends der Knoten (Schnittstelle zur Anwendungsprogrammierung API und die Dienste, die ein Server Client-Anwendungen zur Verfügung stellt) den VMS-Clients Sites als eine pauschale Liste von Video-Sensor-IDs ohne Hierarchie. Knoten und andere Sensortypen sind von der standardmäßigen Benutzeransicht ausgeschlossen und sind nur in den Einrichtungs- und Konfigurationsansichten sichtbar. Endbenutzer können die Videosensoren in logischen Hierarchien in der VMS organisieren, die von der physischen Struktur und Beziehung der Knoten unabhängig sind. Außerdem können virtuelle Sensoren beispielsweise auch durch Konfigurieren des Zusammenhangs zwischen Audio-Sensoren und Video-Sensoren erstellt werden. Die logischen Zuordnungen zwischen den Sensoren können in einem Verzeichnis gespeichert werden, das zwischen allen Knoten in einer Site synchronisiert wird. Die physische Hierarchie und die physischen Knoten sind auf VMS-Setup-Seiten sichtbar, damit Benutzer Knoten und Einheiten, die nicht in der logischen Ansicht sichtbar sind, konfigurieren können.
Die Darstellung und der logische Aufbau der Site können sich je nach der für das Front-End unterstützten Anwendung unterscheiden. 11A zeigt ein Diagramm, das ein physisches Modell einer Site für eine VMS-Anwendung veranschaulicht. Die Site besteht aus Knoten, die leistungsstarke NVR-Systeme (Network Video Recorder) 1102, 1104 und 1106 sind, die über ein leistungsstarkes LAN mit hoher Verfügbarkeit und Kameraknoten mit eingebautem Speicher 1110 angeschlossen sind, sowie Kameraknoten mit Programmspeicher, aber ohne Videospeicher 1108, der über zuverlässige oder unzuverlässige Links (zum Beispiel drahtlos, WAN 1116 oder LAN) angeschlossen ist. Ebenso dargestellt sind eine WAN-Client-Workstation 1118 und ein mobiler Client 1120 sowie eine LAN-Client-Workstation 1122, ein lokaler Schalter 1112 und ein Router 1114.
Beispielhafte Systemarchitektur
11B ist ein Diagramm, das eine beispielhafte Systemarchitektur für ein Kameraüberwachungs- und Zugangskontrollsystem veranschaulicht. Die Sites und Knoten können mit Kameras, Zugangskontrollgeräten und anderen Elementen, wie in 11B gezeigt, zusammenhängen. Ein nachfolgend beschriebenes verteiltes Site-Management-System kann das Management von Überwachungssystemen, Zugangskontrollsystemen sowie von hybriden Video- und Zugangskontrollsystemen erleichtern.
Site Families
Site Families führen einen Mechanismus ein, über den Sites kommunikativ gekoppelt sein können, um den Austausch organisationsweiter Daten, wie Benutzer und Gruppeneinstellungen, zu ermöglichen. Zudem kann Benutzergruppen und Sites innerhalb einer Site Family eine Hierarchie auferlegt werden, um eine einfachere Einrichtung globaler Zugangskontrollen und -berechtigungen zu ermöglichen. Die Hierarchie kann auch dazu verwendet werden, die Reproduktion sensibler Daten, wie Benutzeranmelderechte, auf weniger gesicherte Sites zu beschränken. Wird eine Hierarchie für eine Site Family festgelegt, können die einzelnen Sites innerhalb der Hierarchie platziert werden, wenn sie der Parent Site beitreten. In einer Ausführungsform besteht eine Hierarchie vor der Einrichtung einer Child Site. Nach der Einrichtung der Site Family können Gruppen von der Parent Site verwaltet werden und einen Rang zugewiesen bekommen, was dazu beiträgt, die gültigen Genehmigungen der Benutzer, die Teil dieser Gruppe sind, zu bestimmen und außerdem festzulegen, welche Benutzer und Gruppen die Parent Site mit einer Child Site synchronisieren wird.
Sites in einer Site Family müssen selbst dann betriebsfähig und hoch verfügbar bleiben, wenn die Site-Site-Kommunikation über Netzwerklinks mit niedriger Zuverlässigkeit und/oder niedriger Leistung stattfindet. Gleichzeitig müssen Site Families die einfache Konfiguration von Zugangskontroll-, Benutzermanagement- und Datensynchronisierungsgrundsätzen sowie des Netzwerkmanagements von einer zentralen Stelle aus unterstützen. Zusätzlich können sie die Synchronisierung weiterer globaler Daten unterstützen, um die Systemwartung zu vereinfachen. Dazu gehört beispielsweise die Synchronisation von standardmäßigen Systemregeln, die für alle Sites gültig sind.
Ausführungsformen können eine ganze Reihe von Systemen unterstützen, die von Systemen, die nur aus ein paar wenigen Sites mit einzelnen Serverknoten bestehen, bis zu Systemen reichen, die aus Tausenden von Sites mit jeweils vielen Hunderten von Knoten und vielen Tausenden von Benutzern bestehen. Ein hierarchisches Modell für die Konfiguration und Zugangskontrolle vereinfacht die Einrichtung dieser Systeme.
12 zeigt ein Diagramm, das eine beispielhafte Site-Hierarchie 1200 veranschaulicht, die aus einer Parent Site 1202 und mehreren Child Sites 1204, 1206 und 1208 besteht, die über ein Großraumnetzwerk verbunden sind. Die Child Sites 1204, 1206 und 1208 kommunizieren zur Durchführung globaler Konfigurationseinstellungen, wie z. B. ACLs (Access Control Lists) für Benutzer mehrerer Sites, mit einer designierten Parent Site 1202. In einer Ausführungsform wird im Site-Family-Modell kein Peer-to-Peer-Modell verwendet, weil die Child Sites nicht an physisch gesicherten Stellen angeordnet sein dürfen und man sich nicht darauf verlassen darf, dass sie in Bezug auf die Sicherheit nicht gefährdet sind. Eine einzelne Parent Site 1202 ermöglicht, dass diese Site 1202 gegen eine Gefährdung physisch gesichert ist und eine Stelle vorsieht, an der die empfindlichsten Informationen, wie die Anmeldedaten von Benutzern mit Super-Benutzerzugang zu allen Sites, gespeichert werden. Außerdem können von der Parent Site für die gesamte Kommunikation zwischen der Child Site und der Parent Site ACLs durchgesetzt werden, um unabhängig von Gruppen-, Site- oder Benutzerberechtigungsstufen zu verhindern, dass eine Child Site auf gesperrte Informationen zugreift.
Die Child Sites 1204, 1206 und 1208 können lose verbunden sein und bei nicht vorhandener Konnektivität mit der Parent Site 1202 weiterhin unabhängig voneinander arbeiten. Sites oder Site Families können auch mit Plattformen für Cloud-Dienste verbunden sein. Cloud-Dienste können die Archivierung kritischer Sensordaten, eine gehostete Metadatenanalyse, Systemberichte, Einzelpunkt-Client-Zugriff oder andere Dienste, die die Plattformfähigkeit erhöhen, außerhalb der Site umfassen.
Knoten-, Site- und Multisite-Modelle erlauben den Benutzern die Konfiguration und Verwaltung von Systemen in geeignetem Umfang auf intuitive Weise. Beispielsweise können Grundsätze und Konfigurationen, die nur für eine bestimmte Site gelten, auf Site-Ebene und solche, die für alle Sites gelten, auf Multisite-Ebene festgelegt werden.
Schnittstellen für das Site-Management einer Child Site
13 zeigt ein Diagramm, das Schnittstellen (vorliegend auch als kombinierte Benutzerschnittstelle bezeichnet) für das Site-Management einer Child Site veranschaulicht. 13 zeigt eine beispielhafte Benutzerinteraktionssequenz für die Verbindung einer Child Site A mit der Parent Site A und ihre Zuordnung zum Rang West Coast. Die Schnittstelle 1302 entspricht 1 und ist die UI-Darstellung (User Interface) der „physischen“ Kommunikationshierarchie, während die Schnittstelle 1304 16 und 17 entspricht und die UI-Darstellung der „logischen“ Berechtigungshierarchie für die Sites in einer Site Family ist.
Die Schnittstelle 1302 ermöglicht die Auswahl eines Child-Knotens. Die Schnittstelle 1304 ermöglicht das Hinzufügen des ausgewählten Child-Knotens zu einer Hierarchie. Der Rang innerhalb der Hierarchie ist auswählbar, im vorliegenden Beispiel anhand einer Auswahlliste. Die Aufforderung 1306 zeigt an, dass durch das Hinzufügen einer Child Site zu einer Parent Site die Site-Site-Synchronisierung möglich ist. Die erfolgreiche Aktivierung der Synchronisierung wird in dem Pop-up-Fenster 1308 angezeigt, die nicht erfolgreiche Aktivierung in dem Pop-up-Fenster 1310.
In einer Ausführungsform ist die Einrichtung der Child Site in einem Site-Management-Dialog angeordnet. Sites, die Child Sites sein können, können eine Schaltfläche „Synchronisieren“ oder „Mit Parent verbinden“ sowie den Status der Site-Synchronisierung anzeigen. Alternativ kann ein Benutzer eine Child Site in eine Parent Site ziehen oder auf andere Weise auswählen und verbinden, um sie zu der Hierarchie der Parent Site hinzuzufügen, was zum gleichen Ergebnis führt. In einer Ausführungsform muss ein Benutzer sowohl beim Parent als auch beim Child angemeldet sein und über die entsprechenden Genehmigungen verfügen, um die Child Site der Hierarchie hinzuzufügen.
Darüber hinaus kann auch eine Eingabe über Drag-und-Drop erfolgen, um die Verbindung und Trennung manuell durchzuführen. In einer Ausführungsform mit Drag-und-Drop kann der Benutzer beispielsweise ein Symbol einer Child Site ziehen und ablegen, die mit einer Parent Site verbunden werden soll.
Die Verbindung einer Site mit einer Parent Site kann ein expliziter Vorgang sein. Die grafische Benutzerschnittstelle kann eine spezielle Schaltfläche oder eine Auswahloption aufweisen, um den Vorgang auszulösen.
Verbindung einer Child Site mit einer Parent Site
14 zeigt ein Nachrichtensequenzdiagramm, das veranschaulicht, wie eine Kandidaten-Site mit einer Parent Site (Site Family) verbunden werden kann. Der Client hat bereits eine sichere Anmeldesitzung 1402 mit der Parent Site mit mindestens der „Berechtigung zum Site-Management“ und eine sichere Anmeldesitzung 1404 mit allen Berechtigungen mit der Kandidaten-Site eingerichtet.
In Schritt A von 14 fragt der Client die Parent Site ab, um Informationen zu erhalten, die die Kandidaten-Child-Site benötigt, um der Site Family beizutreten.
In Schritt B von 14 sendet die Parent Site das Ergebnis mit den Daten 1403 über die Site Family zurück. In Ausführungsformen, die eine tokenbasierte Authentifizierung verwenden, erzeugt die Parent Site einen eindeutigen Zugangstoken und sendet diesen zurück, damit ihn die Kandidaten-Site in diesen Informationen verwenden kann. Der Client kann diese Daten 1403 auf die Kandidaten-Site laden.
In Schritt C von 14 gibt der Client eine Aufforderung an die Kandidaten-Site aus, der Site Family mit den geladenen Daten 1403 beizutreten. In einigen Fällen können die geladenen Daten 1403 einen Zugangstoken 1404, wie zum Beispiel den von der Parent Site erzeugten eindeutigen Zugangstoken, umfassen.
In Schritt D von 14 gibt die Kandidaten-Site einen Beitrittsvorgang an die Parent Site mit den geladenen Daten 1403 aus.
In Schritt E von 14 erzeugt die Parent Site nach der Authentifizierung der im Beitritt enthaltenen Daten 1403 Berechtigungsdaten 1405 für die Child Site. In Ausführungsformen, die eine tokenbasierte Authentifizierung verwenden, prüft die Parent Site die geladenen Daten, einschließlich des Zugangstokens und assoziiert den Token mit der den Beitritt anfordernden Child Site. Dann speichert die Parent Site den Token und die assoziierte Identität der Child Site in ihrem dauerhaften Verzeichnisspeicher.
In Schritt F von 14 sendet die Parent Site die Berechtigungsdaten 1405 an die Child Site zurück.
„Verzeichnis“- und „Knoten“-Dienste
Eine mehrere Knoten enthaltende Parent Site kann Redundanz vorsehen und die Parent Site in die Lage versetzen, weiterhin Dienste zu bieten, solange ein einzelner Knoten läuft und erreichbar ist. In einer Ausführungsform werden die Berechtigungsdaten 1405 für die Child Site von den „Verzeichnis“-Diensten an alle Knoten der Parent Site reproduziert. In einer Ausführungsform kann der Server der die Beitrittsanforderung handhabenden Parent Site die Berechtigungsdaten mit Hilfe der Geteilte-Benutzerobjekte-Anwendung 228, in der die Child Site als besonderer Benutzertyp behandelt wird, speichern. Dadurch wird gewährleistet, dass die Child Site ermächtigt werden kann, auf Ressourcen von einem beliebigen Knoten der Parent Site zuzugreifen. Ferner können in einer Ausführungsform die „Knoten“-Dienste der Child Site mit allen erreichbaren Endpunkten der Parent Site konfiguriert werden, beispielsweise indem dem Benutzer eine Client-Schnittstelle bereitgestellt wird, damit er jeden Endpunkt manuell hinzufügen kann. Der „Knoten“-Dienst erhält diese Endpunkteliste dauerhaft in der Child Site aufrecht. Falls ein Endpunkt für die Parent Site nicht erreichbar ist, kann die Child Site versuchen, sich mit Hilfe von alternierenden Endpunkten, die in dem Knotendienst gespeichert sind, zu verbinden. In einer weiteren Ausführungsform kann die Parent Site selbst eine Liste von über Fernzugriff verfügbaren Endpunkten im Parent-Site-Verzeichnis speichern. Diese Endpunkte können über eine Benutzerschnittstelle in einem Client konfiguriert werden, der von einem Benutzer mit ausreichenden Berechtigungen mit der Parent Site verbunden worden ist. Bei der Benutzerschnittstelle kann es sich um eine einfache Liste von Endpunkten handeln, zu der der Benutzer Endpunkte hinzufügen oder aus der der Benutzer Endpunkte entfernen kann. In dieser Ausführungsform kann Child Sites, die mit der Parent Site verbunden sind, der Zugriff auf die Parent Site gewährt werden, um diese Endpunkte ohne Konfiguration durch den Benutzer wie in der zuvor beschriebenen Ausführungsform automatisch in ihren Knotendienst zu synchronisieren.
Diese entfernten Endpunkte können auch dauerhaft in den Verzeichnissen der Child Site gespeichert werden. Entfernte Clients mit einem einzelnen entfernten Endpunkt würden die Endpunkte herunterladen und in den Cache-Speicher aufnehmen und sie zum Konfigurieren des Client-Knotendienstes verwenden, um Verbindungsredundanz für Child Sites bereitzustellen. In einigen Ausführungsformen können Child Sites diese entfernten Endpunkte auch mit dem Verzeichnis entfernter Endpunkte der Parent Site synchronisieren. In diesen Ausführungsformen wäre eine Client-Anwendung, wenn ein einziger zugänglicher Endpunkt der Parent Site gegeben wäre, in der Lage, ihren Knotendienst mit den Endpunkten aller Sites in der ganzen Site Family automatisch zu konfigurieren, was die Konfiguration des entfernten Clients für sehr große Site Families vereinfacht
Bei den “Knoten”-Diensten kann es sich um ein Knotenprotokoll handeln, das dafür verantwortlich ist, eine Ansicht der Netzwerktopologie des Systems für jeden Knoten zu erzeugen, die jeden Knoten mit einer Netzwerkkarte versieht, um ihm die Kommunikation mit jedem anderen Knoten im System zu erlauben. In einigen Ausführungsformen ist die Netzwerkkarte eine Leitwegtabelle. Die Netzwerkkarte kann auf Kommunikationsendpunkte verweisen, die eine Adresse (IP/FQDN), eine Anschlussnummer und ein Protokoll sind, durch das ein Knoten über das IP-Netzwerk, das die Knoten verbindet, erreicht werden kann.
“Verzeichnis”-Dienste sind Dienste der Anwendungsschicht, die eine gemeinsame Nutzung von Einstellungen, Berechtigungsnachweise, Systeminformationen und anderen Daten zwischen Knoten unterstützen. Geteilte-Einstellungen-Anwendung 226 und Geteilte-Benutzerobjekte-Anwendung 228 sind Beispiele für Verzeichnisdienste mit dauerhaftem Speicher-Backing. Systeminformation 230 ist ein Beispiel für einen Verzeichnisdienst, der in einigen Ausführungsformen möglicherweise keine Beständigkeit hat, weil die enthaltene Information bei Laufzeit wiederhergestellt werden kann. Die zugrunde liegende Replikation kann durch verschiedene Protokolle in der Datensynchronisationsschicht von 2 bereitgestellt werden, wie etwa Synchronie 214, Übereinstimmung 216 oder Status 218.
Ein Administrator kann sehen, welche Benutzer und Gruppen mit einer Child Site synchronisiert sind. Dazu kann es erforderlich sein, dass die Child Site Benutzer und Gruppen periodisch mit der Parent Site synchronisiert.
In einer Ausführungsform kann ein Server in einer Parent oder Child Site nur einer Parent oder Child Site angeschlossen werden, wenn diese ein Einzelstandort ist. Wenn sie angeschlossen ist, kann der Server Einstellungen mit der Site synchronisieren, aber er übernimmt nicht-lokale Einstellungen wie etwa entfernte Benutzer und Gruppen und Zugangsberechtigungsnachweise von der Site, die er gerade angeschlossen hat.
In einer Ausführungsform kann eine Site nicht als Parent oder Child Site konfiguriert werden, wenn ein oder mehrere Server in der Site die Site Family-Fähigkeiten nicht unterstützen. In einer Ausführungsform sollte eine Parent Site ablehnen, dass sich eine Child Site einer Site Family anschließt, wenn ein oder mehrere Server an dieser Child Site die Site Family-Fähigkeiten nicht unterstützen.
In einer Ausführungsform wird der Export der globalen Site Family-Benutzer und -gruppen und -hierarchie, die von der Parent Site verwaltet werden, zu Backup-Zwecken unterstützt. Eine Benutzerschnittstelle kann im Client bereitgestellt sein, die für entsprechend berechtigte Benutzer, die mit der Parent Site verbunden sind, verfügbar ist, um die Benutzer und Gruppen in eine Datei zu exportieren oder importieren. In einer Ausführungsform kann die exportierte Einstellung nicht in eine Child Site importiert werden, weil sie in der Child Site schreibgeschützt ist. In einer anderen Ausführungsform kann der Import durch eine Child Site, die über entsprechenden Schreibzugriff und Rechte für die Parent Site verfügt, unterstützt werden. Eine Child Site sollte keine Benutzer und Gruppen exportieren, die sie nicht authentifizieren kann. In einer Ausführungsform kann eine Child Site möglicherweise keine entfernten Benutzer und Gruppen exportieren, weil diese Gruppen nur von der Parent Site authentifiziert werden können.
In einer Ausführungsform kann ein Benutzer eine Site mit einer Parent Site „verbinden“. Ein Benutzer kann eine Site von seiner Parent Site „trennen“. Ein Benutzer kann zentral wählen, welche Benutzer und Gruppen mit jeder Child Site synchronisiert werden, um eine Wiederholung “für jede Site” zu vermeiden. In einer Ausführungsform ist nicht-wiederholende Zuordnung durch die Ranghierarchie und Benutzerschnittstellen aktiviert, um Benutzer, Gruppen und Sites in dieser Hierarchie zu verwalten.
Schnittstelle für das Site-Management von Parent Sites
15 ist ein Diagramm, das eine Schnittstelle für das Site-Management von Parent Sites veranschaulicht. Das Beispiel von 15 zeigt die Bearbeitung der Ranghierarchie an der Parent Site durch Löschen des Rangs Oregon. Child Site C ist verwaist und verliert alle Rechte für die Site Family, bis ihr ein neuer Rang zugeordnet wird. (Die Ranghierarchie erlaubt eventuell Drag-und-Drop, um den Rang von Elementen neu zu ordnen).
Schnittstelle 1502 erlaubt die Auswahl einer Parent Site. Schnittstelle 1508 kann verwendet werden, um einen Rang mit Warnung 1510, die auf die Folgen einer Ranglöschung hinweist, zu löschen.
Die Synchronisationseinstellung der Child Site kann sich in einem Site-Management-Dialog befinden. In einigen Ausführungsformen kann die Synchronisation der Child Site aktiviert oder deaktiviert sein. Zum Beispiel kann in 15 die Schnittstelle 1502, wenn die Parent Site ausgewählt ist, eine Einstellungsschaltfläche anzeigen, um die Schnittstelle 1508 zu öffnen. Schnittstelle 1508 kann ein Kontrollkästchen enthalten, um die Synchronisation mit allen Child Sites zu aktivieren oder zu deaktivieren und um den aktuellen Status der Synchronisation anzuzeigen.
Rang
16 zeigt einen Baum, der einen Satz hierarchischer Berechtigungsstufen (Ränge) darstellt. Objekte, die einem Rang in diesem Baum zugeordnet sind, erhalten privilegierten Zugang zu allen Rängen im Teilbaum unter dem zugeordneten Rang, einschließlich des Privilegs, den Teilbaum zu bearbeiten. Im Beispiel von 16 stellt der Rang Global Zugangsprivilegien dar zum Teilbaum, der Kanada enthält, und zum Teilbaum, der USA enthält, sowie dessen Child Sites: Ostküste, Westküste und Oregon. Der Rang USA stellt den Zugang zu den Rängen Ost- und Westküste dar. Die Rangnamen sind generisch und müssen nicht zwangsläufig geografisch sein, wie in 16 veranschaulicht. Beispielsweise können Ränge von organisatorischer Art sein (z. B. Technik, Betrieb, IT usw.).
Objekte können einer Position im Rang, von dem sie einen Rang übernehmen, zugeordnet werden. 17 veranschaulicht die Beziehung zwischen Objekten und Rang und umfasst die Ränge Global 1701, USA 1702, Kanada 1704, Westküste 1705, Ostküste 1706 und Oregon 1703, denen Benutzergruppen- und Child Site-Objekte zugeordnet sind. Die Ränge in diesem Beispiel entsprechen denen mit demselben Namen in 16.
In einer Ausführungsform kann ein Rang einer Gruppe zugeordnet sein, wie etwa Global 1701, USA 1702, Kanada 1704, Westküste 1705, Ostküste 1706 und Oregon 1703, wie in 17 gezeigt. Ein Benutzer, der ein Mitglied einer eingeordneten Gruppe ist, übernimmt den Gruppenrang. Ein Benutzer, der ein Mitglied mehrerer eingeordneter Gruppen ist, übernimmt einen Verband von Gruppenrängen, wobei der Rangveband als die Sammlung von Teilbäumen des Gruppenrangs, dessen Mitglied der Benutzer ist, definiert ist. Wenn beispielsweise ein Benutzer den beiden Gruppen Kanada-Administratoren und USA-Administratoren in 17 zugeordnet ist, hätte er Zugang zu Objekten in den Teilbäumen von sowohl Kanada als auch USA von 16. In einer Ausführungsform bestimmt der Rang der Benutzer, zu welchen Gruppen sie Zugang haben. Ein eingeordneter Benutzer hat Zugang zu Gruppen eines niedrigeren Rangs und darf diese bearbeiten. Im Beispiel von 17 sind Benutzer, die den Rang Oregon 1703 übernehmen, nicht berechtigt, irgendeine Gruppe zu ändern, weil es keine Gruppen von niedrigerem Rang gibt, während Benutzern, die der Gruppe USA-Administratoren angehören, den Rang USA 1702 übernehmen und folglich berechtigt sind, auf die Gruppen Benutzer westliche Regionen und Benutzer Oregon Admin zuzugreifen oder diese zu ändern. Das Ändern einer Gruppe kann darin bestehen, dass sie einem höheren Rang zugeordnet wird, dass Benutzer zu der Gruppe hinzugefügt werden oder die Berechtigungen der Gruppe geändert werden, um beispielsweise den Zugang zu spezifischen Einstellungsvorgängen oder Live-Video in einem VMS-System zu erlauben bzw. zu verweigern.
Insbesondere kann es in einer Ausführungsform einem Benutzer nicht möglich sein, einer Gruppe einen Rang zuzuordnen, der höher als sein eigener Rang ist. Er darf aber eventuell einer Gruppe einen Rang zuordnen, der gleich oder niedriger als sein eigener Rang ist. Ebenso darf ein Benutzer anderen Gruppen oder Sites keine Berechtigungen zuordnen, die er selbst nicht hat.
In einer Ausführungsform kann einer Child Site ein Rang zugeordnet werden. Der Rang der Child Site kann bestimmen, welche eingeordneten Benutzer/Gruppen Zugang zur Site haben. In einer Ausführungsform hat ein eingeordneter Benutzer nur Zugang zu Child Sites von gleichem oder niedrigerem Rang (dem Teilbaum, dem die Gruppe des Benutzers zugeordnet ist). Im Beispiel von 17 haben Benutzer mit dem Rang Oregon 1703 Zugang zur Child Site C, aber nicht zu den Child Sites A, B oder C; Benutzer mit dem Rang Westküste 1705 haben Zugang zu den Child Sites A, B und C, aber nicht zu D; Benutzer mit den Rängen USA 1702 oder Global 1701 haben Zugang zu den Child Sites A, B, C und D. In einer Ausführungsform sind die Child Sites, zu denen ein Benutzer keinen Zugang hat, für den Benutzer nicht sichtbar. Der Rang einer Site kann auch bestimmen, welche Teilsätze globaler Daten zugreifbar sind. Beispielsweise hat eine Site mit dem Rang Kanada 1704 eventuell keinen Zugang zu Gruppen oder anderen Objekten, die dem Rang USA 1702 zugeordnet sind.
Weil ein Rang einen Satz von Sites beschreibt, hat ein Benutzer auf diesem Rang Zugang zu diesem Satz von Child Sites. Einem Benutzer kann eine Ranghierarchie präsentiert werden, und durch Auswählen eines Rangs kann er automatisch mit allen Sites innerhalb des Rangs verbunden werden, sodass ein Benutzer mit hohen Privilegien leichter ein Problem, das mehrere Sites übergreift, untersuchen kann.
Die Konfiguration kann den Child Sites von den Parent Sites bereitgestellt werden. Diese Konfiguration kann Regeln, Warnungen, Benutzer, Gruppen, Einstellungsinformationen für Geräte, wie etwa IP-Adressen für Kameras usw. umfassen. Diese Organisationsstruktur kann eventuell die Zeit verkürzen, die eine manuelle Einstellung der Konfiguration an der Child Site erfordern würde. Zum Beispiel die Regel: „Benachrichtigung an lokale Administrator-Benutzer senden, wenn eine Kamera offline geht“ könnte als eine globale Standardregel für die gesamte Site Family definiert sein. Child Sites würden diese Regel von der Parent Site synchronisieren, wann immer sie von Benutzern geändert oder bearbeitet wird. Die Ränge könnten auch dazu dienen, den Umfang von Alarmen, Benachrichtigungen und anderen Ereignissen zu bestimmen. Zum Beispiel können Administratoren an der Westküste gewarnt werden, wenn ein Server an der Westküste ausfällt, aber nicht benachrichtigt werden, wenn ein Server an der Ostküste ausfällt.
In einer Ausführungsform ist der Rang “Global” im Hierarchiebaum unveränderlich. Global stellt den Stammknoten in der Hierarchie dar, was zur Folge hat, dass es keinen „höheren“ Rang als Global geben darf.
Manchen Gruppen sind eventuell keine Ränge zugeordnet. Gruppen ohne Rang sind nicht Teil des Privileghierarchiebaums. Standardmäßig können folgende Gruppen auf einer neu erstellten Site dazu gehören: Administratoren, Hochleistungsbenutzer, Standardbenutzer und Eingeschränkte Benutzer.
In einer Ausführungsform werden Gruppen ohne Rang nicht zwischen Sites synchronisiert und existieren nur als lokal definierte Gruppen mit Zugangsrechten und -privilegien, die für die Site gelten, die sie besitzt und verwaltet. Der Zugang eines Benutzers, der einer Gruppe ohne Rang zugeordnet ist, ist auf die Site begrenzt, die die Gruppe verwaltet. Wenn eine Gruppe ohne Rang berechtigt ist, die Ranghierarchie zu ändern, und wenn die Site, die die Gruppe ohne Rang verwaltet, ebenfalls berechtigt ist, die Ranghierarchie zu ändern, dürfen Benutzer, die der Gruppe angehören, Gruppen ohne Rang bearbeiten oder der Ranghierarchie zuordnen. Sobald eine Gruppe der Ranghierarchie zugeordnet ist, kann sie zwischen Sites synchronisiert werden. In einer Ausführungsform ist keine der Child Sites berechtigt, die Ranghierarchie zu ändern oder Ränge Gruppen zuzuordnen, sodass nur die Parent Site in der Lage ist, die Ranghierarchie zu ändern oder ihr Gruppen zuzuordnen.
In einer Ausführungsform dürfen nur Benutzer, die Mitglieder von Gruppen ohne Rang sind und die berechtigt sind, Benutzer und Gruppen zu verwalten, andere Gruppen ohne Rang erstellen. Gruppen ohne Rang dürfen nicht mit den Gruppen des Rangs Global verwechselt werden: die Ersteren sind nicht Teil der Hierarchie und können auf jedes eingeordnete Objekt zugreifen, einschließlich Global; die Letzteren können nur auf Objekte mit einem zugeordneten Rang zugreifen.
In einer Ausführungsform können einige Sites lokale Benutzer haben, die nicht mit anderen Sites synchronisiert sind, die aber einer Gruppe mit Rang, die zwischen Sites synchronisiert ist, zugeordnet sind. In diesem Fall übernimmt der Benutzer die Privilegien und Zugangsrechte von der Gruppe, wird aber nicht zwischen Sites synchronisiert. Der Zugang des Benutzers ist also auf die lokale Site begrenzt.
Alle anderen Ränge können über eine Schnittstelle, die durch ein Einstellungsfenster zugänglich ist, von einem Benutzer mit ausreichenden Privilegien, wie etwa Verwaltung von Hierarchieprivilegien, benutzerdefiniert werden.
Der Rang gilt nicht nur für Gruppen, sondern auch für Sites in einer Site Family. Der Rang einer Child Site kann beispielsweise bestimmen, welche anderen synchronisierbaren eingeordneten Objekte (z. B. Benutzer und Gruppen) mit dieser Site synchronisiert werden. Die Synchronisation von Benutzern und Gruppen kann beinhalten, welche Benutzer Zugang zur Child Site haben. Siehe dazu beispielsweise 18, in welcher die Child Site A keinen Zugang zu Objekten über dem Rang Westküste hat.
Eine Site kann entweder eine Parent Site oder eine Child Site oder keines von beiden sein. Eine Child Site in einer Site Family ist ein Objekt, dessen Zugriff auf Daten, die von der Parent Site verfügbar sind, beschränkt werden kann, um den Umfang der Offenlegung von sensiblen Daten auf ein Minimum zu beschränken, falls diese Child Site gefährdet wird. Beispielsweise kann der Zugang der Child Site darauf begrenzt werden, dass nur Benutzerauthentifikationsfunktionen von der Parent Site zugänglich sind, wie etwa globale Gruppen und Ränge und Benutzer, aber nicht die Passwörter dieser Benutzer. Eine Child Site ohne Passwortzugang würde hinsichtlich der Benutzerauthentifikation von der Parent Site abhängen. In einigen Ausführungsformen ist die Zugangsebene der Child Site auf die Parent Site der Schnittpunkt der Benutzer- und Site-Rechte. Zum Beispiel wäre ein Superuser mit privilegiertem Zugriff auf globale Admin-Benutzer und deren Berechtigungsnachweise, der in einer Child Site ohne privilegierten Zugriff auf globale Admin-Benutzer angemeldet ist, nicht in der Lage, auf globale Admin-Benutzer zuzugreifen. Der Superuser müsste sich bei einer Parent Site anmelden, um auf diese Benutzerdaten zuzugreifen.
In einigen Ausführungsformen kann die Child Site die von der Parent Site heruntergeladenen Ränge, Gruppen und Benutzerberechtigungsnachweise in einen Cache-Speicher aufnehmen, um es diesen Benutzern zu ermöglichen, sich anzumelden, wenn die Parent Site nicht verfügbar ist. Verschiedene Caching-Strategien können definiert werden, um die Gefahr, dass Benutzerberechtigungsnachweise gefährdet werden, zu begrenzen. Einige Beispiele für solche Strategien sind ein Caching von Benutzern mit niedrigen Privilegien zu erlauben, aber nicht von Benutzern mit hohen Privilegien (z. B. Benutzer mit dem Privileg, die Privilegien anderer Benutzer zu ändern oder die Sites in der Site Family zu verwalten); oder die Dauer des Caching von Berechtigungsnachweisen zu begrenzen, indem die Berechtigungsnachweise nach einer festgelegten Zeitraum gelöscht werden. Alternativ kann die Authentifikation an die Parent Site delegiert werden, wenn Passwörter auf der Child Site nicht im Cache gespeichert werden. In diesem Fall können Benutzer- und Gruppenobjekte auf den Child Sites schreibgeschützt sein. Es kann für die Sicherheit vorteilhaft sein, wenn Passwörter auf der Child Site nicht im Cache gespeichert werden.
Die Parent und Child Sites können einander gegenseitig so authentifizieren, dass sich beide Sites der Identität der anderen sicher sind, um Site-Personifikation und Mittelsmannangriffe zu verhindern. In einigen Ausführungsformen kann dies durch den Austausch eines geteilten Geheimnisses bewerkstelligt werden, wenn die Child Site mit der Parent Site verbunden ist, das verwendet werden kann, um einen gesicherten Kommunikationskanal über ein Protokoll wie etwa Transport Layer Security Secure Remote Password (TLS-SRP) herzustellen. Alternativ können Zertifikate ausgetauscht werden, wenn eine Child Site der Site Family angeschlossen wird, und sowohl die Child Site als auch die Parent Site können sogenanntes Certificate Pinning, kombiniert mit traditioneller Transport Layer Security (TLS) und gegenseitiger Authentifikation, verwenden, um sichere Kommunikationskanäle zwischen Child und Parent Site herzustellen.
Synchronisation
In einer Ausführungsform können Sites optional externe Benutzer und Gruppen anhand eines Synchronisationssystems, wie etwa dem von Microsoft hergestellten Active Directory (AD), synchronisieren, um innerhalb der Site Family verwaltet zu werden. Gruppen, die von AD in einer Site synchronisiert werden, können ohne Rang oder einem Standardrang zugeordnet sein. Die Zugriffssteuerungsstrategien für AD-Benutzer und -Gruppen sind dieselben wie für Nicht-AD-Benutzer und -Gruppen. Ein eingeordneter AD-Benutzer kann auf Benutzer von niedrigerem Rang und auf Child Sites von gleichem oder niedrigerem Rang zugreifen. AD-Benutzern und -Gruppen, die von der Parent Site heruntergeladen wurden, können Ränge zugeordnet werden und sie können mit Child Sites synchronisiert werden. Für Site Families, deren AD-Synchronisation von der Parent Site verwaltet wird, müssen Child Sites nicht auf derselben AD-Domäne oder mit AD synchronisiert sein, wenn die AD-Benutzeranmeldeauthentifikation zu den Child Sites durch die Parent Site delegiert ist. Active Directory (AD)-Benutzer können den Rang der AD-Gruppen, deren Mitglieder sie sind, „übernehmen“. Eine Child Site kann auch lokale Benutzer erstellen, indem Benutzer und Gruppen vom Active Directory (AD) synchronisiert werden. Eine Child Site muss nicht zwangsläufig auf derselben AD-Domäne wie die Parent Site sein, ebenso wenig wie die Parent Site zwangsläufig auf einer AD-Domäne sein muss. Zugriffsrechte für Objekte, die lokal für Sites sind, müssen nicht synchronisiert werden und können lokal für eine Site bleiben. Die Site-Site-Synchronisierung kann ein Master-Slave-Synchronisationsmodell verwenden. Es muss keine Peer-Peer-Synchronisation verwendet werden. Die Synchronisation kann auf Pull-Basis (auf Anfrage durch Ereignisse wie Login oder Bearbeitungseinstellungen auf der Child Site) statt auf Push-Basis (bei Benachrichtigung von der Parent Site) sein. In einer Ausführungsform kann ein Site-Site-Synchronisierungsmechanismus verwendet werden, um Benutzer-, Gruppen- und Stammprivilegien von Parent auf Child Sites zu übertragen.
Child Sites können optional periodisch Informationen über ihren Status und ihre Konfiguration (von den Knoten- und Statusprotokollen) zu einer Parent Site innerhalb der Site Family synchronisieren, um eine zentrale Überwachung von Systemproblemen, wie etwa Serverausfällen, zu ermöglichen. In einem Beispiel kann eine Parent Site, die zuvor Status- und Gesundheitsinformationen von einer Child Site empfangen hat, aufgrund der fehlenden periodischen Synchronisation annehmen, dass eine Child Site vollständig ausgefallen ist, und beispielsweise über eine Benutzerschnittstelle den Ausfall oder die Trennung melden. So sind Benutzer mit kleinen Child Sites mit nur einem einzigen Knoten in der Lage, das Ausfallen dieser Knoten festzustellen.
In einer Ausführungsform kann ein Statusbericht von einer Child Site zu einer Parent Site eine Zusammenfassung sein (z. B. „fehlerfrei“ oder „nicht fehlerfrei“). In Abwesenheit eines Statusberichts von einer Child Site kann der Status einer Child Site unbekannt sein, und eine Parent Site kann daraus folgern, dass die Child Site ausgefallen ist (z. B. Störung oder getrennte Verbindung), und kann über eine Benutzerschnittstelle diesen Status einem Benutzer präsentieren.
In einer Ausführungsform pflegt die Parent Site das „Master“-Benutzer- und Gruppenverzeichnis. In diesem Fall behandeln die Child Sites die Master-Datenbank als schreibgeschützt. Änderungen an Benutzern, Gruppen und Privilegien können auf der Parent Site vorgenommen werden, um anschließend mit einer Child Site von der Parent Site synchronisiert zu werden.
In einer Ausführungsform kann ein Benutzer Benutzer-, Gruppen- und Stammprivilegien auf einer Child Site bearbeiten, wobei die Master-Kopie von der Parent Site verwaltet wird. In diesem Fall kann die Child Site das Master-Gruppenverzeichnis auf der Parent Site lesen und in dieses schreiben, um Änderungen zu synchronisieren. Änderungen von entfernt synchronisierten Objekten auf der Child Site können lokal in den Cache-Speicher aufgenommen und später mit der Parent Site synchronisiert werden.
Die Child Site kann authentifiziert werden, um berechtigt zu sein, Daten von der Parent Site zu synchronisieren. Die Parent Site kann eine Authentifikation und ein Autorisierungsschema auf Token-Basis verwenden, um die Berechtigungsnachweise der Child Site zu überprüfen. In einigen Ausführungsformen kann dieses Zugangs-Token einer Zugangskontrollliste (Access Control List, ACL) und einem Rang auf der Parent Site zugeordnet werden und dauerhaft in dessen Parent Site-Verzeichnis gespeichert werden. Die Child Site behält ihre eigene Kopie des Zugangs-Tokens in ihrem eigenen Verzeichnis. Das Zugangs-Token kann eindeutig für jede berechtigte Child Site erzeugt werden.
Schnittstellen zum Verwalten von Gruppen und Zugangsrechten
18 und 19 zeigen Benutzerschnittstellen zum Verwalten von Gruppen und Zugangsrechten. Schnittstellen 1802, 1902 erlauben die Auswahl einer Gruppe. Gruppen können in einer Baumstruktur dargestellt oder in einer flachen Struktur mit Rangspalte angezeigt werden. In einigen Ausführungsformen kann die Liste von Gruppen, angezeigt zur Bearbeitung, abhängig von den Zugriffsrechten beschränkt werden. Schnittstellen 1804, 1904 erlauben die Bearbeitung von Name, Rang, Privilegien und lokalen Site-Zugriffsrechten für die Gruppe. In einigen Ausführungsformen können Teile der Schnittstellen abhängig von den Zugriffsrechten der Site, von der aus die Gruppen bearbeitet werden, und den Privilegien des Benutzers, der die Bearbeitungen vornimmt, ausgeblendet oder schreibgeschützt sein.
18 zeigt die Bearbeitung der nicht-lokalen Gruppe Benutzer westliche Region von Child Site A des Rangs Westküste in einer beispielhaften Ausführungsform, in der die Gruppe Benutzer westliche Region das Eigentum der Parent Site ist und von dieser verwaltet wird, und die Child Sites auf Nur-Lese-Zugriff auf nicht-lokale Gruppen unter ihrem zugeordneten Rang beschränkt sind. In Schnittstelle 1802 ist eine beschränkte Ansicht der Ranghierarchie von 16 verfügbar, weil Child Site A nicht berechtigt ist, auf andere Objekte außerhalb des Teilbaums Westküste zuzugreifen. In Schnittstelle 1804 sind der Gruppenname, der Rang und die Privilegien schreibgeschützt, weil in dieser beispielhaften Ausführungsform die Child Site A nicht berechtigt ist, diese Eigenschaften zu bearbeiten, weil sie von der Parent Site verwaltet werden. Schnittstelle 1804 erlaubt die Bearbeitung der lokalen Zugriffsrechte in der beispielhaften Ausführungsform, weil diese Objekte Eigentum der Child Site A sind und von dieser verwaltet werden und der angemeldete Benutzer ausreichende Privilegien für deren Bearbeitung hat.
19 ist ein Diagramm, das die Bearbeitung der Gruppe Benutzer westliche Region von Parent Site A in einer beispielhaften Ausführungsform darstellt, wobei die Parent Site Eigentümer der Gruppe Benutzer westliche Region ist und diese verwaltet. Schnittstelle 1902 zeigt alle Gruppenobjekte von 17 in der Ranghierarchie von 16, weil die Parent Site den Rang Global hat. In Schnittstelle 1904 können Name, Rang, Gruppenprivilegien und lokale Zugriffsrechte für Benutzer westliche Region bearbeitet werden, weil die Parent Site und der bearbeitende Benutzer über ausreichende Zugriffsrechte verfügen, um die Eigenschaften dieser Objekte zu ändern.
Eine grafische Benutzerschnittstelle kann bereitgestellt werden, um es einem Benutzer zu erlauben, die Struktur der Site Family zu sehen (Ranghierarchie und welche Gruppen und Sites zu jedem Rang gehören). In einer Ausführungsform wird diese grafische Benutzerschnittstelle den Benutzern helfen, die Auswirkung von Änderungen, die sie vornehmen, zu verstehen.
Entfernte Authentifikation
In einer Ausführungsform muss die Child Site von der entfernten Site authentifiziert und berechtigt werden, damit die Child Site Benutzer- und Gruppenobjekte ihrer Parent Site synchronisieren kann. Eine Child Site kann authentifiziert werden, indem verlangt wird, dass sich der Benutzer in die Child und Parent Sites einloggt, um die Parent Site mit der Child Site zu verbinden. Dies stellt sicher, dass nur berechtigte Benutzer die Verbindung von Child Sites zu Parent Sites autorisieren können.
Die Server-Server-Synchronisation zwischen den Servern in der Child Site und Servern in der Parent Site kann leicht sein. Server müssen nicht zwangsläufig die mit Status und Ressourcen verbundenen dauerhaften Verbindungen und einen Benachrichtigungskanal auf Push-Basis aufrechterhalten, weil eine „REST“-API verwendet werden kann, um mithilfe von Polling Daten standortübergreifend zu synchronisieren. In einer Ausführungsform können die Child Sites Daten nach Bedarf und/oder in regelmäßigen Intervallen abrufen (engl. to pull) statt auf Push-Basis Aktualisierungen von der Parent Site über einen Benachrichtigungskanal zu empfangen. Beispielsweise kann eine Child Site Gruppen, Benutzer und Authentifikationsdaten, die nötig sind, um die Identität, die Privilegien und die Berechtigungsnachweise des Benutzers zu bestätigen, nur dann synchronisieren, wenn sich dieser Benutzer in die Child Site einloggt (auf Anfrage). In einer solchen Ausführungsform kann die Child Site ein dauerhaftes Zugangs-Token, das sie von der Parent Site bezogen hat, verwenden, dem die Parent Site eine dem Rang zugeordnete Zugangskontrollliste (ACL) zuordnet. Die ACL verhindert, dass die Child Site auf Ressourcen der Parent Site zugreift, auch wenn die Benutzer-ACL höher wirksame Privilegien hat.
In einem anderen Beispiel dürfen Benutzer und Gruppen und Site-Hierarchien nur synchronisiert werden, wenn ein Benutzer auf die Site und die Gruppeneinstellungsschnittstellen in der Client-UI zugreift, um sicherzustellen, dass sie auf dem neuesten Stand sind.
20 ist eine Meldungsfolge, die ein entferntes Authentifikationsschema beschreibt, das von der Child Site einer Ausführungsform angewendet wird.
In Schritt A von 20 werden Anmeldedaten 2002 vom Benutzer über eine grafische Schnittstelle auf dem Client eingegeben. Der Client stellt eine sichere Verbindung zum Server her und fordert die Child Site auf, sich unter Verwendung der bereitgestellten Anmeldedaten einzuloggen.
In Schritt B von 20, wenn die Anmeldedaten 2002 für einen entfernt synchronisierten Benutzer sind, kann die Child Site eine gesicherte und gegenseitig authentifizierte Verbindung zur Parent Site herstellen.
In Schritt C von 20 handeln der Client und die Parent Site die Authentifikationsparameter aus, die verwendet werden sollen, um den Benutzer über die Child Site zu authentifizieren.
In Schritt D von 20 akzeptiert die Child Site die Authentifikationsparameter und Berechtigungsnachweise 2002 und sendet die Parameter und die Anmeldedaten über die gesicherte Sitzung an die Parent Site.
In Schritt E von 20 führt die Parent Site die Authentifikationsaufgabe durch, indem die Anmeldedaten 2002 mit den Anmeldedaten verglichen werden, die in einer Backend-Benutzerdatenbank gespeichert sind.
In Schritt F von 20 schließt die Child Site die Verbindung zur Parent Site, nachdem die Parent Site ihre Authentifikationsaufgabe erledigt hat.
In Schritt G von 20 gibt die Child Site das Authentifikationsergebnis an den Client zurück.
In Schritt H von 20 fordert der authentifizierte Client eine neue Sitzung mit der Site an.
In Schritt I von 20 akzeptiert die Child Site die Anfrage des authentifizierten Client zur Herstellung einer Sitzung und erzeugt die Autorisationsdaten 2003. Die Child Site gibt die Autorisationsdaten 2003 an den Client zurück.
In Schritt J von 20 kann die Child Site die Genehmigungen für 2002 aktualisieren, indem nach der Authentifikation der Anmeldedaten eine Synchronisation mit der Parent Site eingeleitet wird.
In Schritt K von 20 reagiert die Parent Site auf die Aktualisierungsanfrage, indem sie den Satz von Genehmigungen für die Gruppe des Benutzers zurückgibt.
Ausführungsformen
In einer Ausführungsform umfasst ein Knoten einen Prozessor und einen Speicher. Der Knoten umfasst ferner computerausführbare Befehle, die im Speicher des Knotens gespeichert sind und die, wenn sie vom Prozessor des Knotens ausgeführt werden, den Knoten zu Handlungen veranlassen. Zu den Handlungen kann das Hinzufügen einer Site als eine Child Site zu einer Parent Site gehören. Das Hinzufügen einer Child Site kann umfassen, dass eine grafische Benutzerschnittstelle angezeigt wird und auf der grafischen Benutzerschnittstelle eine Eingabe empfangen wird und die Site als Child Site zur Parent Site hinzugefügt wird.
Der Knoten kann Teil einer Site sein, wie etwa der Parent Site und der Child Site, oder er kann ein entfernter Client-Computer sein. Die Sites, einschließlich der Child Site, können mit Überwachungskameras verbunden sein.
Die Kontrolle der Child Site kann mit der Parent Site synchronisiert sein. In einer Ausführungsform können Benutzer mit der Fähigkeit, die Parent Site zu verwalten, die Fähigkeit oder den Zugang zum Verwalten der Child Site erwerben, aber Benutzer mit der Fähigkeit, die Child Site zu verwalten, werden nicht die Fähigkeit zum Verwalten der Parent Site erwerben. Nach Rang geordnete Benutzer- und Gruppenprivilegien der Parent Site können im Pull- oder Push-Verfahren zur Child Site übertragen werden.
Eine Child Site kann lokal eine Anmeldedatenbank für lokale Benutzer an der Child Site speichern, sodass eine lokale Anmeldung und eine Authentifikation zur Child Site erlaubt sein kann, auch wenn die Parent Site nicht erreichbar ist. Eine Child Site kann auch den entfernten Benutzer gegenüber der Parent Site, die Anmeldedaten für entfernte Benutzer speichert, authentifizieren, um es den entfernten Benutzern zu ermöglichen, auf mindestens eine Überwachungskamera für die Child Site zuzugreifen.
In einer Ausführungsform umfasst ein Knoten einen Prozessor und einen Speicher. Der Knoten umfasst ferner computerausführbare Befehle, die im Speicher des Knotens gespeichert sind und die, wenn Sie vom Prozessor des Knotens ausgeführt werden, den Knoten zu Handlungen veranlassen. Der Knoten kann bestimmen, dass der Knoten Teil einer Child Site ist. Die Child Site umfasst mehrere synchronisierte Knoten. Der Knoten ist mit mindestens einer Kamera verknüpft. Der Knoten ist mit einem anderen Knoten in einer Parent Site synchronisiert.
Der in den vorhergehenden Ausführungsformen verwendete Prozessor kann beispielsweise ein Mikroprozessor, ein Mikrocontroller, eine speicherprogrammierbare Steuerung, ein feldprogrammierbares Gate-Array oder ein anwendungsspezifischer integrierter Schaltkreis sein. Beispiele für computerlesbare Medien sind nicht flüchtig und umfassen Medien auf Disc-Basis wie CD-ROM und DVD, magnetische Medien wie Festplattenlaufwerke und andere Formen magnetischer Plattenspeicherung, Medien auf Halbleiterbasis wie Flash-Medien, RAM-Speicher und schreibgeschützte Speicher.
Es ist zu berücksichtigen, dass jeder Teil von jedem Aspekt oder der Ausführungsform, behandelt in dieser Spezifikation, mit jedem Teil von einem anderen Aspekt oder einer anderen Ausführungsform, behandelt in dieser Spezifikation, implementiert oder kombiniert werden kann.
Der Einfachheit halber werden die beispielhaften Ausführungsformen als verschiedene miteinander verbundene funktionelle Blöcke beschrieben. Dies ist jedoch nicht notwendig, und es kann Fälle geben, in denen diese funktionellen Blöcke gleichwertig in einer einzelnen logischen Vorrichtung, einem Programm oder einer Operation vereinigt sind. In jedem Fall können die funktionellen Blöcke allein oder in Kombination mit anderen Teilen von Hardware oder Software implementiert werden.
Zwar wurden im Vorhergehenden bestimmte Ausführungsformen beschrieben, doch versteht es sich von selbst, dass andere Ausführungsformen möglich sind und als hierin eingeschlossen gedacht sind. Dem Fachmann wird klar sein, dass Änderungen und Anpassungen der vorhergehenden Ausführungsformen, die nicht gezeigt werden, möglich sind.

Claims

Verfahren zur Steuerung von Sites in einem Sicherheitssystem durch mindestens eine grafische Benutzerschnittstelle, umfassend: Hinzufügen einer Site als eine Child Site zu einer Parent Site im Sicherheitssystem über eine erste grafische Benutzerschnittstelle, auf die durch die Parent Site zugegriffen wird, wobei die Parent Site mit einer oder mehreren Einstellung(en) verbunden ist und wobei die Child Site automatisch die eine oder mehreren Einstellung(en) von der Parent Site übernimmt; und Beschränken eines Zugriffs zum Ändern der einen oder mehreren Einstellung(en) der Parent Site von einer zweiten grafischen Benutzerschnittstelle aus, auf die durch die Child Site zugegriffen wird.
Verfahren nach Anspruch 1, ferner umfassend Ändern von einer oder mehreren Einstellung(en) der Child Site von der ersten grafischen Benutzerschnittstelle aus, auf die durch die Parent Site zugegriffen wird.
Verfahren nach Anspruch 2, ferner umfassend automatisches Aktualisieren der einen oder mehreren Einstellung(en) der Child Site auf der Basis von Änderungen, vorgenommen an der einen oder den mehreren Einstellung(en) der Parent Site.
Verfahren nach Anspruch 1, wobei mindestens eine der Child Sites oder der Parent Sites einen einzelnen Knoten umfasst.
Verfahren nach Anspruch 1, wobei mindestens eine der Child Sites oder der Parent Sites mehrere Knoten umfasst, wobei mindestens einer der mehreren Knoten mit einer Kamera, einer Zugangskontrollvorrichtung oder einem Kontrollknoten verbunden ist.
Verfahren nach Anspruch 1, wobei die Child Site eine oder mehrere Benutzerberechtigungsnachweise in einer Berechtigungsdatenbank an der Child Site speichert und wobei mindestens eine Kamera, verbunden mit der Child Site, zugänglich ist, sobald die Child Site über die zweite grafische Benutzerschnittstelle einen oder mehrere der Berechtigungsnachweise empfängt.
Verfahren nach Anspruch 6, wobei die Berechtigungsdatenbank an der Child Site von einer zweiten Berechtigungsdatenbank, die an der Parent Site gespeichert ist, unabhängig ist, wobei mindestens die Berechtigungsdatenbank und die zweite Berechtigungsdatenbank ein verteiltes Zugangssystem bilden.
Verfahren nach Anspruch 7, ferner umfassend Synchronisieren von mindestens der Berechtigungsdatenbank und der zweiten Berechtigungsdatenbank, sodass die Child Site Bilder von der mindestens einen Kamera unabhängig von der Parent Site anzeigt.
Verfahren nach Anspruch 1, wobei die Parent Site einen oder mehrere Benutzerberechtigungsnachweis(e) in einer zweiten Berechtigungsdatenbank an der Parent Site speichert und wobei die Child Site Benutzerberechtigungsnachweise, die an der Child Site empfangen werden, mit denen an der Parent Site überprüft, um entfernten Zugang zu mindestens einer Kamera, die mit der Child Site verbunden ist, zu gewähren.
Verfahren nach Anspruch 1, wobei der Zugang zur Parent Site durch die erste grafische Benutzerschnittstelle umfasst, dass Benutzerberechtigungsnachweise an der Parent Site empfangen werden, wobei die Benutzerberechtigungsnachweise einem ersten Rang zugeordnet sind, umfassend Zugang zur Parent Site und zur Child Site.
Verfahren nach Anspruch 10, wobei der erste Rang ferner Zugang zum Ändern von Berechtigungsnachweisen oder Attributen der Berechtigungsnachweise umfasst, die mindestens einem anderen Benutzer zugeordnet sind, der dem ersten Rang oder niedrigeren Rängen zugeordnet ist.
Verfahren nach Anspruch 1, wobei nach Rang geordnete Benutzer- und Gruppenprivilegien der Parent Site mit der Child Site synchronisiert werden.
Verfahren nach Anspruch 1, ferner umfassend Auswählen eines Teilsatzes der einen oder mehreren Einstellung(en), um diese von der Parent Site auf die Child Site zu übertragen.
Verfahren nach Anspruch 1, wobei die eine oder mehreren Einstellung(en) mindestens eines von einer Regel, einer Warnung, Benutzerberechtigungsnachweisen, Gruppenberechtigungsnachweisen, einem Netzwerk-Endpunkt für Fernzugang, einer Standardgeräteeinstellung oder einem Standardaufzeichnungsplan für mindestens eine Kamera oder einen Sensor umfassen.
Verfahren nach Anspruch 1, wobei die erste grafische Benutzerschnittstelle und die zweite grafische Benutzerschnittstelle von einem gemeinsamen Knoten oder einer gemeinsamen Site erzeugt werden.
Nicht flüchtiges computerlesbares Medium, das Befehle zur Kontrolle des Zugangs zu Sites in einem Sicherheitssystem durch eine grafische Benutzerschnittstelle speichert, die, wenn sie von einem Prozessor ausgeführt werden, den Prozessor veranlassen, folgende Handlungen auszuführen: Zuordnen eines Rangs zu jeder der Sites des Sicherheitssystems, wobei jeder Rang mindestens einem Satz von Benutzerberechtigungsnachweisen zugeordnet ist, und einem oder mehreren Zugangs-Privileg(ien) zu mindestens einer der Sites; Definieren von mindestens einer Child Site und mindestens einer Parent Site, wobei die Parent Site Zugang zur Child Site hat und die Child Site beschränkten Zugang zur Parent Site hat; und Anzeigen einer Hierarchie der Sites des Sicherheitssystems, wobei die Sites gemäß dem einen oder den mehreren Zugangs-Privileg(ien) mit anderen Sites verbunden sind.
Nicht flüchtiges computerlesbares Medium nach Anspruch 16, ferner umfassend Befehle, die, wenn sie vom Prozessor ausgeführt werden, den Prozessor veranlassen, folgende Handlungen durchzuführen: Anzeigen von mindestens einer Auswahl zum Hinzufügen einer ersten Site zur Hierarchie von Sites des Sicherheitssystems, wobei die erste Site automatisch einen Teilsatz von einem oder mehreren der Zugangs-Privilegien der verbundenen Site übernimmt.
Nicht flüchtiges computerlesbares Medium nach Anspruch 16, ferner umfassend Befehle, die, wenn sie vom Prozessor ausgeführt werden, den Prozessor veranlassen, folgende Handlungen durchzuführen: Anzeigen von mindestens einer Auswahl, um einer Gruppe mindestens ein Gruppenprivileg oder ein Zugangsrecht zuzuordnen.
Nicht flüchtiges computerlesbares Medium nach Anspruch 16, ferner umfassend Befehle, die, wenn sie vom Prozessor ausgeführt werden, den Prozessor veranlassen, folgende Handlungen durchzuführen: Anzeigen von mindestens einer Auswahl, um einen Rang einer Site oder einem Knoten zuzuordnen.
Nicht flüchtiges computerlesbares Medium nach Anspruch 16, ferner umfassend Befehle, die, wenn sie vom Prozessor ausgeführt werden, den Prozessor veranlassen, folgende Handlungen durchzuführen: Empfangen von Benutzerberechtigungsnachweisen, die der Child Site zugeordnet sind, die einem ersten Rang zugeordnet ist; und Anzeigen von mindestens einem nicht wählbaren Element zum Zuordnen von mindestens einem Gruppenprivileg oder einem Zugangsrecht zu einer Gruppe, die einem zweiten Rang zugeordnet ist.
Nicht flüchtiges computerlesbares Medium nach Anspruch 16, wobei die Hierarchie eine grafische Darstellung eines Baumes umfasst.
Knoten, umfassend einen Prozessor und einen Speicher, wobei der Knoten ferner computerausführbare Befehle, die in einem Speicher des Knotens gespeichert sind, umfasst und die, wenn sie vom Prozessor des Knotens ausgeführt werden, den Knoten veranlassen: eine erste grafische Schnittstelle für ein Sicherheitssystem, das Sites umfasst, anzuzeigen; Eingabe an der ersten grafischen Benutzerschnittstelle zu empfangen, um eine Site als eine Child Site zu einer Parent Site hinzuzufügen, wobei der Parent Site eine oder mehrere Einstellung(en) zugeordnet ist/sind; eine oder mehrere der Einstellungen von der Parent Site der Child Site zuzuordnen; und den Zugang zum Ändern von einer oder mehreren der Einstellungen der Parent Site von einer grafischen Benutzerschnittstelle aus, auf die durch die Child Site zugegriffen wird, zu beschränken.
Knoten nach Anspruch 22, wobei der Knoten Teil der Child Site ist.
Knoten nach Anspruch 23, wobei die computerausführbaren Befehle, wenn sie vom Prozessor ausgeführt werden, den Knoten dazu veranlassen, die eine oder mehreren Einstellung(en) mit der Parent Site zu synchronisieren.
Knoten nach Anspruch 23, wobei die erste grafische Benutzerschnittstelle eine grafische Darstellung einer Netzwerk-Topologie umfasst, einschließlich mindestens des Knotens, der der Child Site zugeordnet ist, und eines zweiten Knotens, der der Parent Site zugeordnet ist.
Knoten nach Anspruch 23, wobei die Child Site konfiguriert ist, um Mitgliedschaftsinformationen der Child Site unabhängig von der Parent Site zu pflegen.
Knoten nach Anspruch 26, wobei die Mitgliedschaftsinformationen Benutzerberechtigungsnachweise, Rang und Privilegien, die mindestens einem Benutzer zugeordnet sind, umfassen.
Knoten nach Anspruch 26, wobei der Knoten und mindestens ein anderer Knoten Teil der Child Site sind und wobei jeder der Knoten und der mindestens eine andere Knoten konfiguriert sind, um: mindestens eine oder mehrere Einstellung(en) für die Child Site zu speichern; und die eine oder mehreren Einstellung(en) mit den anderen des Knotens oder des mindestens einen anderen Knotens zu synchronisieren.
Knoten nach Anspruch 22, wobei mindestens eine der Child Sites oder der Parent Sites konfiguriert ist, Benutzerberechtigungsnachweise mit einem externen Dienst zu synchronisieren.
Knoten nach Anspruch 22, wobei die computerausführbaren Befehle, wenn sie vom Prozessor ausgeführt werden, den Knoten ferner dazu veranlassen, mindestens eine Ansicht über ein Kamerabild mit der Parent Site zu teilen.
Knoten nach Anspruch 22, wobei die computerausführbaren Befehle, wenn sie vom Prozessor ausgeführt werden, den Knoten dazu veranlassen, Videodaten durch einen anderen Knoten zur Parent Site zu streamen.
Knoten nach Anspruch 22, wobei die computerausführbaren Befehle, wenn sie vom Prozessor ausgeführt werden, den Knoten ferner dazu veranlassen, Systemereignis- und Warnungsinformationen in Echtzeit mit der Parent Site zu teilen.
Knoten nach Anspruch 22, wobei der Knoten eine Client-Vorrichtung umfasst.
Knoten nach Anspruch 22, wobei die erste grafische Benutzerschnittstelle und die zweite grafische Benutzerschnittstelle von der Parent Site erzeugt werden.