DE60223386T2

DE60223386T2 - Verfahren zur überwaltung eines netzes mit einer netzübergangseinrichtung zwischen zwei havi-netzwerken

Info

Publication number: DE60223386T2
Application number: DE60223386T
Authority: DE
Inventors: Jean-Baptiste Henry
Original assignee: Thomson Licensing SAS
Current assignee: Thomson Licensing SAS
Priority date: 2001-08-22
Filing date: 2002-08-20
Publication date: 2008-08-28
Anticipated expiration: 2022-08-21
Also published as: WO2003019863A3; CN100353715C; JP4304066B2; US20040267915A1; AU2002331164A1; KR100917287B1; EP1419619A2; EP1286502A1; KR20040028994A; MXPA04001614A; JP2005501476A; ES2295402T3; WO2003019863A2; DE60223386D1; CN1545782A; EP1419619B1

Description

Die Spezifikation für Heim-Audio-Video-Interoperabilität (HAVi) wurde von mehreren Unterhaltungselektronikfirmen entwickelt, um das Verbinden von Audio-Video-Einrichtungen in einer Heimumgebung unter Verwendung serieller Bustechnologie gemäß IEEE 1394 zu ermöglichen. Die derzeitige Spezifikation (Versionen 1.1, erhältlich von HAVi, Inc., 2694 Bishop Drive, Suite 275, San Ramon, CA 94583, USA) wurde nicht dafür ausgelegt, das Prinzip der Überbrückung mehrerer HAVi-Netzwerke zu enthalten.
Andere Schriften, auf die im folgenden Bezug genommen wird, sind der Standard IEEE 1394-2000 für einen seriellen Bus (erhältlich von IEEE), sowie IEC 61883.1, wodurch eine digitale Schnittstelle für Audio- und Videoeinrichtungen unter Verwendung des Standards IEEE 1394 spezifiziert wird. Die Schrift IEC 61883.1 ist von der International Electrotechnical Commission erhältlich.
Die Schrift EP1058422 mit dem Titel "methods for bridging a HAVi sub-network and a UPnP sub-network and device for implementing said methods" beschreibt die Überbrückung zweier verschiedener Subnetzwerke.
Die Schrift WO01/19032 mit dem Titel "clustered networked devices" betrifft virtuelle 1394-flugs zum Abbilden IEEE 1394 auf drahtlos und ist eng mit den Schichten niedriger Ebene verknüpft.
Ein Verfahren zur Überbrückung zweier HAVi-Netzwerke basiert auf einem Ansatz des Software-Element-Proxy. 8 ist ein Beispiel für ein Netzwerk, das durch zwei durch eine Brückeneinrichtung verbundene HAVi-Netzwerke gebildet wird. Einrichtungen und Subeinrichtungen oder Funktionen werden durch Softwareelemente repräsentiert, die als DCM (Device Control Modules) bzw. FCM (Functional Component Modules) bezeichnet werden.
Der HAVi-Einrichtungsentdeckungsprozeß basiert auf "GUID"-Erkennung auf dem IEEE-1394-Bus. GUID steht für globale eindeutige Kennung. Eine GUID identifiziert eindeutig eine IEEE-1394-Einrichtung.
Die Einrichtungen auf einer Seite der Brücke werden von Einrichtungen auf der anderen Seite nicht erkannt, weil sie auf der Ebene von IEEE 1394 nicht sichtbar sind. Ein Controller auf einer Seite wird nicht in der Lage sein, ein Ziel auf der anderen Seite zu benutzen. Die Brückeneinrichtung konstruiert Repräsentationen der DCM und FCM einer Seite, um sie als DCM und FCM auf der anderen Seite zu exponieren, als Proxy-Elemente des realen Softwareelements, das sie repräsentieren.
In 8 werden reale DCM und FCM mit ihrer SEID (Software Element-ID) repräsentiert. Die SEID ist eine Kombination der GUID (ein Beispiel ist bei jeder Einrichtung unten angegeben) und einer eindeutigen Nummer im Innern dieser Einrichtung.
Diese DCM und FCM werden auf der anderen Seite der Brücke durch Proxy-SE repräsentiert. Sie sind mit gestrichelten Linien gezeigt, um sie von realen SE zu unterscheiden. Für jedes reale DCM und FCM gibt es ein Proxy-SE. Eine steuernde Anwendung kann reale Zieleinrichtungen hinter der Brücke durch ihre Proxy-SE steuern.
Um einen Strom zu konstruieren, verwendet eine HAVi-Anwendung ein lokales Softwareelement der Hosteinrichtung der Anwendung, das als der Streammanager bezeichnet wird. Bestimmte Parameter, die durch die Anwendung dem Streammanager gegeben werden, sind Datenstrukturen des Typs "FcmPlug", und zwar eine für das Senken-FCM und/oder eine für das Quellen-FCM (für einen Punkt-zu-Punkt- oder einen Broadcast-Strom entweder beide oder jeweils nur eine). Dieser Parameter "FcmPlug" ist eine Struktur, die den Parameter "Targetld" enthält, der die GUID der Zieleinrichtung enthält (wobei die reale Einrichtung die durch dieses FCM repräsentierte Funktion enthält).
Das Problem besteht darin, daß der Streammanager nach dem Protokoll IEC 61883.1 diese GUID verwendet, um die IEEE-1394-Verbindung herzustellen. Wenn sich die Zieleinrichtung der Quelle oder der Senke (oder von beidem) hinter der Brücke befindet, kann der Streammanager diese GUID nicht sehen und somit die Verbindung nicht herstellen.
Das Ziel der Erfindung ist ein Verfahren zur Verwaltung eines Netzwerks mit einer Brückeneinrichtung (AB bzw. BC), wobei die Brückeneinrichtung ein mit einem ersten HAVi-Cluster (A bzw. B) verbundenes erstes Portal und ein mit einem zweiten Cluster (B bzw. C) verbundenes zweites Portal umfaßt, gekennzeichnet durch die folgenden Schritte:
jedes Portal repräsentiert DCM-Softwareelemente und FCM-Softwareelemente, die auf dem Cluster des Portals vorliegen, durch Proxy-DCM-Softwareelemente und Proxy-FCM-Softwareelemente, wobei jedes Proxy-Softwareelement auf dem Cluster des Portals unter Verwendung einer Softwareelementkennung (SEID) auf der Basis der globalen eindeutigen Kennung (GUID) des Portals, das die Softwareelemente umfaßt, repräsentiert ist;
in jeder Brückeneinrichtung wird eine Tabelle einer Korrespondenz zwischen Softwareelementkennungen von Proxy-Softwareelementen und den von ihnen repräsentierten Softwareelementen unterhalten, wobei die TargetID-Datenstruktur eines Proxy-FCM- bzw. Proxy-DCM-Softwareelements die globale eindeutige Kennung des dieses Proxy-FCM- bzw. Proxy-DCM-Softwarelement enthaltenden Portals umfaßt.
Gemäß einer spezifischen Ausführungsform gibt ein an ein Proxy-FCM-Softwareelement gestellter Funktionsaufruf Fcm::GetDcmSeid die Softwareelementkennung des das Proxy-FCM enthaltenden Proxy-DCM zurück.
Gemäß einer spezifischen Ausführungsform umfaßt eine HUID-Datenstruktur eines Proxy-DCM- oder FCM-Softwareelements eine globale eindeutige Kennung des dieses Proxy-DCM- oder -FCM-Softwareelement enthaltenden Portals.
Gemäß einer spezifischen Ausführungsform gibt ein an ein Proxy-DCM-Softwareelement gestellter Funktionsaufruf Fcm::GetFcmSeidList die Softwareelementkennungen des in dem Proxy-DCM enthaltenen Proxy-FCM zurück.
Gemäß einer spezifischen Ausführungsform geben an Proxy-FCM- oder -DCM-Softwareelemente gestellte Funktionsaufrufe Fcm::GetHuid oder Dcm::GetHuit die jeweilige durch die Brücke bereitgestellte Proxy-HUID zurück.
Gemäß einer spezifischen Ausführungsform umfaßt das Verfahren den Schritt, daß die Brücke einen Funktionsaufruf für eine Anforderung an ein DCM-Softwareelement, interne Verbindungen von einem Ursprungscluster, auf dem das DCM-Softwareelement durch ein Proxy-DCM repräsentiert wird, zu einem Zielcluster herzustellen, weiterleitet, wobei die Brücke die auf dem Ursprungscluster gültigen Softwareelementkennungen, die in dem Funktionsaufruf eingeschlossen sind, unter Verwendung der Korrespondenztabelle in auf dem Zielcluster gültige Softwareelementkennungen umändert.
Gemäß einer spezifischen Ausführungsform werden die Proxy-DCM und Proxy-FCM als DCM_NON61883 bzw. FCM_NON61883 deklariert.
Gemäß einer spezifischen Ausführungsform umfaßt das Herstellen eines Stroms durch ein Streammanagers-Softwareelement die folgenden Schritte:

– Senden eines Funktionsaufrufs StreamManager::FlowTo zu einem Streammanager auf dem ersten Cluster, wobei der Funktionsaufruf das Herstellen einer Verbindung zwischen einem ersten FCM-Softwareelement auf dem ersten Cluster und einem zweiten FCM-Softwareelement auf einem anderen Cluster anfordert;
– Veranlassen, daß das Streammanagers-Softwareelement eine Verbindung zwischen dem ersten FCM-Softwareelement und dem Proxy-FCM des zweiten FCM-Softwareelements aufbaut;
– Anweisen eines zweiten Streammanagers, der Teil der Brücke ist, eine Verbindung auf dem zweiten Cluster zwischen dem das erste FCM-Softwareelement repräsentierenden Proxy-FCM-Softwareelement und dem zweiten Softwareelement oder einem Proxy davon aufzubauen.

Gemäß einer spezifischen Ausführungsform wird die Anweisung des zweiten Streammanagers dadurch getriggert, daß die Brücke eine Nachricht auf dem ersten Cluster empfängt, die angibt, daß die Verbindung durch den ersten Streammanager abgeschlossen ist.
Gemäß einer spezifischen Ausführungsform wird das Weiterleiten des Funktionsaufrufs für die interne Verbindung des DCM-Softwareelements durch die Brücke dadurch getriggert, daß die Brücke eine Nachricht auf dem ersten Cluster empfängt, die angibt, daß die Verbindung durch den ersten Streammanager abgeschlossen ist.
Gemäß einer spezifischen Ausführungsform wird der Abschluß der Herstellung einer Verbindung auf einem Cluster durch ein Ereignis ConnectionAdded angegeben, wobei dieses Ereignis nicht von einem Cluster zum anderen weitergeleitet wird.
Gemäß einer spezifischen Ausführungsform umfaßt das Verfahren die folgenden Schritte:

– Senden einer Nachricht zum Abwerfen einer über die Brücke hergestellten Verbindung zu einem dritten Streammanager auf einem der Cluster, wobei der dritte Streammanager zuvor als die abzuwerfende Verbindung haltend identifiziert wurde;
– Veranlassen, daß der dritte Streammanager die auf seinem lokalen Cluster hergestellte entsprechende Verbindung abwirft;
– Veranlassen, daß die Brücke eine Verbindungskennung in der ursprünglichen Abwurfnachricht unter Verwendung ihrer Korrespondenztabelle aktualisiert;
– Veranlassen, daß die Brücke die Abwurfnachricht zu einem vierten Streammanager auf dem anderen Cluster weiterleitet, wobei der Streammanager durch die Aktualisierung identifiziert wurde.

Gemäß einer spezifischen Ausführungsform umfaßt das Verfahren die folgenden Schritte:

– Senden einer Nachricht zum Abwerfen einer über die Brücke hergestellten Verbindung von einem Cluster zu einem dritten Streammanager (53) in einem Portal, wobei der dritte Streammanager (53) zuvor als die abzuwerfende Verbindung haltend identifiziert wurde;
– Veranlassen, daß die Brücke eine Verbindungskennung in der ursprünglichen Abwurfnachricht unter Verwendung ihrer Korrespondenztabelle aktualisiert;
– Bewirken, daß die Brücke (BC) die Abwurfnachricht zu einem vierten Streammanager auf dem anderen Cluster (C) weiterleitet, wobei der Streammanager durch die Aktualisierung identifiziert wurde;
– Bewirken, daß der vierte Streammanager das Abwerfen der Verbindung auf beiden Clustern triggert.

Die Erfindung betrifft außerdem eine Brückeneinrichtung zum Verbinden eines ersten Einrichtungsclusters mit einem zweiten Einrichtungscluster, wobei die Einrichtung ein erstes Portal zur Verbindung mit dem ersten Cluster und ein zweites Portal zur Verbindung mit dem zweiten Cluster umfaßt, wobei die Brücke dafür ausgelegt ist, Elemente auf einem Cluster durch auf einem anderen Cluster sichtbare Proxy-Elemente zu repräsentieren, dadurch gekennzeichnet, daß sie ferner Mittel zum Erzeugen von Datenstrukturen umfaßt, die die Proxy-Elemente beschreibend, wobei die Datenstrukturen mindestens eine Kennung der Brücke oder des Portals umfassen, die eine Kennung der ursprünglichen Datenstruktur des durch das Proxy-Element repräsentierten ursprünglichen Elements ersetzt.
Gemäß einer Ausführungsform der Erfindung umfaßt die Brückeneinrichtung ferner Mittel zum Analysieren von Anforderungen von Datenstrukturen, die von einem Element auf dem ersten Cluster empfangen werden und an ein Element des zweiten Clusters adressiert sind, wobei das Element des zweiten Clusters durch ein Proxy-Element auf dem ersten Cluster repräsentiert wird, und zum selektiven Weiterleiten einer Anforderung zu dem Element des zweiten Clusters oder zum Reagieren auf die Anforderung anstelle des Elements des zweiten Clusters, wobei das selektive Weiterleiten oder Reagieren als Reaktion auf einen in der angeforderten Datenstruktur anwesenden Elementkennungstyp erfolgt.
Gemäß einer Ausführungsform der Erfindung umfaßt die Brückeneinrichtung ferner Mittel zum Detektieren einer neuen Verbindung zwischen einem Element einer mit einem Cluster verbundenen Einrichtung und einem auf dem einen Cluster sichtbaren Proxy-Element und zum Triggern des Herstellens einer Verbindung auf einem anderen Cluster auf dem Weg zu dem Element, das durch das Proxy-Element repräsentiert wird, als Reaktion auf die Detektion.
Weitere Eigenschaften und Vorteile der Erfindung werden durch die Beschreibung einer nicht einschränkenden Ausführungsform der Erfindung, erläutert mit Hilfe der beigefügten Figuren, ersichtlich werden. Es zeigen:
1 bis 3 Blockschaltbilder eines selben Kommunikationsnetzes, das zwei Brücken umfaßt, in verschiedenen Phasen der Herstellung eines Stroms zwischen zwei Einrichtungen.
4 bis 7 Blockschaltbilder des Netzes von 1 bis 3 in verschiedenen Phasen während des Schließens eines Stroms.
8, die bereits beschrieben wurde, ein Beispiel für zwei durch eine Brückeneinrichtung verbundene HAVi-Netzwerke.
Ein HAVi-Netzwerk kann vier verschiedene Arten von Einrichtungen umfassen. Diese Arten unterscheiden sich in bezug auf ihre Fähigkeit zum Ausführen der Softwareelemente der HAVi-Architektur: Voll-Audio/Video-Einrichtung (FAV), Zwischen-Audio/Video-Einrichtungen (IAV), Basis-Audio/Video-Einrichtungen (BAV) und Legacy-Audio/Video-Einrichtungen (LAV).
Jede Einrichtung wird durch ein als DCM (Device Control Module) bezeichnetes Softwareelement repräsentiert. Jedes DCM kann null oder mehr FCM (Functional Component Modules) enthalten. Zum Beispiel kann eine VCR-Einrichtung ein Tuner-FCM und ein eigentliches VCR-VCM enthalten. Die HAVi-Spezifikation definiert eine Anzahl von API (Application Programmable Interfaces) für Softwareelemente.
Kurz gefaßt enthält eine FAV-Einrichtung einen vollständigen Satz HAVI-Softwareelemente, während ein LAV keine aufweist. FAV und IAV können ihre eigenen DCM ausführen, während BAV und LAV dies nicht können; DCM und FCM für diese letzteren Einrichtungen müssen von FAV- oder IAV-Einrichtungen ausgeführt werden. Softwareelemente registrieren sich bei einem anderen lokalen Element ihrer Einrichtung, das als eine Registrierdatenbank bezeichnet wird. Die Kenntnis der auf dem Cluster verfügbaren Ressourcen kann durch Abfragen der verschiedenen Registrierdatenbanken auf dem Cluster erzielt werden.
Physische Einrichtungen werden wie in der Einführung erwähnt durch die globale eindeutige Kennung oder GUID identifiziert. Softwareelemente werden durch eine Softwareelementkennung oder SEID referenziert, die die GUID der Hosteinrichtung des Softwareelements sowie eine innerhalb der Hosteinrichtung eindeutige zusätzliche Kennung umfaßt.
Die Stromherstellung wird durch ein als "Streammanager" (SM) bezeichnetes Softwareelement ausgeführt. Der Streammanager reagiert auf den Empfang eines Funktionsaufrufs zum Beispiel von einer Anwendung. Er stellt eine Verbindung des Stromtyps, zum Beispiel des Typs IEC 61883.1, her, indem zuerst intern die Quellen- und Senkeneinrichtungen konfiguriert werden (wobei Stromtypen und Übertragungsformate gesetzt und Plugs von Funktionskomponenten (FCM) und Einrichtungen (DCM) angeschlossen werden), die IEEE-1394-Kanal- und -Bandbreitenressourcen reserviert und die IEC-61883.1-Plug-Register aktualisiert werden.
Der Lesbarkeit der Figuren halber werden in 1 bis 6 nur DCM und FCM und andere Softwareelemente gezeigt, die in bezug auf den Stromaufbau nützlich sind.
Das Netzwerk von 1 umfaßt drei durch zwei Brücken AB und BC verbundene IEEE-1394-Busse A, B und C. Die drei Busse und die mit den Bussen verbundenen Einrichtungen bilden drei distinkte HAVi-Cluster. In der Figur ist die GUID jeder Einrichtung angegeben. Im folgenden wird jede Einrichtung durch ihre GUID referenziert. Wenn die GUID eine Einrichtung "X" ist, ist die Referenz für ein DCM in der Einrichtung dann "X1" und die eines FCM "X2". Ein Streammanager hat dann die Referenz "X3". Im Fall des vorliegenden Beispiels gibt es, da nur DCM und FCM, die am Stromaufbau beteiligt sind, gezeigt sind, maximal ein gezeigtes DCM und ein gezeigtes FCM für jede Einrichtung. Die Referenz für Proxies ist dann die der von ihnen repräsentierten Softwareelemente, wozu ein oder mehrere Apostrophen hinzugefügt werden, um die Abgesetztheit des Proxys im Vergleich zu dem ursprünglichen Softwareelements anzuzeigen. Wenn zum Beispiel die Referenz eines Softwareelements X ist, ist das Proxy der mit demselben Bus verbundenen Brücke X' und das der nächsten Brücke X''. Proxy-Softwareelemente werden auch als Kästen mit gestrichelten Linien gezeichnet, um sie von den ursprünglichen Softwareelementen zu unterscheiden.
Die Notation für eine SEID soll ('GUID', n) sein, wobei 'GUID' die GUID der Hosteinrichtung ist und n die zusätzliche Kennung innerhalb des Hosts repräsentiert.
Bus A ist mit einem BAV-Tuner 1 (GUID = 1) verbunden, der mit einer (nicht referenzierten) Antenne verbunden ist. Die DCM- bzw. FCM-Softwareelemente 21 bzw. 22, die den Tuner repräsentieren, werden durch eine FAV-Einrichtung 2 gehostet, die auch mit dem Bus A verbunden ist. Außerdem ist eine Brücke AB mit dem Bus A verbunden. Das Portal der Brücke auf der Seite des Busses A wird mit 3 referenziert. Es umfaßt einen Streammanager 33 sowie zwei Proxy-DCM und -FCM 81'' und 82'', die ein DCM und ein FCM der Einrichtung 8 auf dem Bus C repräsentieren.
Bus B ist mit Portalen der Brücken AB und BC (referenziert mit 4 bzw. 5) sowie mit einer IAV- oder FAV-Einrichtung 6 verbunden, die eine Anwendung, zum Beispiel eine Benutzeroberfläche, umfaßt. Das Portal 4 umfaßt die Proxy-Einrichtungen DCM 21' und FCM 22', die das Tuner-DCM und -FCM der Einrichtung 2 repräsentieren. Das Portal 4 enthält auch einen Streammanager 43, da es wie sein Peer-Portal an der Herstellung oder Aufhebung von Strömen teilnehmen muß. Ähnlich enthält das Portal 5 einen Streammanager 53 sowie ein DCM 81' und FCM 82'.
Bus C ist mit dem Portal 7 der Brücke BC verbunden und umfaßt den Streammanager 73 sowie Proxies DCM 21'' und FCM 22''. Darüber hinaus ist eine BAV-VCR-Einrichtung mit Bus C verbunden und umfaßt eine VCR-Funktion 94. Die FAV-Einrichtung 8 hostet das DCM und FCM für die BAV-Einrichtung 9. Eine IAV- oder FAV-Einrichtung 10 hostet eine Anwendung, zum Beispiel eine Benutzeroberfläche, und einen Streammanager 103.
Die Brücken AB und BC umfassen Speicher zum Aufbau einer Tabelle, worin die Brücken die SEID- und/oder GUID-Kennungen der Softwarelemente führen, für die es Proxies darstellt.
Referenzen in 1 bis 6 sind für dieselben Elemente gleich.
Es wird nun das Verfahren zum Aufbau eines Stroms beschrieben.
Als ein Beispiel möchte die Anwendung der Einrichtung 10 einen Strom von dem Tuner 1 zu dem VCR 9 aufbauen, um eine Aufzeichnungsoperation auszuführen. Diese Anwendung weiß über den VCR 9 durch das FCM 21 und weiß über den Tuner 1 durch das Proxy-FCM 22''. Die SEID-Kennungen dieser beiden FCM sind durch eine entsprechende an die Registrierdatenbank der Einrichtung 10 gestellte Anfrage verfügbar.
Die Anwendung ruft die Funktion 'StreamManager::FlowTo' des Streammanager 103 auf, um die Herstellung des Stroms anzufordern. Parameter dieses Aufrufs 'FlowTo' sind hauptsächlich die Datenstruktur 'FcmPlug' der Quelle und der Senke. Diese Datenstrukturen umfassen ihrerseits eine als 'TargetID' bezeichnete Datenstruktur, die die GUID der Einrichtungen enthält, die die FCM hosten (oder ihre Proxies, wie später zu sehen sein wird).
Wie in 2 gezeigt, fordert der Streammanager 103 von dem FCM 22'' die SEID-Kennung seines assoziierten DCM über den Aufruf 'Fcm::GetDcmSeid' an. Das Proxy-FCM 22'' leitet diese Anforderung nicht zu dem realen FCM 22 weiter, weil die Antwort dann die SEID des DCM 21 wäre. Das Proxy-FCM 22'' reagiert auf diese Anforderung, indem es die SEID des DCM 21'' (hier SEID (7, 10)) zurückgibt. Dieser Aufruf wird auch zu dem FCM 82 gesendet, das die SEID des DCM 82 zurücksendet.
Das Portal 7 fängt somit den Aufruf 'FCM::GetDcmSeid' auf der Ebene des Proxy-FCM ab. Es leitet ihn nicht direkt zu dem realen FCM weiter. Wie später zu sehen sein wird, stellt der Streammanager 103 einen Strom auf dem Bus C zwischen dem FCM 82 und dem Proxy-FCM 22'' her, wobei er denkt, daß der Strom zwischen dem FCM 82 und FCM 22 hergestellt wird. Wäre die SEID des realen DCM 21 als Antwort auf den Funktionsaufruf 'FCM::GetDcmSeid' zurückgegeben worden, so hätte der Streammanager 103, der sich auf einem anderen Cluster befindet, in jedem Fall diesen nicht verarbeiten können. Funktionsaufrufe wie etwa 'FCM::GetDcmSeid', die Kennungen zur Verwendung durch das Aufrufen des Softwareelements zurückgeben, werden somit durch das entsprechende Proxy abgefangen und die Kennung des realen Softwareelements wird durch die seines Proxys ersetzt.
Die eindeutige HAVi-Kennung (HUID) dient zum eindeutigen Identifizieren eines DCM, FCM oder Anwendungsmoduls. Die HUID-Kennung umfaßt die TargetID (modifizerit durch die Brücke) und eine Anzahl anderer Kennungen: 'InterfaceId', 'VendorId', 'n1Uniqueness', 'n2Assigner'. Die 'InterfaceId' und 'VendorID' des Proxys sind dieselben wie die der ursprünglichen Einrichtung oder funktionalen Komponente, die durch das Proxy repräsentiert wird. 'n1Uniqueness' wird auf TRUE gesetzt und 'n2Assigner' auf NONE für das DCM und auf NONE oder DCM für das FCM.
Da die HUID oder TargetID eines Proxys im Vergleich zu der HUID oder TargetID der durch das Proxy repräsentierten Einrichtung durch die Brücke geändert wird, sollten zusätzlich zu der Nachricht Fcm::GetDcmSeid auch die folgenden Nachrichten nicht weitergeleitet, sondern von der Brücke beantwortet werden:

Dcm::GetHuid
Dcm::GetFcmSeidList
Fcm::GetHuid.

Wie in 3 gezeigt, produziert der Streammanager 103, um die internen Verbindungen innerhalb der Einrichtungen herzustellen, einen Aufruf 'Dcm::Connect' auf dem DCM 21'' und auf dem DCM 81. Das DCM 81 stellt die interne Verbindung in dem BAV-VCR zwischen der aufzeichnenden Subeinheit und der Busverbindung her. Das DCM 21'' leitet die Anforderung zu dem Streammanager 53 weiter, der der Streammanager des anderen Portals seiner Brücke ist, weil es weiß, daß diese Art von Aufruf zu dem realen DCM weitergeleitet werden muß. Tatsächlich weist die Funktion 'DCM::Connect' ein DCM an, die internen Verbindungen einer Einrichtung auf demselben Cluster wie das DCM herzustellen.
Gemäß der HAVi-Spezifikation ist die Funktion 'Dcm::Connect' für die Verwendung ausschließlich durch einen Streammanager reserviert, und aus diesem Grund weist das Proxy-DCM 21'' gemäß der vorliegenden Ausführungsform durch private Brückensoftware den Streammanager 53 an, diese Aufgabe auszuführen, statt diesen Funktionsaufruf direkt selbst durchzuführen. Man beachte, daß das DCM 21'' tatsächlich das Proxy des DCM 21' und nicht direkt das DCM 21 ist.
Der Streammanager 53 führt den Aufruf für das Proxy-DCM 21' durch, daß ihn auf ähnliche Weise wie gerade beschrieben zu dem Streammanager 33 weiterleitet, wobei letzterer letztendlich das reale DCM 21 aufruft. Das DCM 21 stellt dann wie in 3 gezeigt die interne Verbindung in dem BAV-Tuner 1 her.
Der Aufruf DCM::Connect enthält die SEID-Kennung des aufrufenden Softwareelements, die anfänglich die SEID des Streammanagers 103 ist. Jedesmal, wenn ein Streammanager den Aufruf DCM::Connect weiterleitet, ersetzt er die Aufruferkennung mit seiner eigenen SEID.
Der Aufruf DCM::Connect ist ein Funktionsaufruf, der das reale DCM 21 anweist, eine Aufgabe auszuführen. Eine solche Art von Nachricht wird durch die Brücke BC und die Brücke AB zu dem realen DCM weitergeleitet, wobei sichergestellt wird, daß alle relevanten Parameter in bezug auf Softwareelementidentifikation (z. B. Aufrufer-SEID-Kennung) so modifiziert werden, daß sie auf den Clustern gültig sind, die die Nachricht auf ihrem Weg zu dem Zielsoftwareelement durchläuft. Wenn eine Brücke eine Nachricht von einer Entität auf einem Cluster empfängt, leitet sie anders ausgedrückt die Nachricht nicht systematisch so wie sie ist weiter, sondern analysiert die Beschaffenheit der Nachricht, um zu bestimmen, ob Weiterleitung erlaubt ist oder nicht. Wenn es erlaubt ist, müssen möglicherweise bestimmte Parameter in der Nachricht modifiziert werden, um den Anforderungen auf dem neuen Cluster zu genügen. Wenn die Weiterleitung nicht erlaubt ist – dies ist der Fall, wenn eine Informationsanforderung in bezug auf Identifikation des Softwareelements gestellt wird – reagiert die Brücke direkt auf das Aufrufer-Softwareelement, da sie bereits eine gültige Antwort auf diese Anforderung besitzt.
Die Streammanager haben nun durch die DCM die Erzeugung der erforderlichen internen Verbindungen in den Quellen- und Senkeneinrichtungen getriggert (die gemäß dem vorliegenden Beispiel Einrichtungen sind, die diese DCM nicht hosten).
Der Streammanager 103 muß nun die IEEE-1394-Verbindung herstellen. Der Prozeß ist in 4 gezeigt. Der Streammanager 103 stellt diese Verbindung nur für Bus C her, obwohl er im Glauben gelassen wird, daß er diese Verbindung über das gesamte Netzwerk herstellt. Der Streammanager 103 ruft die GUIDs der Quellen- und Senkeneinrichtungen über die oben erwähnten FCM Plug- Datenstrukturen ab, die die TargetIds enthalten, die die GUIDs enthalten.
Die GUID der TargetId des FCM 22'' ist nicht die reale GUID der Tuner-Einrichtung 1, sondern der GUID der Einrichtung, die das Proxy-FCM 22'' hostet (d. h. GUID 7), da der Streammanager nicht direkt eine IEEE-1394-Verbindung über die beiden Brücken herstellen kann. Das Proxy-FCM 22'' besitzt somit sein eigenes TargetId-Attribut: diese TargetId ist nicht eine Kopie der TargetId des realen FCM 22.
Gemäß HAVi werden DCM und FCM Typen zugewiesen. In der Regel kann ein DCM oder ein FCM in der Lage sein, Ströme gemäß dem Standard IEC 61883 zu handhaben oder nicht. Dieser Standard definiert den Transport isochroner Ströme über IEEE 1394. Der Typ eines DCM kann somit DCM_61883 (bei Kompatibilität mit IEC 61883) oder DCM_NON61883 sein. Die Notationen sind für FCM ähnlich. Weiterhin sind gemäß der HAVi-Spezifikation TargetIds in dem Netzwerk einzigartig und es kann in jeder Einrichtung nur ein DCM des Typs DCM_61883 geben.
Der Typ des DCM 21'' – oder eines anderen Proxy-DCM – kann nicht DCM_61883 sein. Da wie gerade erläutert wurde die GUID dieses DCM 21'' dieselbe wie die seiner Hosteinrichtung ist (GUID 7), wäre die TargetId des DCM 21'' tatsächlich identisch mit der TargetId des DCM des Portals selbst (wobei dieses DCM in den Figuren nicht gezeigt ist).
Gemäß der vorliegenden Ausführungsform werden DCM (bzw. FCM) als IEC 61883 nicht genügend deklariert. In diesem Fall erlaubt HAVi, daß zusätzliche Parameter in der TargetId variieren, wodurch die Erzeugung distinkter TargetIds für die Proxy-Softwareelemente möglich wird.
Eine andere Lösung wäre die Berücksichtigung anderer DCM und FCM-Typen, die für die Proxy-Elemente spezifisch sind (zum Beispiel die Typen 'DCM_PROXY' und 'FCM_PROXY'), diese Lösung würde aber eine Modifikation der HAVi-Spezifikation erfordern.
Der Streammanager 103 baut eine IEEE-1394-Verbindung zwischen der Einrichtung 7 und der Einrichtung 9 auf. Sobald dies geschehen ist und der Streammanager 103 glaubt, daß der Strom ordnungsgemäß hergestellt worden ist, sendet er ein Ereignis ConnectionAdded auf seinem Cluster rund.
Der Streammanager 73 empfängt dieses ConnectionAdded-Ereignis. Dann ruft er die Funktion StreamManager::GetConnection auf der API des Streammanagers 103 auf, um weitere Informationen über diesen Strom abzurufen (insbesondere das Quellen-FcmPlug und Senken-FcmPlug). Dann kann er diese Informationen zu dem Streammanager 53 seines Peer-Portals weiterleiten. Der Streammanager 53 prüft dann die Quelle und Senke dieser Verbindung und deduziert durch interne Mittel, daß er eine IEEE-1394-Verbindung zwischen dem FCM 22' und dem FCM 82' aufbauen muß; die Brückeneinrichtung behält Kenntnis der Äquivalenz zwischen Proxy- und realen DCM/FCM und weiß somit aus den durch den Streammanager 73 bereitgestellten Informationen, zwischen welchen FCM eine IEEE-1394-Verbindung herzustellen ist. In diesem Beispiel sind für die Brückeneinrichtung BC die realen DCM DCM 81 auf der Seite der GUID 7 und DCM 21' auf der Seite der GUID 5 (obwohl dies ein Proxy-DCM ist, ist es, soweit es die Brücke BC betrifft, als real angesehen), und die Proxy-DCM sind das DCM 21'' auf der Seite der GUID 7 und das DCM 81' auf der Seite der GUID 5. Darüber hinaus baut er die interne Verbindung innerhalb der Brückeneinrichtung auf.
Wenn dies geschieht, sendet der Streammanager 53 ein neues Ereignis 'ConnectionAdded' auf seinem HAVi-Cluster rund. Dieses neue Ereignis ist nicht eine Kopie des durch den Streammanager 103 rundgesendeten, da aufgrund der Clusteränderung mehrere Parameter geändert werden müssen.
Mit Bezug auf die HAVi-Spezifikation ist das 'mgr'-Feld des 'ConnectionId'-Parameters, wodurch der Streammanager angezeigt wird, der die Verbindung erzeugt hat, nun die SEID des Streammanagers 53 und die Felder in der 'Connection'-Struktur wurden gemäß diesem Cluster geändert (der 'Channel' ist nicht unbedingt derselbe, die 'FcmPlug'-Datenstrukturen für die Quelle und die Senke beziehen sich nicht mehr auf das FCM 22'' und das FCM 82, sondern auf das FCM 22' und FCM 82', der 'ConnectionId'-Parameter hat sich geändert und somit gilt dasgleiche für den 'owner').
Der Streammanager 43 empfängt das Ereignis, ruft die Funktion 'StreamManager::GetConnection' auf, um Informationen über die Verbindung zu erhalten, und leitet sie zu seinem benachbarten Streammanager 53 weiter, der deduziert, daß er eine IEEE-1394-Verbindung zwischen dem DCM 21 und dem DCM 82'' (selber Prozeß wie zuvor) und eine interne Verbindung innerhalb der Brücke AB herstellen muß. Als letztes sendet der Streammanager 43 ein neues 'ConnectionAdded'-Ereignis auf dem Cluster A rund.
Man beachte, daß in 4 die Abkürzung 'CMP' für "Verbindungsverwaltungsprozedur" steht. Diese Prozedur ist Teil von IEC 61883.1, und die mit CMP markierten Pfeile in 4 entsprechen Nachrichten, die auf den IEEE-1394-Bussen zur Ressourcenreservierung gesendet werden.
Wie aus den vorausgehenden Absätzen ersichtlich ist, wird die Ereignisnachricht 'ConnectionAdded' nicht direkt von einer Brückenseite zur anderen weitergeleitet. Statt dessen triggert das Ereignis auf einem Cluster die Aktionssequenz, die zu dem Daseinsgrund der Ereignisnachricht auf dem anderen Cluster führte. Anders ausgedrückt, wird die Aktionssequenz von Cluster zu Cluster propagiert (wenn es die Stromherstellung erfordert), wobei der Abschluß der Aktionssequenz auf einem Cluster die Sequenz auf dem nächsten Cluster triggert.
Es wird nun beschrieben, wie ein Strom zu beenden oder "abzuwerfen" ist.
Als ein Beispiel entscheidet sich die Anwendung auf der Einrichtung mit der GUID 6, den Strom, der zwischen den FCM 22 und 82 hergestellt wurde, abzuwerfen.
Wenn diese Anwendung den Empfang der 'ConnectionAdded'-Ereignisse zum ordnungsgemäßen Zeitpunkt abonniert hat, empfängt es die 'ConnectionId' des Stroms. Andernfalls hat sie zuvor eine Funktion 'StreamManager::GetGlobalConnectionMap' ausgeführt, durch die sie von der Existenz der Verbindung erfahren hat.
Bei der 'ConnectionId'-Datenstruktur für diese konkrete Verbindung ist ein 'mgr'-Feld gleich 53, weil sie auf diesem Cluster des HAVi-Netzwerks durch den Streammanager 53 aufgebaut wurde.
Die 'ConnectionId'-Struktur enthält außerdem ein Feld mit dem Label 'seq', das eine durch den Streammanager 53 der Verbindung gegebene Sequenznummer angibt und dem für die Zwecke des vorliegenden Beispiels willkürlich ein Wert von "3" gegeben werden soll. Die Verbindung wird als die Verbindung (53, 3) identifiziert.
Die Anwendung führt einen Aufruf der Funktion 'StreamManager::GetConnection' an den Streammanager aus, der den Strom hält (hier Streammanager 53), um weitere Informationen über diese Verbindung (z. B. die Quelle und die Senke) zu erhalten.
Wie in 5 gezeigt, führt die Anwendung einen Aufruf'StreamManager::Drop' bei dem Streammanager 53 mit einer durch (53, 3) identifizierten 'ConnectionId' durch.
Ein normaler Streammanager würde dann 'Dcm::Disconnect'-Nachrichten zu den beiden an der Verbindung beteiligten DCM senden. Gemäß der vorliegenden Ausführungsform sendet der Streammanager solch eine Nachricht nur zu DCM, von denen er annimmt, daß sie keine Proxies sind. Wenn anders ausgedrückt der Streammanager (der die Nachricht 'StreamManager::Drop' empfangen hat) auf einer Brücke residiert, sendet er die 'Dcm::Disconnect'-Nachricht nur zu DCM, die nicht durch die Brücke emuliert werden, auf der er residiert. Nur für diese DCM weiß der Streammanager, ob sie Proxies sind oder nicht.
Wie in 6 gezeigt, sendet der Streammanager 53 eine 'Dcm::Disconnect'-Nachricht zu dem DCM 21', nicht aber zu dem DCM 82', da er durch die internen Mittel der Brücke ableiten kann, daß dieses DCM ein Proxy-DCM ist. Der Aufruf, den das Proxy 21' empfängt, wird durch das Proxy- DCM zu dem Streammanager 53 weitergeleitet, der ihn zu dem DCM 21 weiterleitet, und die interne Verbindung des BAV-Tuners 1 wird geschlossen.
Der Streammanager 53 schließt die IEEE-1394-Verbindung auf seinem Cluster und die interne Verbindung seiner Brückeneinrichtung.
Als letztes leitet der Streammanager 53 als Ersatz für die fehlende 'Dcm::Disconnect'-Nachricht die Abwurfinformationen zu dem Streammanager 73 seines Peer-Portals weiter. Der Streammanager 73 deduziert, daß sich die ConnectionID (53, 3) tatsächlich auf die ConnectionId (103, 1) bezieht, die der Streammanager 103 hält, und sendet dann einen 'StreamManager::Drop'-Aufruf zu dem Streammanager 103.
Der Streammanager 103 startet den Abwurfprozeß auf seinem Cluster, d. h. sendet eine 'Dcm::Disconnect'-Nachricht zu dem DCM 82. Das DCM 82 reagiert, indem es die interne Verbindung des BAV-VCR 9 unterbricht. Da der Streammanager 103 – der nicht ein Streammanager einer Brücke ist – ignoriert, daß das DCM 21'' ein Proxy-DCM ist, sendet er auch eine 'Dcm::Disconnect'-Nachricht zu diesem Proxy. Es ist keine Aktion von dem Proxy-DCM 21'' erforderlich, da dies bereits von dem Streammanager 53 auf dem Bus B abgewickelt wurde. Der Streammanager 103 schließt dann die IEEE-1394-Verbindung auf seinem Cluster und sendet ein 'ConnectionDropped'-Ereignis.
Parallel dazu empfing der Streammanager 43 das 'ConnectionDropped'-Ereignis von dem Streammanager 53. Er leitet es zu seinem assoziierten Brücken-Streammanager 33 weiter. Dieser deduziert die wahre ConnectionId auf seinem Cluster aus der ConnectionId (53, 3) und startet dann den Abwurfprozeß, d. h. es schließt die IEEE-1394-Verbindung auf Cluster A und sendet ein ConnectionDropped-Ereignis auf seinem Cluster (hier nicht gezeigt).
Obwohl das Beispiel von 2 bis 7 das Herstellen und Abbrechen einer Punkt-zu-Punkt-Verbindung betrifft, kann der beschriebene Prozeß leicht auf Rundsendeverbindungen (Eingang und Ausgang) und auf Overlay-Verbindungen angewandt werden.
Die automatische Wiederherstellung von Verbindungen nach einem Busrücksetzen erfolgt individuell auf jedem Cluster.
Die Reihenfolge der in dem oben beschriebenen Beispiel beschriebenen Aktionen kann unterschiedlich sein. Es werden hier einige Varianten der Ausführungsform angegeben:

• Die von einer Brücke weitergeleiteten Dcm::Connect-Aufrufe können zur selben Zeit wie die Herstellung der IEEE-1394-Verbindungen durch diese Brücke erfolgen, d. h. nicht wenn das erste Dcm::Connect durch das Proxy-DCM weitergeleitet wird (siehe 3), sondern wenn der Streammanager der Brücke das ConnectionAdded-Ereignis empfängt.
• Die von einer Brücke weitergeleiteten Dcm::Disconnect-Aufrufe können zur selben Zeit wie die IEEE-1394-Trennung durch eine Brücke erfolgen, d. h. nicht wenn das erste Dcm::Disconnect durch das Proxy-DCM weitergeleitet wird (siehe 6), sondern wenn der Streammanager der Brücke das ConnectionDropped-Ereignis empfängt (siehe 7).
• Die Dcm::Disconnect-Aufrufe des Streammanagers einer Brücke (z. B. des Streammanagers 53) können erfolgen, wenn der ursprüngliche Einleiter des Stroms (z. B. der Streammanager 103) die Dcm::Disconnect-Nachrichten auf seinem Cluster sendet, und diese Dcm::Disconnect-Nachricht wird von dem Proxy-DCM der Brücke BC (z. B. 21'') detektiert, statt daß der anscheinende Halter des Strom-Streammanagers diesen Aufruf propagiert.
• Das StreamManager::Drop kann zu dem ursprünglichen Einleiter (Streammanager 103) weitergeleitet werden, ohne daß die zwischengeschalteten Brücken Aktionen unternehmen. Der ursprüngliche Einleiter startet dann den Trennungsprozeß, dessen Ausbreitung dann dem Verbindungsprozeß ähnlich ist.

Obwohl die Erfindung im Rahmen von HAVi beschrieben wurde, können viele der charakteristischen Eigenschaften in anderen Kontexten angewendet werden.
Jede Brücke umfaßt Speicher und Schnittstellen und Verarbeitungsschaltkreise (z. B. einen Mikroprozessor), wie in der Technik bekannt ist, zum Ausführen der beschriebenen Verfahren. Diese Elemente erscheinen nicht in den Figuren.

Claims

Verfahren zur Verwaltung eines Netzwerks mit einer Brückeneinrichtung (AB bzw. BC), wobei die Brückeneinrichtung ein mit einem ersten HAVi-Cluster (A bzw. B) verbundenes erstes Portal und ein mit einem zweiten HAVi-Cluster (B bzw. C) verbundenes zweites Portal umfaßt, gekennzeichnet durch die folgenden Schritte: das erste Portal repräsentiert DCM-Softwareelemente und FCM-Softwareelemente, die auf dem zweiten Cluster vorliegen, durch Proxy-DCM-Softwareelemente und Proxy-FCM-Softwareelemente, wobei die Softwareelementkennung SEID jedes auf dem ersten Cluster repräsentierten Proxy-Softwarelements auf der Basis der globalen eindeutigen Kennung GUID des die Proxy-Softwareelemente umfassenden Portals aufgebaut wird; das zweite Portal repräsentiert DCM-Softwareelemente und FCM-Softwareelemente, die auf dem ersten Cluster vorliegen, durch Proxy-DCM-Softwareelemente und Proxy-FCM-Softwareelemente, wobei die Softwareelementkennung SEID jedes auf dem zweiten Cluster repräsentierten Proxy-Softwarelements auf der Basis der globalen eindeutigen Kennung GUID des die Proxy-Softwareelemente umfassenden Portals aufgebaut wird; in der Brückeneinrichtung wird eine Korrespondenztabelle zwischen Softwareelementkennungen von Proxy-Softwareelementen und den von ihnen repräsentierten Softwareelementen aufgebaut, wobei die TargetId-Datenstruktur eines Proxy-FCM- bzw. Proxy-DCM-Softwareelements als die globale eindeutige Kennung des dieses Proxy-FCM- bzw. Proxy-DCM- Softwarelement enthaltenden Portals umfassend aufgebaut wird.
Verfahren nach Anspruch 1, wobei eine Datenstruktur der eindeutigen HAVi-Kennung HUID eines Proxy-DCM- oder -FCM-Softwareelements als eine globale eindeutige Kennung des dieses Proxy-DCM- oder -FCM-Softwarelement enthaltenden Portals umfassend aufgebaut wird.
Verfahren nach einem der Ansprüche 1 oder 2, wobei ein erster Funktionsaufruf an ein Proxy-FCM-Softwareelement die Softwareelementkennung des das Proxy-FCM enthaltenden Proxy-DCM zurückgibt.
Verfahren nach einem der Ansprüche 1 bis 3, wobei ein zweiter Funktionsaufruf an ein Proxy-DCM-Softwareelement die Softwareelementkennungen des in dem Proxy-DCM enthaltenden Proxy-FCM zurückgibt.
Verfahren nach einem der Ansprüche 1 bis 4, wobei ein dritter Funktionsaufruf Proxy-FCM- oder -DCM-Softwareelemente die entsprechende durch die Brücke bereitgestellte eindeutige HAVi-Kennung HUID zurückgibt.
Verfahren nach einem der Ansprüche 1 bis 5 mit dem Schritt des Veranlassens, daß die Brücke einen Funktionsaufruf für eine Anforderung an ein DCM-Softwareelement, interne Verbindungen von einem Ursprungscluster, auf dem das DCM-Softwareelement durch ein Proxy-DCM repräsentiert wird, zu einem Zielcluster herzustellen, weiterleitet, wobei die Brücke die auf dem Ursprungscluster gültigen Softwareelementkennungen, die in dem Funktionsaufruf eingeschlossen sind, unter Verwendung der Korrespondenztabelle in auf dem Zielcluster gültige Softwareelementkennungen umändert.
Verfahren nach einem der Ansprüche 1 bis 6, wobei Proxy-DCM und Proxy-FCM jeweils als DCM_NON61883 bzw. FCM_NON61883 deklariert werden.
Verfahren nach einem der Ansprüche 1 bis 7, wobei das Herstellen eines Stroms durch ein Streammanager-Softwareelement die folgenden Schritte umfaßt: – Senden eines Funktionsaufrufs zu einem Streammanager (103) auf dem ersten Cluster (C), wobei der Funktionsaufruf die Herstellung einer Verbindung zwischen einem ersten FCM-Softwareelement (82) auf dem ersten Cluster (C) und einem zweiten FCM-Softwareelement (22) auf einem anderen Cluster (A) anfordert; – Veranlassen, daß das Streammanager-Softwareelement eine Verbindung zwischen dem ersten FCM-Softwareelement (82) und dem Proxy-FCM (22'') des zweiten FCM-Softwareelements (22) aufbaut; – Anweisen eines zweiten Streammanagers (53), der Teil der Brücke (BC) ist, eine Verbindung auf dem zweiten Cluster (B) zwischen dem das erste FCM-Softwareelement repräsentierenden Proxy-FCM-Softwareelement (FCM 82') und dem zweiten Softwareelement (22) oder einem Proxy (22') davon aufzubauen.
Verfahren nach Anspruch 8, wobei die Anweisung des zweiten Streammanagers (53) dadurch getriggert wird, daß die Brücke (BC) eine Nachricht auf dem ersten Cluster empfängt, die angibt, daß die Verbindung durch den ersten Streammanager (103) abgeschlossen ist.
Verfahren nach Anspruch 6 und Anspruch 8, wobei das Weiterleiten des Funktionsaufrufs für die interne Verbindung des DCM-Softwareelements durch die Brücke dadurch getriggert wird, daß die Brücke (BC) eine Nachricht auf dem ersten Cluster empfängt, die angibt, daß die Verbindung durch den ersten Streammanager (103) abgeschlossen ist.
Verfahren nach einem der Ansprüche 8 bis 10, wobei der Abschluß der Herstellung einer Verbindung auf einem Cluster durch ein Ereignis ConnectionAdded angegeben wird, wobei dieses Ereignis nicht von einem Cluster zum anderen weitergeleitet wird.
Verfahren nach einem der Ansprüche 8 bis 11, mit den folgenden Schritten: – Senden einer Nachricht zum Abwerfen einer über die Brücke hergestellten Verbindung zu einem dritten Streammanager (53) auf einem der Cluster (B), wobei der dritte Streammanager (53) zuvor als die abzuwerfende Verbindung haltend identifiziert wurde; – Veranlassen, daß der dritte Streammanager (53) die entsprechende auf seinem lokalen Cluster hergestellte Verbindung abwirft; – Veranlassen, daß die Brücke eine Verbindungskennung in der ursprünglichen Abwurfnachricht unter Verwendung ihrer Korrespondenztabelle aktualisiert; – Veranlassen, daß die Brücke (BC) die Abwurfnachricht zu einem vierten Streammanager auf dem anderen Cluster (C) weiterleitet, wobei der Streammanager durch die Aktualisierung identifiziert wurde.
Verfahren nach einem der Ansprüche 8 bis 11, mit den folgenden Schritten: – Senden einer Nachricht zum Abwerfen einer über die Brücke hergestellten Verbindung von einem Cluster zu einem dritten Streammanager (53) in einem Portal, wobei der dritte Streammanager (53) zuvor als die abzuwerfende Verbindung haltend identifiziert wurde; – Veranlassen, daß die Brücke eine Verbindungskennung in der ursprünglichen Abwurfnachricht unter Verwendung ihrer Korrespondenztabelle aktualisiert; – Bewirken, daß die Brücke (BC) die Abwurfnachricht zu einem vierten Streammanager auf dem anderen Cluster (C) weiterleitet, wobei der Streammanager durch die Aktualisierung identifiziert wurde; – Bewirken, daß der vierte Streammanager das Abwerfen der Verbindung auf beiden Clustern triggert.
Brückeneinrichtung (AB, BC) zum Verbinden eines ersten HAVi-Einrichtungsclusters mit einem zweiten HAVi-Einrichtungscluster, wobei die Einrichtung ein erstes Portal (3, 5) zur Verbindung mit dem ersten Cluster und ein zweites Portal zur Verbindung mit dem zweiten Cluster (4, 7) umfaßt, wobei die Brücke dafür ausgelegt ist, Softwareelemente (21, 22, 81, 82) auf einem Cluster durch Proxy-Softwareelemente (21', 21'', 22', 22'', 81', 81'', 82', 82''), die auf dem anderen Cluster sichtbar sind, zu repräsentieren, dadurch gekennzeichnet, daß sie ferner Mittel zum Erzeugen von Datenstrukturen umfaßt, die die Proxy-Softwareelemente beschreiben, wobei die Datenstrukturen mindestens eine Kennung der Brücke oder des Portals umfassen, die eine Kennung in der ursprünglichen Datenstruktur des durch das Proxy-Softwareelement repräsentierten ursprünglichen Softwareelements ersetzt.
Einrichtung nach Anspruch 14, dadurch gekennzeichnet, daß sie ferner Mittel zum Analysieren von Anforderungen von Datenstrukturen umfaßt, die von einem Softwareelement auf dem ersten Cluster empfangen werden und an ein Softwareelement des zweiten Clusters adressiert sind, wobei das Softwareelement des zweiten Clusters durch ein Proxy-Softwareelement auf dem ersten Cluster repräsentiert wird, und zum selektiven Weiterleiten einer Anforderung zu dem Softwareelement des zweiten Clusters oder zum Reagieren auf die Anforderung anstelle des Softwareelements des zweiten Clusters, wobei das selektive Weiterleiten oder Reagieren als Reaktion auf einen in der angeforderten Datenstruktur anwesenden Softwareelementkennungstyp erfolgt.
Einrichtung nach einem der Ansprüche 14 oder 15, ferner mit Mitteln (33, 43, 53, 73) zum Detektieren einer neuen Verbindung zwischen einem Softwareelement einer mit einem Cluster verbundenen Einrichtung und einem auf dem einen Cluster sichtbaren Proxy-Softwareelement und zum Triggern der Herstellens einer Verbindung auf einem anderen Cluster auf dem Weg zu dem Softwareelement, das durch das Proxy-Softwareelement repräsentiert wird, als Reaktion auf die Detektion.