DE19918896A1 - Logisches Netzwerksystem - Google Patents
Logisches NetzwerksystemInfo
- Publication number
- DE19918896A1 DE19918896A1 DE19918896A DE19918896A DE19918896A1 DE 19918896 A1 DE19918896 A1 DE 19918896A1 DE 19918896 A DE19918896 A DE 19918896A DE 19918896 A DE19918896 A DE 19918896A DE 19918896 A1 DE19918896 A1 DE 19918896A1
- Authority
- DE
- Germany
- Prior art keywords
- sub
- network system
- peripheral
- connection
- center
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Withdrawn
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/542—Event management; Broadcasting; Multicasting; Notifications
Abstract
Bestehende Netzwerksysteme erlauben nur die an die jeweiligen physikalischen Einheiten gebundene Punkt-zu-Punkt-Kommunikation zwischen genau zwei Prozessen. Die Auflösung von einheitenunabhängigen logischen Kennungen erfordert zusätzliche Transaktionen mit Netzwerk-Information- oder Directory-Services. Um mit mehreren Services zu kommunizieren, müssen Clients einzelne Verbindungen zu jedem der Services aufbauen. Die vorliegende Erfindung soll die einheitenunabhängige logische Kommunikation eines Peripherieprozesses mit einer beliebigen Anzahl anderer Peripherieprozesse in heterogenen Netzwerken unter Minimierung der notwendigen Kommunikationsverbindungen erlauben. DOLLAR A Die vorliegende Erfindung realisiert die unter 2.1 genannte Aufgabe durch hierarchisch verbindbare sternförmige Netzwerksysteme, bestehend aus beliebig vielen homogenen oder heterogenen physikalisch verbundenen Einheiten, welche auf einer Zentraleinheit mindestens einen Zentralprozeß -Zentrale - und auf einer der Einheiten Peripherieprozesse ausführen, wobei die Peripherieprozesse über mindestens eine stehende logische bidirektionale Verbindung mit einer Zentrale verbunden sind. Die Zentrale ordnet den Verbindungen der Peripherieprozesse logische Kennungen zu, wodurch die Peripherieprozesse unabhängig von ihren Einheiten mit ausgewählten Peripherieprozessen bzw. Verbindungen kommunizieren und gleichartige Peripherieprozesse für andere Peripherieprozesse transparent gegeneinander ausgetauscht werden können. DOLLAR A ...
Description
Die Erfindung betrifft logische Netzwerksysteme zur Interprozeßkommunikation in homo
genen oder heterogenen Netzwerken gemäß einem der Ansprüche 1 bis 81.
Logische Netzwerksysteme bestehen aus einer oder mehreren Einheiten, welche physi
kalisch miteinander verbunden sind und zwei oder mehr Prozesse ausführen, die unter
einander logische - d. h. von der Art der physikalischen Übertragung unabhängige -
Verbindungen aufbauen und über diese logischen Verbindungen Informationen austau
schen können. Homogene Systeme umfassen gleichartige Einheiten, welche von gleich
artigen Programmen gesteuert werden. Heterogene Systeme bestehen aus gleich- oder
verschiedenartigen Einheiten, welche durch gleich- oder verschiedenartige Programme
gesteuert werden, wobei die Netzwerkkomponenten der Steuerungsprogramme ein im
gesamten Netzwerk einheitliches Protokoll zum Verbindungsaufbau und zur Informati
onsübertragung auf jeder am Netzwerk partizipierenden Einheit implementieren.
Nach dem Stand der Technik erfolgt der Aufbau logischer Verbindungen wie folgt:
Eine durch eine eindeutige physikalische Kennung identifizierte Einheit führt einen Pro zeß (Server genannt) aus, der mindestens einen logischen Verbindungsendpunkt zur Verfügung stellt, welcher Endpunkt auf der den Server ausführenden Einheit durch eine lokale Kennung eindeutig identifiziert ist, und wartet anschließend bis ein anderer Pro zeß (Client), welcher auf derselben oder einer anderen Einheit ausgeführt wird, eine Ver bindung zu diesem Endpunkt anfordert. Vorausgesetzt die Einheiten, auf welchen Server und Client ausgeführt werden, sind physikalisch miteinander verbunden, benötigt der Cli ent zum Verbindungsaufbau einerseits die eindeutige Identifikation der Einheit, auf wel cher der Server ausgeführt wird, und andererseits die lokale Kennung des Verbindungsendpunktes, welchen der Server zur Verfügung stellt. Beide Informationen zusammen genügen, um den Verbindungsendpunkt eines Servers im gesamten Netzwerk eindeutig zu identifizieren. Hat ein Server eine Verbindungsanforderung eines Clients empfangen, entscheidet der Server über die Annahme oder Ablehnung der Anforderung. Eine Verbindung kommt nur zustande, wenn der Server die Anforderung gegebenenfalls nach einer positiv ausgefallenen Überprüfung der Zugangsberechtigung des Clients annimmt. Fällt die Überprüfung der Zugangsberechtigung des Clients negativ aus, bricht der Server den Verbindungsaufbau ab und es kommt keine Verbindung zustande. Nach diesem Mechanismus sind ausschließlich logische Punk-zu-Punkt Verbindungen zwi schen einem Client und einem Server aufbaubar. Logische Verbindungen zwischen zwei Clients, zwei Servern oder mehr als zwei Clients und/oder Servern sind nicht möglich.
Eine durch eine eindeutige physikalische Kennung identifizierte Einheit führt einen Pro zeß (Server genannt) aus, der mindestens einen logischen Verbindungsendpunkt zur Verfügung stellt, welcher Endpunkt auf der den Server ausführenden Einheit durch eine lokale Kennung eindeutig identifiziert ist, und wartet anschließend bis ein anderer Pro zeß (Client), welcher auf derselben oder einer anderen Einheit ausgeführt wird, eine Ver bindung zu diesem Endpunkt anfordert. Vorausgesetzt die Einheiten, auf welchen Server und Client ausgeführt werden, sind physikalisch miteinander verbunden, benötigt der Cli ent zum Verbindungsaufbau einerseits die eindeutige Identifikation der Einheit, auf wel cher der Server ausgeführt wird, und andererseits die lokale Kennung des Verbindungsendpunktes, welchen der Server zur Verfügung stellt. Beide Informationen zusammen genügen, um den Verbindungsendpunkt eines Servers im gesamten Netzwerk eindeutig zu identifizieren. Hat ein Server eine Verbindungsanforderung eines Clients empfangen, entscheidet der Server über die Annahme oder Ablehnung der Anforderung. Eine Verbindung kommt nur zustande, wenn der Server die Anforderung gegebenenfalls nach einer positiv ausgefallenen Überprüfung der Zugangsberechtigung des Clients annimmt. Fällt die Überprüfung der Zugangsberechtigung des Clients negativ aus, bricht der Server den Verbindungsaufbau ab und es kommt keine Verbindung zustande. Nach diesem Mechanismus sind ausschließlich logische Punk-zu-Punkt Verbindungen zwi schen einem Client und einem Server aufbaubar. Logische Verbindungen zwischen zwei Clients, zwei Servern oder mehr als zwei Clients und/oder Servern sind nicht möglich.
Services nach dem Stand der Technik sind transaktionsorientierte Server, welche nach
erfolgreichem Verbindungsaufbau auf eine Transaktionsaufforderung seitens eines Cli
ents warten, nach erfolgter Aufforderung eine bestimmte Aktion durchführen und
anschließend gegebenenfalls dem Client das Resultat dieser Aktion übermitteln. Der
gesamte Vorgang, von der Aufforderung bis zur Übermittlung des Resultates bezeichnet
man als eine Transaktion. Die Transaktionsaufforderung des Clients muß nicht notwen
digerweise durch eine Nachricht erfolgen, sondern kann bereits durch den Verbindungs
aufbau impliziert sein.
Eine Verbindung zwischen Service und Client kann sowohl nur für eine einzige Transak
tion (temporäre Verbindung) als auch für mehrere Transaktionen (stehende Verbindung)
bestehen. Nach Abschluß aller Transaktionen wird die Verbindung von einem der beiden
Transaktionspartnern geschlossen, woraufhin der andere Partner seinerseits die Verbin
dung schließt.
Ein typisches Beispiel solcher Netzwerke ist das Internet oder Internet-ähnliche Intra
nets, welche aus mehreren freiprogrammierbaren, physikalisch vernetzten Rechenma
schinen bestehen. Die Steuerung einer jeden Rechenmaschine erfolgt durch ein
Betriebssystem, der Netzwerk- sowie den Anwendungsprogrammen. Homogene
Systeme umfassen gleich- oder verschiedenartige Rechenmaschinen, welche von gleich
artigen Betriebssystemen gesteuert werden. Heterogene Systeme bestehen aus gleich-
oder verschiedenartigen Rechenmaschinen, welche durch gleich- oder verschiedenartige
Betriebssysteme gesteuert werden. Die Netzwerkprogramme sind typischerweise nach
dem ISO/OSI-Modell aufgebaut, verwenden das TCP/IP-Protokoll und dienen zum Infor
mationsaustausch zwischen verschiedenen Softwarekomponenten, welche auf dersel
ben oder verschiedenen gleich- oder verschiedenartigen Rechenmaschinen ausgeführt
werden.
Typische Vertreter, welche nach dem beschriebenen Client/Server-Prinzip arbeiten, sind
die Betriebsysteme Unix, Windows NT, OS/2 oder NetWare, sowie die Middleware DCE,
TUXEDO oder CORBA.
Folgende Punkte wirken sich bei Netzwerken nach dem Stand der Technik als beson
ders nachteilig aus:
- 1. Das Client/Server-Prinzip erlaubt nur Punkt-zu-Punkt-Verbindungen zwischen einem Client und einem Server bzw. Service. Benötigt ein Client mehrere Services, muß er zu jedem Service eine separate Verbindung herstellen.
- 2. Sollen alle Komponenten eines Netzwerksystems wahlfrei untereinander Verbin dungen aufbauen können, muß jede Komponente gleichzeitig als Server und Client ausgelegt sein. Dies erhöht die Zahl der Server und damit das Sicherheitsrisiko dramatisch.
- 3. Sollen n Komponenten eines Systems untereinander kommunizieren, beträgt die Anzahl der benötigten bidirektionalen Punkt-zu-Punkt-Verbindungen ½n(n-1) und wächst proportional zu ½n2. Systeme dieser Art lassen sich nur unter unwirtschaft lich großem Aufwand mit einer großen Anzahl von Komponenten betreiben und sind daher nicht beliebig skalierbar.
- 4. Die Zuverlässigkeit des Gesamtsystems nimmt mit zunehmender Anzahl von Ver bindungen ab, da das Risiko eines Verbindungsunterbruchs mit jeder zusätzlichen Punkt-zu-Punkt-Verbindung zunimmt.
- 5. Jede Einheit, welche einen Server ausführt, muß im gesamten Netzwerk eindeutig gekennzeichnet sein.
- 6. Clients müssen die Kennzeichnung der Einheit und die lokale Kennung des Verbin dungsendpunktes eines Servers kennen, zu welchem sie eine Verbindung auf bauen wollen. Dies hat zur Folge, daß Server an ihre Einheit gebunden sind und nicht durch gleichartige Server auf anderen Einheiten ersetzt werden können, ohne daß dies den Clients bekannt sein muß. Der für die Clients transparente Ersatz eines Servers durch einen anderen auf einer anderen Einheit ist nach derzeitigem Stand der Technik nicht möglich.
- 7. In der Praxis stellt jeder Server ein potentielles Sicherheitsrisiko dar, da er alleine dafür verantwortlich ist, eine Verbindungsanforderung und Transaktionsaufforde rungen eines Clients anzunehmen bzw. auszuführen. Mit zunehmender Anzahl von Servern steigt auch das Sicherheitsrisiko des Gesamtsystems. Zur Erlangung eines definierten Sicherheitsstandards des Gesamtsystems müssen alle Server die gleichen Sicherheitsanforderungen erfüllen, da das Gesamtsystem nur so sicher ist wie der unsicherste Server.
- 8. Die Historie des Netzwerkes ist in Systemen nach dem Stand der Technik nur mit sehr hohem Aufwand nachzuvollziehen, da das Netzwerk nur auf physikalischer Ebene überwacht werden kann und die physikalisch übertragenen Daten erst in logisch sinnvolle Einheiten übersetzt werden müssen, bevor sie auf logischer Ebene sinnvolle Nachrichten oder Transaktionen ergeben. Dies gilt in besonderem Maße für Netzwerke auf TCP/IP-Basis, welche nur durch "Sniffen", d. h. direkte Analyse der physikalisch übertragenen Daten, vollständig überwacht werden kön nen.
- 9. Zur Gewährleistung der Sicherheit bestehender Netzwerke werden derzeit soge nannte Firewalls eingesetzt, welche zwischen Clients und Services geschaltet sind und von bestimmten Quellen nur Nachrichten bestimmten Types passieren lassen, so daß Clients nur zu denjenigen Services Verbindungen aufbauen und Transaktio nen durchführen können, für welche sie authorisiert sind. Diese zusätzliche Filte rung vermindert die Leistungsfähigkeit des Gesamtsystems.
Die zugrundeliegende Aufgabe der Erfindung liegt darin, ein logisches Netzwerksystem
zu realisieren, welches die obengenannten Nachteile beseitigt, insbesondere die Mög
lichkeit der einheitenunabhängigen logischen Kommunikation aller Komponenten unter
einander bietet und dadurch den für die Clients transparenten Ersatz von Servern
erlaubt, gleichzeitig die Übertragungszeit der einzelnen Nachrichten minimiert sowie ein
Maximum an Zuverlässigkeit und Sicherheit gewährleistet.
Zur Lösung der Aufgabe bieten sich Netzwerke mit sternförmiger Architektur an. Stern
förmige Netzwerke sind prinzipiell bereits aus verschiedenen anderen Anwendungsge
bieten bekannt, die jedoch nicht für den Aufbau von logischen Netzwerken auf
Prozeßebene geeignet sind, sondern nur für Verbindungen von physikalischen Periphe
rieeinheiten, wie z. B.: Telefonanlagen (z. B.: DE 43 29 172, EP 876067, EP 883310),
Funknetze (WO 97/36444), physikalische Subnetze (US 5274631), ATM-Netze (DE 195 32 421/2),
Netzwerk-Gateways (US 5596579), und erlauben nach Kenntnis des
Autors nicht, mehrere voneinander unabhängige Verbindungen zwischen denselben
Peripherieeinheiten bzw. -Prozessen und Zentrale. Auch die logische Adressierbarkeit
einzelner Prozesse bzw. Verbindungen unabhängig von den physikalischen Kennungen
der Einheiten und lokalen Kennungen der Verbindungsendpunkte ist nach Kenntnis des
Autors in keinem System nach dem Stand der Technik realisiert.
Zur Lösung der gestellten Aufgabe dient ein sternförmig aufgebautes logisches Netz
werksystem nach dem Obergriff des Anspruches 1 bestehend aus einer Zentraleinheit,
welche einen Zentralprozeß - Zentrale genannt - ausführt und weiteren Prozessen - Peri
pherieprozesse genannt -, welche beliebig verteilt auf der Zentraleinheit oder einer min
destens mit der Zentraleinheit physikalisch verbundenen Peripherieeinheit ausgeführt
werden und über eine oder mehrere stehende logische bidirektionale Kommunikations
verbindungen mit der Zentrale verbunden sind. Die Zentrale ordnet mindestens einer
Verbindung eines Peripherieprozesses mindestens eine logische - d. h. an keine
bestimmte physikalische Einheit gebundene - Kennung zu, so daß ein Peripherieprozeß
allein aufgrund dieser logischen Kennung(en) indirekt über die Zentrale mit mindestens
einem bestimmten Peripherieprozeß kommunizieren kann.
Die logische Kennung(en) müssen in einem Netzwerksystem nach Anspruch 1 nicht not
wendigerweise eine Verbindung oder einen Peripherieprozeß eindeutig kennzeichnen.
Ein spezielles Ausführungsbeispiel eines Netzwerksystems nach Anspruch 1 veran
schaulicht Abb. 1. Es besteht aus der Zentraleinheit ZE und drei Peripherieeinhei
ten PE1-PE3, welche jeweils über die physikalischen Verbindungen V1-V3 mit der
Zentraleinheit verbunden sind. Die Zentraleinheit führt den Zentralprozeß Z und einen
Peripherieprozeß P1 aus, Einheit PE1 die Peripherieprozesse P2-P4, Einheit PE2 die
Peripherieprozesse PS und P6 und Einheit PE3 die Peripherieprozesse P7 und P8. Die
Peripherieprozesse P2, P4, P6 und P8 sind über eine, P1 und P3 über zwei, P5 über
drei und P7 über vier stehende logische bidirektionale Kommunikationsverbindungen mit
der Zentrale verbunden.
Spezielle Ausführungen eines Netzwerksystems nach Anspruch 1 schließen auch den
Fall mit ein, daß alle Prozesse auf der Zentraleinheit ausgeführt werden.
Die besonderen Vorteile eines Netzwerksystems nach Anspruch 1 sind, daß
- 1. die Peripherieprozesse lediglich über eine Verbindung zur Zentrale und über die Kenntnis einer logischen Kennung verfügen müssen, um mit anderen Peripherie prozessen indirekt über die Zentrale zu kommunizieren,
- 2. jeder Peripherieprozeß gleichzeitig mit mehreren anderen Peripherieprozessen kommunizieren kann, ohne weitere Verbindungen aufzubauen,
- 3. die Kommunikation unabhängig von der Einheit ist, auf welcher die Peripheriepro zesse ausgeführt werden, insbesondere die Kommunikationspartner nicht die phy sikalischen Einheiten oder die lokalen Verbindungsendpunkte der Kommunika tionspartner kennen müssen,
- 4. die Anzahl der benötigten stehenden logischen Kommunikationsverbindungen nur linear mit der Anzahl der Peripherieprozesse ansteigt,
- 5. alle Nachrichten die Zentrale passieren müssen, so daß die Zentrale auf logischer Ebene die Aktivität im Netzwerk beobachten, die komplette Historie des Netzwer kes chronologisch protokollieren und die Weiterleitung von unauthorisierten Nach richten verhindern kann,
- 6. die schnellstmögliche Übermittelung der Nachrichten von einem Peripherieprozeß zu einem anderen gewährleistet ist, da nur stehende Kommunikationsverbindun gen verwendet werden und Totzeiten für Verbindungsauf- und -abbauten wegfallen, so daß ein Peripherieprozeß lediglich eine Nachricht an die Zentrale senden und die Zentrale diese Nachricht an den Kommunikationspartner weiterleiten muß. Ansprüche 2 bis 9 charakterisieren den Verbindungsaufbau zwischen der Zentrale und den Peripherieprozessen.
In einem Netzwerksystem nach Anspruch 2 ist die Zentrale zur Annahme einer Verbin
dung befähigt, und stellt jederzeit mindestens einen freien Verbindungsendpunkt zur
Verfügung. Damit die zum Auslösen eines Verbindungsaufbaues geeigneten Peripherie
prozesse eine Verbindung zu diesem Endpunkt aufbauen können, muß die Zentralein
heit eine im gesamten Netzwerk eindeutige physikalische - d. h. an eine bestimmte
physikalische Einheit gebundene - Kennung und die Verbindungsendpunkte der Zentrale
eine auf der Zentraleinheit eindeutige lokale Kennung besitzen. Alle zum Auslösen eines
Verbindungsaufbaues geeigneten Peripherieprozesse verfügen über die Kenntnis der
Kennung der Zentraleinheit und des Verbindungsendpunktes der Zentrale und initiieren
den Verbindungsaufbau von sich aus.
Ein Ausführungsbeispiel des zeitlichen Ablaufes des Verbindungsaufbaus in einem Netz
werksystem nach Anspruch 2 ist im oberen Teil von Abb. 2 (gekennzeichnet mit
"Verbindungsaufbau System-Service" und "Verbindungsaufbau Service-Client") anhand
von zwei Peripherieprozessen - System-Service und Service-Client genannt - wiederge
geben. Zu Beginn stellt die Zentrale in ihrem Hauptthread einen freien Verbindungsend
punkt zur Verfügung und wartet auf eine Verbindungsanforderung. Ein Peripherieprozeß
fordert unmittelbar nach seinem Start eine Verbindung zur Zentrale an (N1 & N3). Die
Zentrale überprüft die Zugangsberechtigung des Peripherieprozesses, ordnet bei positi
vem Ausfall der Überprüfung der neuen Verbindung spezifische Zugangsdaten zu, star
tet einen neuen Thread, welcher jede weitere Kommunikation mit dem Peripherieprozeß
abwickelt, und schließt den Verbindungsaufbau mit der Übermittelung der Zugangsdaten
(N2 & N4) ab. Parallel dazu erzeugt der Hauptthread der Zentrale einen neuen freien
Verbindungsendpunkt unter derselben lokalen Kennung wie anfänglicher Verbindungs
endpunkt und wartet auf die nächste Verbindungsanforderung, so daß der nächste Peri
pherieprozeß (Service-Client) nach dem gleichen Ablauf seine Verbindung zur Zentrale
aufbauen kann. Fällt die Zugangsprüfung negativ aus, bricht die Zentrale den Verbin
dungsaufbau ab und es kommt keine Verbindung zustande.
In einem Netzwerksystem nach Anspruch 3 ist mindestens ein Peripherieprozeß zur Auf
nahme einer Verbindung geeignet und stellt mindestens einen freien Verbindungsend
punkt zur Verfügung. Die Zentrale ist in diesem Fall zum Auslösen eines Verbindungs
aufbaues geeignet und initiiert selbständig Verbindungsaufbauten zu zur Aufnahme
einer Verbindung geeigneten Peripherieprozessen. Damit die Zentrale eine Verbindung
zu einem Peripherieprozeß aufbauen kann, muß die Einheit, welche den zur Aufnahme
einer Verbindung geeigneten Peripherieprozeß ausführt, eine im gesamten Netzwerk
eindeutige Kennung, der Verbindungsendpunkt des Peripherieprozesses eine auf der
ihn ausführenden Einheit eindeutige lokale Kennung besitzen und beide Kennungen der
Zentrale bekannt sein.
Ein Ausführungsbeispiel des zeitlichen Ablaufes des Verbindungsaufbaus in einem Netz
werksystem nach Anspruch 3 ist im oberen Teil von Abb. 3 (gekennzeichnet mit
"Verbindungsaufbau zu System-Service" und "Verbindungsaufbau zu Service-Client")
anhand von zwei Peripherieprozessen - System-Service und Service-Client genannt -
wiedergegeben. Die Zentrale liest alle Peripherieprozesse mit ihren physikalischen und
lokalen Kennungen aus ihrer Datenbasis ein, zu welchen sie eine Verbindung aufbauen
soll. Für jede aufzubauende Verbindung startet die Zentrale einen neuen Thread und
sendet eine Anforderung zum Verbindungsaufbau (N1 & N4) an den Peripherieprozeß.
Der Peripherieprozeß stellt einen lokal eindeutig gekennzeichneten Verbindungsend
punkt zur Verfügung und wartet auf eine Verbindungsanforderung. Nach Empfang einer
Verbindungsanforderung überprüft der Peripherieprozeß die Zugangsberechtigung der
Zentrale. Fällt diese Überprüfung negativ aus, bricht der Peripherieprozeß den Verbin
dungsaufbau ab und es kommt keine Verbindung zustande, fällt genannte Überprüfung
positiv aus, akzeptiert der Peripherieprozeß die Verbindung (N2 & N5), und erhält zum
Abschluß des Verbindungsaufbaues die Zugangsdaten nach ihrer Zuordnung von der
Zentrale übermittelt (N3 & N6). Der Verbindungsaufbau zu weiteren Peripherieprozessen
erfolgt nach demselben Schema, wobei die Threads der Zentrale, welche den Verbin
dungsaufbau durchführen, auch während des Verbindungsaufbaues parallel ausgeführt
werden können.
In keinem der Netzwerksysteme nach einem der Ansprüche 2 oder 3 besteht die Mög
lichkeit der direkten Kommunikation unter den Peripherieprozessen, wenn alle Periphe
rieprozesse entweder nur zum Auslösen eines Verbindungsaufbaues zur Zentrale
geeignet sind oder die zur Aufnahme einer Verbindung geeigneten Peripherieprozesse
nur Verbindungen von der Zentrale akzeptieren.
Anspruch 3 umfaßt sowohl den Fall, daß alle Peripherieprozesse zur Aufnahme einer
Verbindung geeignet sind und nur Verbindungen von der Zentrale akzeptieren, als auch
den Fall, daß ein Teil der Peripherieprozesse nach Anspruch 2 zum Auslösen eines Ver
bindungsaufbaues zur Zentrale geeignet sind und ein anderer Teil zur Aufnahme einer
Verbindung von der Zentrale geeignet sind, wobei die Zentrale von sich aus nur Verbin
dungen zu Peripherieprozessen aufbaut, welche zur Aufnahme einer Verbindung von
der Zentrale geeignet sind.
Besonderere Vorteile eines Netzwerksystemes nach Anspruch 2 sind, daß die Zugangs
überprüfung von der Zentrale durchgeführt wird und es nur einen Zugang zum Gesamt
system gibt, welcher a) eindeutig lokalisiert ist, b) sehr gut überwacht werden kann und
c) mit verhältnismäßig geringem Aufwand absicherbar und wartbar ist. In einem Netz
werksystemen nach Anspruch 3 hingegen führt jeder zur Aufnahme einer Verbindung
geeignete Peripherieprozeß seine eigene Zugangsüberprüfung durch, so daß sich die
Sicherheitsrisiken allein durch die größere Anzahl von Systemzugängen erhöhen.
In einem Netzwerksystem nach Anspruch 2 müssen die Peripherieeinheiten nicht not
wendigerweise im gesamten Netzwerk eindeutig gekennzeichnet sein. Dies verunmög
licht es jedoch zusätzliche Bedingungen für den Zugang zur Zentrale zu stellen, welche
die Ausführungseinheit eines Peripherieprozesses einschänken. Diesen Mangel behebt
ein Netzwerksystem nach Anspruch 4.
In einem Netzwerksystem nach Anspruch 5 ist die logische Kennung, welche eine Ver
bindung zu einem Peripherieprozeß von der Zentrale während des Verbindungsauf
baues zugeordnet bekommt, innerhalb der Zentrale für den jeweiligen Peripherieprozeß
eindeutig, wodurch die Peripherieprozesse die Möglichkeit erhalten, mit eindeutig
bestimmten Peripherieprozessen zu kommunizieren. Baut ein Peripherieprozeß mehrere
Verbindungen zur Zentrale auf, erhalten diese dieselbe logische Kennung. Diese Eigen
schaft ist besonders dann von Vorteil, wenn ein Peripherieprozeß einem bestimmten
Peripherieprozeß Informationen übermitteln möchte und es unerheblich ist, über welche
Verbindung diese Informationen zum Ziel gelangen.
In einem Netzwerksystem nach Anspruch 6 ist die logische Kennung, welche eine Ver
bindung zu einem Peripherieprozeß von der Zentrale während des Verbindungsauf
baues zugeordnet bekommt, innerhalb der Zentrale eindeutig, wodurch die Peripherie
prozesse die Möglichkeit erhalten, mit eindeutig bestimmten einzelnen Verbindungen
eines Peripherieprozesses zu kommunizieren. Diese Eigenschaft ist besonders dann
von Vorteil, wenn ein Peripherieprozeß mehrere Verbindungen mit unterschiedlichen
Funktionalitäten zur Zentrale aufbaut und ein anderer Peripherieprozeß gezielt eine die
ser Funktionalitäten nutzen möchte. Die eindeutige logische Adressierbarkeit einzelner
Verbindungen ist beispielsweise bei Anspruch 23 von großer Bedeutung.
Ein Netzwerksystem nach Anspruch 7 erlaubt es, die Zugangsbedingungen während der
Laufzeit des Systems zu verändern, wobei die bestehenden Verbindungen die neuen
Zugangsbedingungen erfüllen müssen, andernfalls abgebrochen werden und gegebe
nenfalls nach den neuen Zugangsbedingungen erlaubte Verbindungen entweder bei
ihrer Anforderung akzeptiert oder automatisch aufgebaut werden. Auch in diesem
Zusammenhang ist ein Netzwerksystem nach Anspruch 2 gegenüber einem System
nach Anspruch 3 vorzuziehen, da die Zugangsbedingungen in ersterem Fall (Anspruch
2) ausschließlich in der Zentrale vorliegen müssen, während sie im zweiten Fall
(Anspruch 3) zu allen Peripherieprozessen kommuniziert werden müssen, welche zur
Aufnahme einer Verbindung von der Zentrale geeignet sind.
Ansprüche 9 und 10 behandeln den Fall eines Verbindungsunterbruches zwischen Peri
pherieprozeß und Zentrale. In beiden Ansprüchen werden unterbrochene Verbindungen
von den entsprechenden Seiten (Peripherieprozeß bei Anspruch 2) bzw. (Zentrale bei
Anspruch 3) automatisch sobald wie möglich wieder aufgebaut. Dies setzt natürlich vor
aus, daß die jeweiligen Prozesse die Fähigkeit besitzen Verbindungsunterbrüche zu
detektieren und daß nach einem Verbindungsunterbruch die Voraussetzungen zum
erneuten Verbindungsaufbau wieder gegeben sind. Die Detektion eines Verbindungsun
terbruches kann beispielsweise durch Auswertung von Fehlersituationen bei der Infor
mationsübertragung über die Verbindungen geschehen oder durch einen separaten
Thread realisiert werden, welcher in regelmäßigen Abständen die Funktionsfähigkeit der
Verbindungen überprüft. Die Wiederherstellung der Voraussetzung zu einem erneuten
Verbindungsaufbau kann entweder automatisch durch das Netzwerksystem selbst erfol
gen (siehe auch Anspruch 22) oder einen manuellen Eingriff eines Operators erfordern.
Ansprüche 11 bis 19 betreffen die Art der Nachrichtenübermittlung durch die Zentrale.
In einem Netzwerksystem nach Anspruch 11 fügt ein Peripherieprozeß (Sender) einer
Nachricht die logische Kennung mindestens einer Verbindung eines Peripherieprozes
ses (Empfänger) hinzu und sendet die Nachricht zusammen mit den Kennungen der
Empfangsverbindungen an die Zentrale. Die Zentrale analysiert die Nachricht nach ihrer
Qualität und den Empfangsverbindungen und leitet die Nachricht gegebenenfalls nach
einer positiv ausgefallenen Authorisierungsprüfung via der in der Nachricht angegebe
nen Empfangsverbindungen an die Empfänger weiter. Dabei ist es unerheblich, ob die
logischen Kennungen der Empfangsverbindungen eindeutig sind oder nicht. Sind die
logischen Kennungen mehrdeutig, leitet die Zentrale die Nachricht an mindestens eine
der Empfangsverbindungen mit der angegebene Kennung weiter. Ferner ist auch der
Fall eingeschlossen, daß die Kennung der Sendeverbindung als Empfangskennung in
der Nachricht enthalten ist. In diesem Fall leitet die Zentrale die Nachricht auch an die
Sendeverbindung weiter (Loop-Back). Loop-Back-Nachrichten sind zum Beispiel im
Zusammenhang mit Guards (Anspruch 22 oder 23) zum Testen der Funktionsfähigkeit
der Zentrale von Bedeutung.
Ansprüche 12 und 13 spezifizieren, wie die Zentrale mit Nachrichten verfährt, welche
keine logischen Kennungen von Empfangsverbindungen enthalten. Eine Zentrale nach
Anspruch 14 fügt vor der Weiterleitung den Nachrichten die logische Kennung der Sen
deverbindung hinzu, so daß die Empfänger mit der Nachricht auch die logische Kennung
der Sendeverbindung erhalten und dem Sender gegebenenfalls antworten können.
Ansprüche 15 bis 19 legen fest, wie die Zentrale mit Nachrichten verfährt, deren Authori
sierungsprüfung negativ ausfiel (Anspruch 15), die an einen temporär nicht mit der Zen
trale verbunden Empfänger gerichtet sind (Ansprüche 18 und 19) und den Sender
darüber informiert, an welche Empfangsverbindungen eine Nachricht weitergeleitet
wurde (Anspruch 16) bzw. an, welche Empfangsverbindungen eine Nachricht nicht wei
tergeleitet werden konnte (Anspruch 17).
Ansprüche 19 bis 23 charakterisieren spezielle Peripherieprozesse - System-Service,
Service-Client und Guard genannt -, deren Verbindungen sich unabhängig vom Verbin
dungsaufbau zur Zentrale in ihrer Funktionalität unterscheiden. Die Interaktion zwischen
Service-Client und System-Service erfolgt auf Basis sogenannter Transaktionen, welche
aus einer Transaktionsaufforderung, die der Service-Client via der Zentrale an einen
System-Service schickt, der Transaktionsausführung seitens des System-Services und
gegebenenfalls eines Transaktionsresultates, welches der System-Service via der Zen
trale an den Service-Client schickt, bestehen. System-Services sind in dem Sinne passiv
aufgebaut, in dem sie nach dem Verbindungsaufbau mit der Zentrale auf eine Transakti
onsaufforderung eines Service-Clients warten, nach Eintreffen einer solchen Aufforde
rung vordefinierte Aktionen durchführen, gegebenenfalls ein Resultat an den Sender der
Transaktionsaufforderung senden und anschließend auf die nächste Transaktionsauffor
derung warten. Service-Clients spielen dagegen in dem Sinne eine aktive Rolle, in dem
sie zuerst Transaktionsaufforderungen an System-Services senden, anschließend gege
benenfalls das Resultat der Transaktion empfangen und in Abhängigkeit von dem emp
fangenen Resultat und ihrer sonstigen Aufgaben gegebenenfalls weitere Transaktionen
durchführen.
Anspruch 22 beschreibt spezielle Peripherieprozesse - Guards genannt -, welche Über
wachungsfunktionen wahrnehmen und bei festgestelltem Fehlverhalten Maßnahmen
einleiten, um den Fehler automatisch zu beheben oder an andere Peripherieprozesse
oder einen Operator zu melden. So kann ein Guard, welcher beispielsweise in regelmä
ßigen Abständen die Funktionsfähigkeit der Zentrale mit Hilfe von Loop-Back-Nachrich
ten überprüft, ein Fehlverhalten der Zentrale feststellen und zur Korrektur die Zentrale
terminieren und erneut starten. Auch die Überwachung von wichtigen System-Services
ist mit Hilfe von Guards realisierbar, welche als Service-Clients ausgeprägt sind, zur
Überwachung der System-Services gezielte Test-Transaktionen durchführen und im
Falle eines Fehlers den betreffenden System-Service terminieren und gegebenenfalls
auf einer anderen Einheit erneut starten.
Abb. 4 illustriert ein Ausführungsbeispiel eines Netzwerksystems nach den Ansprü
chen 20 bis 22. Die Zentrale Z ist mit drei System-Services S1-S3, einem Guard G und
vier Service-Clients SC1-SC4 verbunden. Alle Service-Clients sind nach Anspruch 21,
der Guard nach Anspruch 22 und die System-Services S2 und S3 nach Anspruch 20
geartet. System-Service S1 ist nach Anspruch 23 ausgeprägt und unterhält gleichzeitig
in Thread T1 eine System-Service-Verbindung SSV und in Thread 2 eine Service-Client-
Verbindung SCV zur Zentrale. Die Zentrale, der Guard und die System-Services bilden
zusammen das Kernsystem KS. Aus Sicht der Service-Clients bildet das Kernsystem
eine "Black Box", welche ihnen nach einem Verbindungsaufbau die Funktionalitäten der
System-Services zur Verfügung stellt.
Der zeitliche Ablauf einer Transaktion in einem Netzwerksystem nach Anspruch 2 und
den Ansprüchen 20 bis 21 ist im unteren Teil der Abb. 2 ("Transaktion 1" bzw. erster
Teil von "Transaktion 2") dargestellt. Der Service-Client sendet die Transaktionsaufforde
rung zusammen mit der Kennung des System-Services an die Zentrale (N5 bzw. N9),
welche die Nachricht in dem für den Service-Client gestarteten Thread empfängt. Nach
einer positiv ausgefallen Authorisierungsprüfung AP1 (bzw. AP3) leitet die Zentrale die
Nachricht an den adressierten System-Service weiter (N6 bzw. N10). Der System-Ser
vice empfängt seinerseits die Aufforderung, führt in Abhängigkeit von der Aufforderung
eine vordefinierte Aktion durch und sendet das Resultat dieser Aktion zusammen mit der
Kennung des Service-Clients an die Zentrale (N7), welche ihrerseits wiederum die Nach
richt gegebenenfalls nach einer positiv ausgefallenen Authorisierungsprüfung AP2 an
den Service-Client weiterleitet. Mit dem Empfang des Transaktionsresultates seitens des
Service-Clients ist die Transaktion abgeschlossen, wonach der Service-Client auf das
Resultat reagiert und gegebenenfalls die nächste Transaktion initiiert ("Transaktion 2").
Transaktion 2 ist auf der Abb. 2 nicht mehr vollständig dargestellt und verdeutlicht
lediglich die zeitliche Sequenz der Transaktionen.
Trotz des unterschiedlichen Verbindungsaufbaues, unterscheidet sich der zeitliche
Ablauf einer Transaktion in einem Netzwerksystem nach Anspruch 3 und Ansprüchen 20
bis 21 nicht gegenüber dem oben dargestellten Transaktionsablauf (siehe auch unterer
Teil von Abb. 3 ("Transaktion 1" bzw. erster Teil von "Transaktion 2")). Hier bezeich
nen N7 bzw. N11 die Übertragung der Transaktionsaufforderung vom Service-Client zur
Zentrale, N8 bzw. N12 die Weiterleitung der Aufforderung an den System-Service, N9
die Übertragung des Transaktionsresultates an den Service-Client und AP1-AP3 die
jeweiligen Authorisierungsprüfungen vor der Weiterleitung der Nachrichten seitens der
Zentrale.
Die Unterscheidung zwischen aktiven (Service-Clients) und passiven (System-Services)
Peripherieprozessen hat vor allem das Ziel Deadlocks zu verhindern, welche beispiels
weise dann auftreten, wenn ein Prozeß eine Transaktionsaufforderung erhält während er
auf das Resultat einer selbstinitiierten Transaktion wartet. In diesem Zusammenhang ist
besonders die Kombination eines System-Services und eines Service-Clients in einem
Peripherieprozeß (Anspruch 23) von großer Bedeutung: Benötigt ein System-Service
Informationen anderer System-Services, ist es vorteilhaft die Transaktionen mit anderen
System-Services in einem parallelen Thread über eine separate Verbindung zur Zentrale
durchzuführen, über welche der System-Service als Service-Client gegenüber anderen
System-Services auftritt. Dies setzt natürlich voraus, daß die beiden Verbindungen des
System-Services unterschiedliche Kennungen von der Zentrale zugeordnet bekommen,
damit potentielle Sender sie unterscheiden können. So lassen sich Deadlock-Situatio
nen, Timing-Probleme oder Fehlinterpretationen eintreffender Nachrichten von vorne
herein sehr einfach und effizient vermeiden.
System-Services nach einem der beschriebenen Ansprüche haben gegenüber traditio
nellen Services nach dem Client/Server-Prinzip folgende entscheidenden Vorteile:
- 1. ein System-Service benötigt nur eine Verbindung zur Zentrale,
- 2. der Zugang zu einem System-Service erfolgt indirekt über die Zentrale, so daß die Zentrale den gesamten Nachrichtenverkehr überwachen und gegebenenfalls nicht authorisierte Transaktionsaufforderungen blockieren kann, wodurch Firewalls über flüssig werden,
- 3. ein System-Service ist nicht an eine bestimmte Einheit und einen bestimmten Ver bindungsendpunkt gebunden sondern allein über seine logische Service-Kennung adressierbar,
- 4. die Verwaltung der logischen Kennungen erfolgt in der Zentrale und bedarf keiner zusätzlichen Transaktionen seitens eines Service-Clients, so daß eine explizite Auflösung von logischen Namen über Network-Information-, Directory- oder ähnli che Services entfallen kann,
- 5. ein System-Service kann für die Service-Clients transparent durch einen gleicharti gen auf derselben oder einer anderen Einheit ausgeführten System-Service ersetzt werden,
- 6. die Verfügbarkeit des Kernsystems kann durch gleichartige redundante System- Services erhöht werden (siehe weiter unten und Anspruch 27),
- 7. mit einer einzigen Verbindung zur Zentrale erhalten Service-Clients die Möglichkeit mit allen System-Services zu kommunizieren, so daß der häufige und zeitaufwen dige Verbindungsauf- bzw. -abbau zu bzw. von oder die Unterhaltung mehrerer par alleler Verbindungen zu verschiedenen traditionellen Services entfallen kann,
- 8. zur Durchführung einer Transaktion werden lediglich vier Nachrichten über das physikalische Netzwerk übertragen, wodurch die Transaktionszeit gegenüber tradi tionellen Systemen erheblich verkürzt wird.
Letzterer Punkt kann jedoch bei großen Nachrichtenvolumina und ungünstig ausgelegten
physikalischen Netzwerkverbindungen im Vergleich zum direkten Informationsaustausch
zwischen traditionellen Client/Service-Systemen das gesamte über das physikalische
Netzwerk übertragene Informationsvolumen signifikant erhöhen, da in traditionellen
Systemen abgesehen vom Verbindungsauf- und -abbau zwei Nachrichten für eine Trans
aktion ausreichen.
In einem Netzwerksystem nach den bisher besprochenen Ansprüchen bildet, wie in
jedem sternförmigen System, die Zentrale einen Single Point of Failure, d. h. ein Ausfall
der Zentrale führt zu einem totalen Systemausfall. Der Ausfall eines oder mehrerer
System-Services dagegen führt in der Regel lediglich zu einem Ausfall von Teilfunktiona
litäten des Kernsystems. Durch gegenseitige Abhängigkeiten können auch in letzerem
Fall andere prinzipiell noch funktionsfähige Teilbereiche betroffen sein. Beides, der Aus
fall der Zentrale oder eines System-Services, ist für Mission Critical Anwendungen nicht
akzeptabel. Eine Verbesserung der Zuverlässigkeit kann duch redundante Zentralen
(Ansprüche 24 bis 26) oder redundante System-Services (Anspruch 27 bis 38) erreicht
werden.
Ein Netzwerksystem nach Ansprüchen 24 bis 26 besitzt zwei oder mehrere redundante
Zentralen, zu welchen die Peripherieprozesse gleichzeitig parallele Verbindungen auf
bauen können. Bei Ausfall einer Zentrale leiten die Peripherieprozesse unmittelbar ihre
Nachrichtenströme über eine der anderen Zentralen, so daß das Gesamtsystem ohne
Totzeit weiterarbeitet. Nach Wiederverfügbarkeit der ausgefallenen Zentrale bauen alle
Peripherieprozesse ihre Verbindung zu der wieder zur Verfügung stehenden Zentrale
erneut auf, wonach das Gesamtsystem wieder seinen ursprünglichen Zustand erreicht.
Abb. 5 illustriert ein Beispiel eines Netzwerksystems nach Ansprüchen 2 und 24 bis
26. Zentrale Z bildet die primäre Zentrale des Systems, Zentrale Z' läuft zur Sicherheit
parallel zu Z im Hintergrund. Beide Zentralen werden von Guard G überwacht und im
Fehlerfall erneut gestartet. System-Service S2 unterhält parallele Verbindungen zu Z und
Z'. Service-Clients SC2 & SC3 wickeln ihren Nachrichtenverkehr zunächst ausschließ
lich über Z ab. Bei Ausfall von Z schalten sie selbsttätig auf Z' um und können ohne Aus
fallzeit weiter mit System-Service S2 kommunizieren. System-Services S1 & S3
dagegen unterhalten keine Verbindung zu Z' und sind nach einem Ausfall von Z nicht
mehr erreichbar. Guard G detektiert den Ausfall von Z und startet Z erneut. Sobald Z
wieder zur Verfügung steht, bauen G, S1-S3, SC1-SC3 ihre Verbindungen zu Z wieder
auf, wonach das System wieder in seinem ursprünglichen Zustand vollständig zur Verfü
gung steht. Service-Client SC1 ist ausschließlich mit Z verbunden und kann bei einem
Ausfall von Z mit keinem anderen Peripherieprozeß kommunizieren, solange bis Z wie
der zur Verfügung steht und alle Verbindungen zu Z erneut aufgebaut wurden.
Anspruch 27 kennzeichnet ein Netzwerksystem nach den vorherigen Ansprüchen des
sen Zuverlässigkeit durch redundante System-Services weiter erhöht werden kann. In
einem solchen System können mehrere gleichartige System-Services gleichzeitig mit
einer oder mehreren Zentralen verbunden sein. Jede Zentrale ordnet allen gleichartigen
System-Services, welche gleichzeitig mit ihr verbunden sind, dieselbe logische Kennung
- Service-Kennung genannt - zu. Schickt ein Service-Client eine Transaktionsaufforde
rung an diese Service-Kennung, bestimmt die Zentrale, zu welchen System-Services die
Aufforderung weitergeleitet und wie das Transaktionsresultat ermittelt werden soll.
Zur Bestimmung des Transaktionsresultates bei redundanten System-Services, gibt es
mehrere Strategien, welche in den Ansprüchen 28 bis 38 beschrieben sind.
- 1. Jede Zentrale leitet die Transaktionsaufforderung an genau einen der mit ihr ver bundenen gleichartigen System-Services weiter, welcher anschließend die Trans aktion ausführt und gegebenenfalls das Resultat an den Service-Client sendet (Anspruch 28).
- 2. Jede Zentrale leitet die Transaktionsaufforderung an mindestens einen der mit ihr verbundenen gleichartigen System-Services weiter (Anspruch 29). In diesem Fall schickt jeder der System-Services, welcher die Transaktionsaufforderung erhalten hat, gegebenenfalls ein Transaktionsresultat an die Zentrale. Ansprüche 30 bis 34 beschreiben, wie aus den gegebenenfalls mehreren Transaktionsresultaten das endgültige Transaktionsresultat ermittelt werden kann.
- 3. Jede Zentrale leitet die Transaktionsaufforderung an alle mit ihr verbundenen gleichartigen System-Services weiter und bestimmt genau einen der gleichartigen System-Services als Master-System-Service, welcher gegebenenfalls das Trans aktionsresultat an den Service-Client sendet (Ansprüche 35 bis 38).
Bei redundanten System-Services ist es besonders vorteilhaft, wenn die Transaktionsre
sultate von keinen durch vorherige Transaktionen bestimmten internen Daten eines
System-Services abhängen. In diesen Fällen ist es unerheblich, welcher der redundan
ten System-Service die Transaktion ausführt.
Hängt dagegen das Resultat der durchzuführenden Transaktion von internen Daten des
System-Services ab, welche sich gegebenenfalls aus vorherigen Transaktionen erge
ben, müssen die internen Daten aller gleichartigen System-Services stets untereinander
synchronisiert werden, da sonst verschiedene gleichartige System-Services verschie
dene Transaktionsresultate zu derselben Transaktion liefern würden und nicht gegenein
ander ausgetauscht werden können.
Den Vorgang der Synchronisierung der internen Daten gleichartiger System-Services
betreffen Ansprüche 36 und 38. Die Zentrale leitet zu diesem Zweck alle Transaktions
aufforderungen an alle gleichartigen System-Services derselben Service-Kennung wei
ter, woraufhin alle gleichartigen System-Services ihre internen Daten aktualisieren
(Anspruch 36). Damit ist zwar die fortlaufende Aktualisierung der internen Daten gleich
artiger System-Services gesichert, jedoch noch nicht ihre tatsächliche Übereinstimmung,
da die System-Services eventuell von verschiedenen Datenständen ausgegangen sind
oder eine oder mehrere Transaktionsaufforderungen nicht erhalten haben, z. B. wegen
temporärem Ausfall. Erst der direkte Abgleich der internen Daten zwischen Master-
System-Service und Hintergund-System-Services (Anspruch 38) garantiert, daß alle
gleichartigen System-Services zu einem gegebenen Zeitpunkt über dieselben internen
Daten verfügen. Der beste Zeitpunkt für einen solchen Abgleich ist unmittelbar nach dem
Start eines Hintergrund-System-Service. Auch ein regelmäßiger Datenabgleich, z. B.:
während transaktionsarmen Zeiträumen, ist trotz des sequentiellen Nachführens von
Zeit zu Zeit aus Konsistenzgründen vorteilhaft. Mit Hilfe des punktuellen Abgleiches und
dem sequentiellen Fortschreiben kann gewährleistet werden, daß die internen Daten
gleichartiger System-Services zu jedem Zeitpunkt übereinstimmen. Dies ist eine wichtige
Voraussetzung damit gleichartige System-Services mit internen Daten zu jedem Zeit
punkt gegeneinander ausgetauscht werden können.
Master-System-Services gelten nur für die jeweilige Verbindung zu einer bestimmten
Zentrale als solche. Ist ein System-Service mit mehreren Zentralen verbunden, kann er
durchaus bei der einen Zentrale als Master-System-Service agieren und bei der anderen
als Hintergrund-System-Service.
Bei Ausfall eines Master-System-Service bestimmt die Zentrale automatisch einen der
gleichartigen Hintergrund-System-Services als neuen Master-System-Service. Dieser
Vorgang erfolgt für die Service-Clients vollkommen transparent und praktisch ohne Tot
zeit. Nach Neustart des ausgefallenen System-Services, meldet sich dieser wieder bei
allen Zentralen an, mit welchen er vorher verbunden war. Existiert zu diesem Zeitpunkt
noch kein Master-System-Service dergleichen Art an einer Zentrale, erfolgt die Wieder
anmeldung an dieser Zentrale als Master-System-Service, andernfalls im Hintergrund-
Modus. Anschließend steht das System wieder in seiner ursprünglichen Konfiguration
vollständig zur Verfügung.
Alternativ zu dem beschriebenen Verfahren zur Synchronisierung der internen Daten
gleichartiger System-Services besteht die Möglichkeit, diese Daten nicht intern innerhalb
eines System-Services zu speichern, sondern an einem von allen anderen gleichartigen
System-Services zugänglichen Ort. Dies könnte beispielsweise ein nichtflüchtiges Spei
chermedium oder ein anderer System-Service sein. In diesen Fällen können die gleich
artigen System-Services wie nach Anspruch 28 behandelt werden.
Abb. 6 stellt eine spezielle Implementierung eines Netzwerksystems nach
Anspruch 27 dar. In diesem System werden zwei System-Services vom Typ S2 parallel
ausgeführt (S2 und S2'). Beide bauen sowohl Verbindungen zur Zentrale Z als auch zur
Backup-Zentrale Z' auf und erhalten von Z und Z' die Service-Kennung "S2" zugeordnet.
Zunächst leitet Zentrale Z alle Transaktionsaufforderungen an Service-Kennung "S2" an
S2 weiter. Bei Ausfall von S2 werden alle weiteren Transaktionsaufforderungen automa
tisch an S2' umgeleitet und ausgeführt. Nach erneutem Start verbindet sich S2 wieder
mit Z und Z', wonach die Transaktionen wieder durch S2 durchgeführt werden können.
Das Beispiel übersteht auch den gleichzeitigen Ausfall von Z und S2, da mit Z' und S2'
unmittelbar verfügbare Alternativen bereitstehen. Dies gilt jedoch nicht für System-Ser
vices S1 und S3, da sie nicht mit Z' verbunden sind und nach einem Ausfall von Z nicht
mehr erreichbar sind.
Die maximale Anzahl von Peripherieprozessen, welche mit einer Zentrale gleichzeitig
verbunden sein können, ist mindestens durch die der Zentralen zur Verfügung stehen
den Ressourcen (wie z. B.: Hauptspeicherkapazität oder Anzahl der Verbindungsend
punkte) nach oben beschränkt. Werden mehr Peripherieprozesse benötigt als eine
Zentrale handhaben kann, besteht die Möglichkeit mehrere Netzwerksysteme mit eige
nen Zentralen parallel laufen zu lassen. Eine solche Konfiguration bildet jedoch noch
kein Gesamtsystem, sondern lediglich eine Menge unabhängiger Einzelsysteme, welche
nicht untereinander kommunizieren können.
Ansprüche 39 bis 68 beschreiben Netzwerksysteme, welche mindestens aus zwei unter
einander zu einer beliebigen Topologie verbundenen Subsystemen bestehen. Dabei
kann die Verbindung der Zentralen der Subsysteme - Subzentralen genannt - direkt
(Anspruch 39) oder indirekt über einen Peripherieprozeß - Link genannt - (Anspruch 40)
erfolgen. Ansprüche 41 bis 45 betreffen die eindeutige Identifizierung der Subzentralen,
Links und Peripherieprozesse in einem aus mehreren Subsystemem aufgebauten Netz
werksystem, Ansprüche 46 bis 54 die Weiterleitung der Nachrichten vom Subsystem des
Senders zu den Empfängern in anderen Subsystemen, Ansprüche 55 und 56 den Spezi
alfall von Ringtopologien, Ansprüche 57 bis 64 die Kriterien - Politik genannt -, unter wel
chen Nachrichten an ein anderes Subsystem weitergeleitet werden dürfen, Ansprüche
65 und 66 die Möglichkeit, daß ein Peripherieprozeß gleichzeitig mit den Zentralen meh
rerer Subsysteme verbunden ist und Ansprüche 67 und 68 schließlich die logische Struk
tur - d. h. dis Topologie und/oder die Übertragungspolitiken der Links bzw. der Zentralen
und/oder die Authorisierungsprüfungen innerhalb der Zentralen - des gesamten Netz
werksystems.
Erst ein Netzwerksystem mit direkten oder indirekten Verbindungen zwischen den Zen
tralen der Einzelsysteme sowie einer Weiterleitung der Nachrichten über diese Verbin
dungen ermöglicht den Peripherieprozessen verschiedener Einzelsysteme unter
einander zu kommunizieren. Die Art der logischen Vernetzung der Einzelsysteme (logi
sche Topologie) kann unter Beachtung der Ressourcenbeschränkungen jeder einzelnen
Zentrale beliebig gewählt und an die besonderen Anfordernisse einer konkreten Anwen
dung angepaßt werden. Dabei definiert die logische Topologie zusammen mit der Über
tragungspolitik einzelner Links bzw. Zentralen, welche Nachrichten von welchen
Peripherieprozessen eines Subsystems an welche Peripherieprozesse eines anderen
Subsystems weitergeleitet werden dürfen.
Die Weiterleitung der Nachrichten zu Empfängern in anderen Subsystemen als das Sub
systems des Senders, setzt natürlich voraus, daß die Empfänger eindeutig durch den
Sender spezifiziert werden können. Da die logischen Kennungen der Peripheriepro
zesse bzw. deren Verbindungen nach den Ansprüchen 2 bis 38 nur innerhalb einer Zen
trale definiert sind, kann die Adressierbarkeit aller Peripherieprozesse bzw. deren
Verbindungen innerhalb des gesamten Netzwerkes nur durch zusätzliche Maßnahmen
erreicht werden. Zu diesem Zweck sind mehrere Methoden anwendbar, welche auch die
Weiterleitung der Nachrichten bestimmen bzw. von ihr abhängen:
- 1. Jede Zentrale besitzt mindestens eine in ihrer unmittelbaren Umgebung - d. h. für
alle mit der Zentrale direkt oder indirekt verbundenen Zentralen - eindeutige Ken
nung. In diesem Fall ist ein Pfad zwischen Sender und Empfänger eindeutig durch
die Folge der Zentralen beschrieben, über welche die Nachricht weitergeleitet wer
den muß, um von der Zentrale des Senders die Zentrale des Empfängers zu errei
chen (Ansprüche 46 und 47). Sicherer, aber nicht zwingend notwendig, ist natürlich
eine im gesamten Netzwerk eindeutige Kennung jeder Zentrale.
Falls zusätzlich jeder Peripherieprozeß oder dessen Verbindungen über im gesam ten Netzwerk eindeutige logische Kennungen verfügt(en) - periphere Kennungen genannt -, läßt sich in jeder Subzentrale eine Routingdatenbasis speichern, welche zu jeder peripheren Kennung den Pfad zu der entsprechenden Subzentrale enthält (Anspruch 49), so daß die Sender zur Spezifikation der Empfänger lediglich die peripheren Kennungen angeben müssen und die Subzentrale des Senders die peripheren Kennungen der Nachrichtenempfänger über die Routingdatenbasis in reale Pfade umsetzen kann, um sie anschließend den Pfaden der Empfänger ent sprechend weiterzuleiten (Ansprüche 51 und 52). - 2. Jeder Link besitzt eine innerhalb seiner unmittelbaren Umgebung - d. h. für alle mit
dem Link verbundenen Zentralen - eindeutige Kennung und verbindet genau zwei
Zentralen untereinander (Anspruch 48). Eine lokal eindeutige Kennung der Zentra
len oder global eindeutige Kennung der Links ist nicht erforderlich, da jeder Link
Nachrichten von einer Zentrale stets an die (eindeutig bestimmte) andere mit ihm
verbundene Zentrale weiterleitet. In diesem Fall ist der Pfad zwischen Sender und
Empfänger eindeutig durch die Folge der lokalen Linkkennungen beschrieben,
über welche die Nachricht weitergeleitet werden muß, um von der Zentrale des
Senders die Zentrale des Empfängers zu erreichen.
Falls zusätzlich jede periphere Kennung im gesamten Netzwerk eindeutig ist, läßt sich wie unter 1. in jeder Subzentrale eine Routingdatenbasis speichern, welche zu jeder peripheren Kennung den Pfad zu der entsprechenden Subzentrale enthält (Anspruch 50), so daß die Sender zur Spezifikation der Empfänger lediglich die peripheren Kennungen angeben müssen und die Subzentrale des Senders die peripheren Kennungen der Nachrichtenempfänger über die Routingdatenbasis in reale Pfade umsetzen kann, um sie anschließend den Pfaden der Empfänger ent sprechend weiterzuleiten (Anspruch 53). - 3. Jede periphere Kennung ist von sich aus im gesamten Netzwerk eindeutig. Die periphere Kennung alleine spezifiziert jedoch nicht, mit welcher Zentrale der Emp fänger verbunden und wie diese Zentrale von einer anderen Zentrale zu erreichen ist. Da ferner weder Links noch Zentralen in diesem Fall eine spezielle Kennung besitzen, kann die Nachricht nur dann zuverlässig an alle Empfänger zugestellt werden, wenn sie sukkzessive von einer Zentrale an die nächste weitergeleitet wird und jede Zentrale die Nachricht an alle mit ihr verbundenen Empfänger weiterleitet, solange bis die Nachricht an alle Empfänger weitergeleitet wurde, oder alle Zentra len im Gesamtsystem die Nachricht mindestens einmal erhalten haben. Dies setzt natürlich voraus, daß alle Zentralen im gesamten System die Nachricht nach einer endlichen Anzahl von Weiterleitungen mindestens einmal erhalten. Aus Gründen der Effizienz ist diese Methode nur sinnvoll für Ringtopologien mit relativ wenigen Subsystemen anwendbar (Ansprüche 55 und 56).
Anspruch 54 deckt den Fall ab, daß die Subzentralen die Routingdatenbasis untereinan
der austauschen und ihre eigene in Abhängigkeit der anderen anpassen, um zum Bei
spiel Änderungen der System-Konfiguration nachzuvollziehen.
Bei allen oben erwähnten Methoden zur Weiterleitung der Nachrichten zwischen ver
schiedenen Subsystemen ist zu beachten, daß verschiedene zwischen Sender und
Empfänger mögliche Pfade im allgemeinen nicht äquivalent sind, da sie sich einerseits in
ihrer Länge und andererseits in der Übertragungspolitik unterscheiden können (Ansprü
che 57 und 58). So kann die Weiterleitung einer Nachricht beispielsweise nach einem
Pfad erlaubt sein, ein Link bzw. eine Zentrale innerhalb eines anderen möglichen Pfa
des zwischen demselben Sender und demselben Empfänger die Weiterleitung hingegen
verbieten.
Nur falls die Übertragungspolitik aller Zentralen und Links im gesamten Netzwerkes
übereinstimmt (Anspruch 59), sind verschiedene Pfade zwischen demselben Sender
und demselben Empfänger äquivalent, so daß bekannte automatische Routingalgorith
men, welche z. B.: stets den zeitlich oder entfernungsmäßig kürzesten Pfad zwischen
Sender und Empfänger suchen, angewendet werden können.
Abb. 7 zeigt jeweils ein Netzwerksystem, welches aus zwei unabhängigen Subnet
zen S1 und S2 bestehen, die im Fall A über einen Link L nach Anspruch 40 bzw. im Fall
B durch eine direkte Verbindung LV zwischen den Zentralen nach Anspruch 39 miteinan
der verbunden sind, so daß Peripherieprozesse aus beiden Subsystemen untereinander
kommunizieren können. Die weiteren Kennzeichnungen der Abbildungen bedeuten im
einzelnen: SC11-SC13 die Service-Clients, S11-S13 die System-Services, G1 einen
Guard und Z1 die Zentrale von System S1, SC21-SC23 die Service-Clients, S21-S23 die
System-Services, G2 einen Guard und Z2 die Zentrale von System S2. KS1 und KS2 bil
den das jeweilige Kern-System der beiden Systeme. Falls es die Übertragungspolitik des
Links L bzw. der Zentralen gestattet, haben in den dargestellten Systemen beispiels
weise Service-Clients SC11-13 und System-Services S11-S13 Zugriff auf System-Ser
vices S21-S23. Allerdings benötigen Peripherieprozesse aus Subsystem S1 zur
Adressierung der System-Services in Subsystem S2 zusätzlich zu den logischen Ken
nungen der System-Services auch die logische Kennung der Zentrale Z2, damit der Link
L Nachrichten von Zentrale Z1 an Z2 (A) bzw Zentrale Z1 Nachrichten direkt an Z2 (B)
weiterleiten kann. Umgekehrt gilt dies natürlich auch für Peripherieprozesse aus Subsy
stem S2, welche System-Services von Subsystem S1 nutzen wollen.
Auf diese Weise lassen sich beispielsweise Prozeßsteuerungen vorteilhaft in zwei Berei
che aufteilen, einen weitgehend automatisierten Teilbereich, welcher im 24 h Betrieb lau
fen muß, und einen benutzerintensiven Teilbereich, welcher nicht ganz so hohe
Anforderungen an die Zuverlässigkeit stellt, wegen vielfältigerer Transaktionsmöglichkei
ten jedoch größere Sicherheitsrisiken als der automatisierte Teil birgt. Beide Teilbereiche
können durch verschiedene miteinander verbundene Subsysteme realisiert werden.
Dabei stellen die Verbindungen mit ihrer Politik sicher, daß nur authorisierte Benutzer
authorisierter Komponenten authorisierte Transaktionen aus dem benutzerintensivem
Teil in dem automatischen Teil durchführen können. Vorteilhaft sind in diesem Zusam
menhang zum Beispiel die Kontrolle wichtiger Systemparameter oder administrative Ein
griffe in den automatisierten Teil.
Links nach Anspruch 40 und Zentralen nach Anspruch 39 haben auch die Möglichkeit
parallele Verbindungen zu Zentralen von mehr als zwei verschiedenen Subsystemen
aufzubauen und je nach ihrer Politik alle Subsysteme untereinander zu verbinden. Die
maximale Anzahl der Zentralen, welche ein Link miteinander verbindet bzw. mit einer
Zentrale verbunden sein können, ist nur durch die Ressourcen des Links bzw. der Zen
trale(n) nach oben beschränkt.
Ein Ausführungsbeispiel eines Netzwerksystems mit einem Link, welcher gleichzeitig
vier Subsysteme untereinander verbindet ist in Abb. 8 wiedergegeben. Jeder Zen
trale ist eine eindeutige Kennung Z1-Z4 zugeordnet. Der Link L teilt jeder Zentrale mit,
welche anderen Zentralen über ihn zu erreichen sind. Die Adressierung erfolgt in diesem
Beispiel nach den eindeutigen Kennungen der Zentralen. So erreicht Service-Client
SC31 System-Service S11 über den Pfad Z3-Z1-S11. Z3 leitet Nachrichten mit Adresse
Z3-Z1-S11 an L weiter, da Z3 weiß, daß Z1 über L zu erreichen ist. Der Link leitet die
Nachricht an Z1 weiter und Z1 sendet sie schließlich mit der Kennung des Senders Z1-Z3-SC31
an S11. Nach demselben Mechanismus erreicht S11 SC31 über Z1-Z3-SC31.
Die folgenden Ausführungen gelten für alle Netzwerksysteme, welche aus mehreren
untereinander verbundenen Subsystemen bestehen, unabhängig davon, ob die Subsy
steme direkt oder indirekt verbunden sind. Sie seien der Einfachheit am Beispiel der Ver
bindungen mit Hilfe von Links formuliert, können aber sinngemäß unmittelbar auf direkt
verbundene Systeme übertragen werden, wobei jeder bivalente Link durch eine und
jeder multivalente Link durch mehrere direkte Verbindungen ersetzt werden muß.
Sollen n Subsysteme untereinander kommunizieren, muß ein Link bis zu n2 unidirektio
nale bzw. ½n2 bidirektionale Verbindungen unter den Subsystemen realisieren. Bei einer
großen Anzahl von Subsystemen führt dies leicht zu Übertragungsengpässen innerhalb
des Links. In solchen Fällen ist es sinnvoller, mehrere Links mit weniger Übertragungs
wegen vorzusehen, welche auf unterschiedlichen Einheiten ausgeführt werden und
gegebenenfalls optimierte physikalische Netzverbindungen nutzen können. Im Extrem
fall verbindet jeder Link nur zwei Zentralen miteinander, so daß bis zu ½n(n-1) Links
benötigt werden, um sicherzustellen, daß jedes Subsystem direkt mit jedem anderen
kommunizieren kann. Die Anzahl der notwendigen bivalenten Links kann durch geeig
nete Topologien reduziert werden. So erlaubt beispielsweise eine ringförmige Topologie
jedem Subsystem die Kommunikation mit allen anderen, wobei Nachrichten gegebenen
falls mehrfach weitergeleitet werden müssen.
Abb. 9 stellt ein Netzwerksystem nach Ansprüchen 55 und 56 dar, welches aus vier
über Links L in Ringtopologie untereinander verbundenen Subsystemen S1-S4 besteht.
Weder Links noch Zentralen sind logische Kennungen zugeordnet. Nachrichten, welche
SC31 an S11 schickt, werden von der Zentrale des Subsystems S3 über einen der bei
den Links an die nächste Zentrale (des Subsystems S2 oder S4) weitergeleitet. Diese
prüft ob die Nachricht lokale Empfänger besitzt und leitet die Nachricht in derselben
Richtung an die folgende Zentrale (Zentrale von S1) weiter. Letztere Zentrale leitet die
Nachricht schließlich an S11 weiter und vernichtet sie anschließend, wenn sie keine wei
teren Empfänger mehr enthält. Nachrichten, welche unbekannte Empfänger enthalten,
werden bis zur Zentrale des Sende-Systems (S3) weitergeleitet, welche die Nachricht
entweder direkt vernichtet oder mit den unbekannten Empfängern an den Sender
zurückschickt.
Die minimale Anzahl von Intersubsystem-Links erreicht man durch Einführung weiterer
Subssysteme analog zur sternförmigen Topologie im Falle der Kommunikation innerhalb
eines Subsystems. Abb. 10 illustriert dies am Beispiel von vier Subsystemen S1-S4,
welche durch ein zentrales Subsystem ZS untereinander verbunden sind. Alle Peri
pherieprozesse sind von allen anderen über maximal 3 Zentralen zu erreichen. Das zen
trale Subsystem ZS befindet sich logisch gesehen auf einer höheren Ebene als die
peripheren Subsysteme S1-S4, da von ihm aus alle Peripherieprozesse nur über maxi
mal 2 Zentralen erreichbar sind. S2 ist nicht nur auf direkte oder indirekte Verbindungen
zu anderen Subzentralen beschränkt, sondern kann auch System-Services (wie S1)
oder andere Peripherieprozesse enthalten, welche von den peripheren Subsystemen
aus über maximal 2 Zentralen erreichbar sind. So erreicht Service-Client SC11 System-
Service S1 über den Pfad Z1-Z-S1 und S21 über Z1-Z-Z2-S21 und Service-Client SC31
System-Service S11 über den Pfad Z3-Z-Z1-S11 und S21 über Z3-Z-Z2-S21. Umgekehrt
kann beispielsweise S21 an S11 über den Pfad Z2-Z-Z1-S11 antworten.
Durch Einführung weiterer Zwischenebenen, deren Subsysteme ihrerseits in frei wählba
rer Topologie miteinander verbunden sind, läßt sich ein erfindungsgemäßes Netzwerksy
stem nach einem der Ansprüche 39 oder 40 für beliebig viele Subsysteme und
Peripherieprozesse konfigurieren. Auch die gleichzeitige Verwendung direkter und indi
rekter Verbindungsmethoden ist nach Anspruch 40 in einem Gesamtsystem möglich.
Ein Peripherieprozeß nach einem der Ansprüche 65 oder 66, insbesondere ein System-
Service, besitzt die Möglichkeit parallele Verbindungen zu mehreren Zentralen verschie
dener Subsysteme aufzubauen. Dies geschieht am vorteilhaftesten indem der Periphe
rieprozeß für jede Verbindung einen separaten Thread startet. Mit Hilfe solcher
Peripherieprozesse lassen sich Netzwerksysteme realisieren, in welchen ansonsten dis
junkte Einzelsysteme auf gemeinsame System-Services zugreifen, ohne daß Nachrich
ten eines Einzelsystems an andere Einzelsysteme weitergeleitet werden können.
System-Services nach Ansprüchen 65 oder 66, stellen ihre Funktionalität allen Einzelsy
stemen zur Verfügung, zu welchen sie in Verbindung stehen, wobei sie innerhalb eines
Einzelsystems nicht von anderen System-Services zu unterscheiden sind. Auch die
Frage, ob ein System-Service ausschließlich einem Einzelsystem zur Verfügung steht
oder Verbindungen zu anderen Einzelsystemen unterhält, ist von anderen Peripheriepro
zessen des Einzelsystems nicht entscheidbar.
Abb. 11 stellt zwei Subsysteme S1 und S2 dar, welche nicht untereinander kommu
nizieren können, da ihre Zentralen Z1 und Z2 weder direkt noch über einen Link mitein
ander verbunden sind. System-Services GS1-GS3 unterhalten parallele Verbindungen
zu beiden Zentralen und sind somit in beiden Systemen gleichzeitig verfügbar. Dagegen
können System-Services S11, S12, S13 nicht von Service-Clients SC2x und System-
Services S21, S22 und S23 nicht von Service-Clients SC1y erreicht werden.
Eine besonders vorteilhafte Anwendung gemeinsamer System-Services ist Electronic-
Commerce: Ein Anbieter bietet System-Services an, welche parallele Verbindungen zu
mehreren Kunden-Einzelsystemen unterhalten. Die Kundensysteme können weder mit
einander kommunizieren noch kennen sie ihre gegenseitige Existenz. Dennoch können
alle Peripherieprozesse der Kunden-Einzelsysteme auf die angebotenen System-Ser
vices über stehende logische Verbindungen zugreifen, als ob sie alleiniger Bestandteil
eines Kunden-Einzelsystems seinen. Gleichzeitig kontrollieren die gemeinsamen
System-Services selbst, zu bzw. von welchen Einzelsystemen sie Verbindungen auf
bauen bzw. akzeptieren, so daß kein unauthorisierter Kunde Zugang zu den gemeinsa
men System-Services erhält. Diese Technik eröffnet vollkommen neue Märkte für
Online-System-Service-Anbieter.
Erfordert ein System-Service-Anbieter zusätzlich die Kontrolle über die jeweils aus den
verschiedenen Einzelsystemen getätigten Transaktionen, läßt sich besonders vorteilhaft
ein System nach Abb. 10 einsetzen, welches in zwei Hierarchieebenen aufgeteilt
ist. Hier könnte der System-Service-Anbieter im Zentralsystem ZS die angebotenen
System-Services zur Verfügung stellen. Jede Transaktion eines der Peripherieprozesse
der peripheren Subsysteme muß von Zentrale Z an die gemeinsamen System-Services
weitergeleitet werden und kann in Abhängigkeit von der Geschäftspolitik des Anbieters
von Z freigeschaltet oder blockiert werden. So hat der System-Service-Anbieter stets die
vollständige Kontrolle, welcher Peripherieprozeß welche Transaktionen mit den gemein
samen System-Services durchführen darf. Gleichzeitig kann Z sämtliche Transaktionen
beispielsweise zu Abrechnungs- oder Dokumentationszwecken protokollieren. Nachtei
lig gegenüber dem direkten Einsatz von gemeinsamen System-Services ist jedoch, daß
alle peripheren Subsysteme theoretisch mit allen im gemeinsamen Zentralsystem zur
Verfügung gestellten System-Services kommunizieren können, so daß nicht eine für
jeden Kunden spezifische Menge von System-Services angeboten werden kann. Aller
dings läßt sich dieser Nachteil auf der Ebene der Transaktionsauthorisierungen behe
ben.
Netzwerksysteme nach den beschriebenen Ansprüchen 1 bis 66 sind in dem Sinne
dynamisch, als ihre Zentralen zu jedem Zeitpunkt die Verfügbarkeit aller Peripheriepro
zesse und somit stets der aktuelle Zustand des Gesamtsystems bekannt ist. Derartige
Netzwerksysteme besitzen jedoch noch nicht die Fähigkeit, ihre logische Struktur - d. h.
ihre Topologie und/o 04509 00070 552 001000280000000200012000285910439800040 0002019918896 00004 04390der die Übertragungspolitiken der Links bzw. Zentralen und/oder die
Authorisierungsprüfungen innerhalb einer Zentrale und/oder die Zugangsbedingungen
der Zentralen oder Peripherieprozesse - selbständig oder auf Anforderung zu verändern
(Anspruch 67).
Ansprüche 68 bis 75 betreffen die Fähigkeit gezielt bestimmte System-Informationen
abzufragen (Ansprüche 69 bis 72) oder zu modifizieren (Ansprüche 68 und 73 bis 75).
In einem Netzwerksystem nach Ansprüchen 68 und 73 bis 75 haben die Zentralen und
Peripherieprozesse zusätzlich die Fähigkeit System-Informationen, welche die logische
Struktur des Gesamtsystems definieren, selbständig oder auf Anforderung zu modifizie
ren. Überwachen ein oder mehrere Peripherieprozesse gleichzeitig vorgegebene
Systemparameter, können sie die logische Struktur des Gesamtsystems im laufenden
Betrieb veränderten Umweltbedingungen, Systemanforderungen oder Systembelastun
gen anpassen. In einem Netzwerksystem nach Ansprüchen 68 und 73 bis 75 kann bei
spielsweise ein Peripherieprozeß die Informationsmenge, welche über vorgegebene
Verbindungen übertragen wird, sowie die Auslastung einzelner Zentralen oder System-
Services überwachen. Werden vorgegebene Grenzwerte über- bzw. unterschritten, ver
anlaßt dieser Peripherieprozeß, daß
- 1. eine weitere Zentrale mit allen erforderlichen System-Services und Verbindungen gestartet wird, oder
- 2. ein Subsystem gestoppt wird, oder
- 3. eine weitere zusätzliche Verbindung zwischen zwei nicht direkt miteinander ver bundenen Zentralen geschaffen wird, oder
- 4. bestehende Verbindungen zwischen Zentralen abgebaut werden.
Ansprüche 76 und 77 betreffen den Ort der Einheiten innerhalb bestehender physikali
scher Netzwerkinfrastrukturen, beispielsweise dem Internet oder ähnlichen Netzwerken.
Der Ort der Einheiten innerhalb eines Netzwerkes ist vor allem im Zusammenhang mit
Firewallschutzzonen von Bedeutung. Traditionelle Netzwerksysteme, welche nur einer
ausgewählten Benutzergruppe zugänglich sein sollen, können nicht frei im Internet aus
geführt werden, sondern müssen durch Firewalls vor unauthorisierten Zugriffen
geschützt werden. Dieser Nachteil wird durch erfindungsgemäße Netzwerksysteme - je
nach Ausführungsort "Private Inter-, Intra- oder Extranets" genannt - behoben, da der
Zugang zu den Peripherieprozessen und jede einzelne Nachricht durch die Zentralen
kontrolliert werden kann, so daß erfindungsgemäße Systeme beliebig verteilt im Internet
ausgeführt werden können ohne sich gegeneinander zu behindern und jedes erfin
dungsgemäße System nur einer ausgewählten Gruppe von Benutzern mit gegebenen
falls unterschiedlichen Rechten zugänglich ist.
Ansprüche 78 bis 81 betreffen das Interfacing zu bestehenden Netzwerksystemen nach
dem Stand der Technik. In diesen Fällen besteht mindestens eine Verbindung zwischen
mindestens einem erfindungsgemäßen Peripherieprozeß und mindestens einem Client
oder einem Server nach dem Stand der Technik, so daß erfindungsgemäße Peripherie
prozesse auf Daten oder Funktionen des Clients oder Servers nach dem Stand der Tech
nik zugreifen können, ohne direkte Verbindungen aufbauen zu müssen.
Besonders vorteilhaft ist in diesem Zusammenhang eine in Abb. 12 wiedergege
bene Ausführung. Ein externes erfindungsgemäßes System ES besitzt einen System-
Service S1, welcher durch einen Firewall eine Verbindung zu einem internen (geschütz
ten) Service nach dem Stand der Technik unterhält. Service-Client SC erhält über Zen
trale Z und S1 die Möglichkeit auf ausgewählte Daten oder Funktionen von S2
zuzugreifen, ohne eine eigene Verbindung durch den Firewall zu S2 aufzubauen. Die
Kontrolle, welche Daten und Transaktionen Service-Clients des externen Systems ES
erhalten bzw. durchführen dürfen, bestimmt zum einen die logische Struktur von Es, die
Funktionalitäten von S1 und S2 sowie der Firewall. Mit Hilfe eines solchen Systems läßt
sich die Anzahl der Verbindungen, welche durch den Firewall hindurch aufgebaut wer
den müssen, drastisch (im Idealfall auf genau eine) reduzieren, so daß der Firewall
wesentlich strengere Kriterien an den Verbindungsaufbau stellen kann und das interne
Netzwerk wesentlich besser schützt, als wenn alle externen Clients eigene Verbindun
gen zu bestehenden internen Services aufbauen.
Claims (81)
1. Netzwerksystem bestehend aus mindestens einer Zentraleinheit und einer beliebi
gen Anzahl physikalisch mit einer Zentraleinheit verbundenen Peripherieeinheiten,
dadurch gekennzeichnet, daß direkte Kommunikationsverbindungen unter den Ein
heiten zwischen Peripherieprozessen, welche auf einer Peripherieeinheit oder
einer Zentraleinheit ausgeführt werden, und mindestens einem auf einer Zentral
einheit ablaufenden Zentralprozeß - Zentrale genannt - aufbaubar sind, wobei
- a) zwischen jedem Peripherieprozeß und der Zentrale eine oder mehrere Kom munikationsverbindungen bestehen, und
- b) genannte Kommunikationsverbindungen nach ihrem Aufbau stehende logi sche bidirektionale Kommunikationsverbindungen sind, und
- c) die Zentrale mindestens einer Verbindung mindestens eines mit der Zentrale verbundenen Peripherieprozesses mindestens eine logische Kennung derart zuordnet, daß ein Peripherieprozeß allein aufgrund dieser logischen Ken nung(en) indirekt über die Zentrale mit mindestens einem Mitglied einer durch die logische Kennung(en) eindeutig bestimmten Gruppe von Peripheriepro zessen kommunizieren kann.
2. Netzwerksystem nach Anspruch 1, dadurch gekennzeichnet, daß
- a) mindestens eine Zentraleinheit eine im gesamten Netzwerksystem eindeutige physikalische Kennung besitzt, und
- b) mindestens eine Zentrale zu jedem Zeitpunkt einen freien Verbindungsend punkt zur Verfügung stellt, welcher Verbindungsendpunkt stets dieselbe auf der Zentraleinheit eindeutige lokale Kennung besitzt, und
- c) mindestens ein zum Auslösen eines Verbindungsaufbaues geeigneter Peri pherieprozeß Mittel enthält, um mit alleiniger Kenntnis der physikalischen Ken nung einer Zentraleinheit und der lokalen Kennung des Verbindungsend punktes einer Zentrale selbständig eine Kommunikationsverbindung zu genannter Zentrale aufzubauen, und
- d) die Zentrale nur Verbindungen von zum Auslösen eines Verbindungsauf baues geeigneten Peripherieprozessen akzeptiert, welche bestimmte beim Verbindungsaufbau und/oder zur Ausführungszeit bestehende Bedingungen, bezüglich der Ressourcen des Zentralprozesses und/oder der Art des Peri pherieprozesses, und/oder der Benutzerkennung unter welcher der Periphe rieprozeß ausgeführt wird, erfüllen und
- e) die Zentrale mindestens einer Verbindung zu einem zum Auslösen eines Ver bindungsaufbaus geeigneten Peripherieprozeß beim Verbindungsaufbau min destens eine logische Kennung derart zuordnet, daß ein zum Auslösen eines Verbindungsaufbaus geeigneter Peripherieprozeß allein aufgrund dieser logi schen Kennung(en) indirekt über die Zentrale mit mindestens einem Mitglied einer durch die logische Kennung(en) eindeutig bestimmten Gruppe von zum Auslösen eines Verbindungsaufbaus geeigneten Peripherieprozessen kom munizieren kann.
3. Netzwerksystem nach einem der Ansprüche 1 oder 2, dadurch gekennzeichnet,
daß
- a) mindestens ein zur Aufnahme einer Verbindung geeigneter Peripherieprozeß mindestens einen freien Verbindungsendpunkt zur Verfügung stellt, welcher Verbindungsendpunkt stets dieselbe, auf der den Peripherieprozeß ausfüh renden Einheit eindeutige, lokale Kennung besitzt, und
- b) der zur Aufnahme einer Verbindung geeignete Peripherieprozeß nur Verbin dungen von der Zentrale akzeptiert, und
- c) die Einheiten, welche mindestens einen zur Aufnahme einer Verbindung geeigneten Peripherieprozeß ausführen, eine im gesamten Netzwerksystem eindeutige physikalische Kennung besitzen, und
- d) mindestens eine Zentrale eine Datenbasis besitzt, die mindestens einen Ein trag für einen zur Aufnahme einer Verbindung geeigneten Peripherieprozeß enthält und jeder Eintrag der Datenbasis mindestens die physikalische Ken nung der Einheit sowie die lokale Kennung des Verbindungsendpunktes des entsprechenden zur Aufnahme einer Verbindung geeigneten Peripheriepro zesses enthält, und
- e) die Zentrale zum Auslösen eines Verbindungsaufbaus geeignet ist und selb ständig Verbindungen zu solchen zur Aufnahme einer Verbindung geeigneten Peripherieprozessen aufbaut; welche in der Datenbasis enthalten sind und welche bestimmte beim Verbindungsaufbau bzw. zur Ausführungszeit beste hende Bedingungen, bezüglich der Ressourcen des Zentralprozesses und/ oder der Art des zur Aufnahme einer Verbindung geeigneten Peripheriepro zesses, und/oder der Benutzerkennung unter welcher die zur Aufnahme einer Verbindung geeigneten Peripherieprozesse ausgeführt werden, erfüllen, und
- f) die Zentrale mindestens einer Verbindung zu einem zur Aufnahme einer Ver bindung geeigneten Peripherieprozeß beim Verbindungsaufbau mindestens eine logische Kennung derart zuordnet, daß ein zur Aufnahme einer Verbin dung geeigneter Peripherieprozeß allein aufgrund dieser logischen Ken nung(en) indirekt über die Zentrale mit mindestens einem Mitglied einer durch die logische Kennung(en) eindeutig bestimmten Gruppe von zur Auf nahme einer Verbindung geeigneten oder zum Auslösen eines Verbindungs aufbaus geeigneten Peripherieprozessen kommunizieren kann.
4. Netzwerksystem nach Anspruch 2, dadurch gekennzeichnet, daß jede Peripherie
einheit, welche einen zum Auslösen eines Verbindungsaufbaues geeigneten Peri
pherieprozeß ausführt, eine im gesamten Netzwerk eindeutige physikalische
Kennung besitzt und die Zentrale nur Verbindungen von solchen zum Auslösen
eines Verbindungsaufbaues geeigneten Peripherieprozessen akzeptiert, welche
zusätzlich bestimmte beim Verbindungsaufbau und/oder zur Ausführungszeit
bestehende Bedingungen, bezüglich der Einheiten, auf welcher die zum Auslösen
eines Verbindungsaufbaues geeigneten Peripherieprozesse ausgeführt werden,
erfüllen.
5. Netzwerksystem nach einem der vorherigen Ansprüche, dadurch gekennzeichnet,
daß die logische(n) Kennung(en), welche eine Verbindung zu einem Peripheriepro
zeß beim Verbindungsaufbau von einer Zentrale zugeordnet bekommt, in genann
ter Zentrale für den jeweiligen Peripherieprozeß eindeutig ist(sind), so daß ein
Peripherieprozeß über eine Verbindung allein aufgrund dieser logischen Ken
nung(en) indirekt über die Zentrale mit einem eindeutig bestimmten Peripheriepro
zeß kommunizieren kann.
6. Netzwerksystem nach einem der vorherigen Ansprüche, dadurch gekennzeichnet,
daß die logische(n) Kennung(en), welche eine Verbindung zu einem Peripheriepro
zeß beim Verbindungsaufbau von einer Zentrale zugeordnet bekommt, in genann
ter Zentrale eindeutig ist(sind), so daß ein Peripherieprozeß über eine Verbindung
allein aufgrund dieser logischen Kennungen indirekt über die Zentrale mit eindeutig
bestimmten Verbindungen eines Peripherieprozesses kommunizieren kann.
7. Netzwerksystem mit einer nach einem der Ansprüche 2 oder 4 gearteten Zentrale,
dadurch gekennzeichnet, daß die Bedingungen für die Akzeptanz einer Verbindung
- Zugangsbedingungen genannt - seitens der Zentrale während der Laufzeit des
Systems veränderbar sind, und die Zentrale unmittelbar nach Neufestlegung der
Zugangsbedingungen
- a) Verbindungen zu bereits verbundenen Peripherieprozessen, welche die neu festgelegten Zugangsbedingungen nicht mehr erfüllen, automatisch trennt,
- b) Verbindungen zu bereits verbundenen Peripherieprozessen, welche nach den neuen Zugangsbedingungen erlaubt sind, bestehen läßt, und
- c) zuvor unverbundene Peripherieprozesse, welche die neuen Zugangsbedin gungen erfüllen, bei einem künftigen Verbindungsaufbau akzeptiert.
8. Netzwerksystem nach Anspruch 3, dadurch gekennzeichnet, daß die Zugangsbe
dingungen seitens der Zentrale oder der Peripherieprozesse während der Laufzeit
des Systems veränderbar sind, und die Zentrale unmittelbar nach Neufestlegung
der Zugangsbedingungen
- a) Verbindungen zu bereits verbundenen Peripherieprozessen, welche die neu festgelegten Zugangsbedingungen nicht mehr erfüllen, automatisch trennt,
- b) Verbindungen zu bereits verbundenen Peripherieprozessen, welche nach den neuen Zugangsbedingungen erlaubt sind, bestehen läßt, und
- c) nach den neuen Zugangsbedingungen erlaubte Verbindungen zu bisher unverbundenen zur Aufnahme einer Verbindung geeigneten Peripheriepro zessen, welche in der Datenbasis der Zentrale enthalten sind, selbständig aufbaut.
9. Netzwerksystem nach einem der vorherigen Ansprüche, dadurch gekennzeichnet,
daß nach Anspruch 2 oder 4 geartete Peripherieprozesse ihre Verbindungen zur
Zentrale im Falle einer Verbindungsunterbrechung selbständig wieder herstellen.
10. Netzwerksystem nach einem der vorherigen Ansprüche, dadurch gekennzeichnet,
daß eine nach Anspruch 3 geartete Zentrale die Verbindung zu einem nach
Anspruch 3 gearteten Peripherieprozeß im Falle einer Verbindungsunterbrechung
selbständig wieder herstellt.
11. Netzwerksystem nach den vorherigen Ansprüchen, dadurch gekennzeichnet, daß
die Zentrale Nachrichten, welche ein Peripherieprozeß - Sender genannt - über
eine Verbindung - Sendeverbindung genannt - an die Zentrale schickt und welche
Nachrichten die logische Kennung mindestens einer Verbindung eines Peripherie
prozesses - Empfangsverbindung genannt - enthält, nach positiv ausgefallenen
Authorisierungsprüfungen via den in der Nachricht angegebenen Empfangsverbin
dungen an die entsprechenden Peripherieprozesse - Empfänger genannt - weiter
leitet.
12. Netzwerksystem nach den vorherigen Ansprüchen, dadurch gekennzeichnet, daß
die Zentrale Nachrichten, welche ein Sender an die Zentrale schickt und welche
keine logische Kennungen von Empfangsverbindungen enthalten, entweder ver
nichtet, speichert oder an die Sendeverbindung zurück sendet.
13. Netzwerksystem nach den vorherigen Ansprüchen, dadurch gekennzeichnet, daß
die Zentrale Nachrichten, welche ein Sender an die Zentrale schickt und welche
keine logische Kennungen von Empfängern enthalten, nach einer positiv ausgefal
lenen Authorisierungsprüfung an alle mit der Zentrale verbundenen Verbindungen
von Peripherieprozessen mit Ausnahme der Sendeverbindung weiterleitet.
14. Netzwerksystem nach einem der Ansprüche 11 bis 13, dadurch gekennzeichnet,
daß die Zentrale weiterzuleitende Nachrichten zusammen mit der logischen Ken
nung der Sendeverbindung an die Empfangsverbindungen weiterleitet.
15. Netzwerksystem nach einem der Ansprüche 11 bis 14, dadurch gekennzeichnet,
daß die Zentrale Nachrichten vernichtet, deren Authorisierungsprüfung negativ
ausfiel, und den Sender selbständig oder auf dessen Anforderung über die Ableh
nung der Weiterleitung seiner Nachricht unterrichtet.
16. Netzwerksystem nach einem der vorherigen Ansprüche, dadurch gekennzeichnet,
daß die Zentrale den Sender einer Nachricht selbständig oder auf dessen Anforde
rung über alle Empfänger informiert, zu welchen die Nachricht weitergeleitet wurde.
17. Netzwerksystem nach einem der vorherigen Ansprüche, dadurch gekennzeichnet,
daß die Zentrale den Sender einer Nachricht selbständig oder auf dessen Anforde
rung über alle Empfänger informiert, zu welchen die Nachricht nicht weitergeleitet
werden konnte.
18. Netzwerksystem nach einem der vorherigen Ansprüche, dadurch gekennzeichnet,
daß die Zentrale Nachrichten an bekannte aber temporär nicht mit ihr verbundene
Empfänger zwischenspeichert und die zwischengespeicherten Nachrichten auto
matisch oder auf Anforderung nach Wiederverbindung des temporär unverbunde
nen Empfängers mit der Zentrale in der Reihenfolge ihres Empfanges seitens der
Zentrale oder einer anderen Reihenfolge an den Empfänger weiterleitet.
19. Netzwerksystem nach einem der vorherigen Ansprüche, dadurch gekennzeichnet,
daß die Zentrale Nachrichten bekannter, aber temporär nicht mit ihr verbundener
Empfänger an den Sender zurückschickt oder vernichtet.
20. Netzwerksystem nach einem der vorherigen Ansprüche, dadurch gekennzeichnet,
daß mindestens ein Peripherieprozeß - System-Service genannt - nach dem Ver
bindungsaufbau über eine Verbindung - System-Service-Verbindung genannt - zur
Zentrale auf eine eintreffende Transaktionsaufforderung wartet, nach dem Eintref
fen einer solchen Aufforderung eine in Abhängigkeit von genannter Aufforderung
vordefinierte Aktion durchführt und gegebenenfalls nach Ausführen dieser Aktion
ein Resultat an den Sender der erwähnten Aufforderung sendet, anschließend auf
die nächste eintreffende Transaktionsaufforderung wartet und diesen Zyklus endlos
wiederholt.
21. Netzwerksystem nach Anspruch 20, dadurch gekennzeichnet, daß mindestens ein
Peripherieprozeß - Service-Client genannt - nach dem Verbindungsaufbau über
eine Verbindung - Service-Client-Verbindung genannt - zur Zentrale selbsttätig
oder auf Anforderung eine in Abhängigkeit seiner Aufgaben geartete Transaktions
aufforderung an einen oder mehrere System-Services sendet, gegebenenfalls
Resultate der System-Services empfängt und dies in Abhängigkeit seiner Aufga
ben und den erhaltenen Resultaten beliebig oft wiederholt.
22. Netzwerksystem nach einem der vorherigen Ansprüche, dadurch gekennzeichnet,
daß mindestens ein Peripherieprozeß - Guard genannt - in regelmäßigen oder
unregelmäßigen Abständen die Funktionalität der Zentrale oder einzelner oder
mehrerer Peripherieprozesse testet und im Falle einer Dysfunktion Maßnahmen
ergreift, um diese Dysfunktion zu beheben oder anderen Peripherieprozessen des
Netzwerksystems mitzuteilen.
23. Netzwerksystem nach einem der Ansprüche 20 bis 22, dadurch gekennzeichnet,
daß mindestens ein Peripherieprozeß nach mindestens zweien der Ansprüche 20
bis 22 geartet ist.
24. Netzwerksystem nach einem der vorhergehenden Ansprüche, dadurch gekenn
zeichnet, daß
- a) auf einer oder mehreren von allen Peripherieeinheiten erreichbaren Zentral einheiten, mehrere gleichartige Zentralprozesse parallel ausgeführt werden,
- b) von mindestens einem Peripherieprozeß nach einem der Ansprüche 2 oder 4
- insbesondere einem System-Service - mehrere parallele stehende Verbin
dungen zu einer oder mehreren Zentralen aufgebaut werden oder
zu mindestens einem Peripherieprozeß nach Anspruch 3 - insbesondere einem System-Service - mehrere parallele stehende Verbindungen von einer oder mehreren Zentralen aufgebaut werden.
25. Netzwerksystem nach Anspruch 24, dadurch gekennzeichnet, daß Peripheriepro
zesse nach einem der Ansprüche 2 oder 4 sich bei Ausfall einer Zentrale, mit wel
cher sie verbunden waren, automatisch mit mindestens einer der anderen
Zentralen verbinden.
26. Netzwerksystem nach Anspruch 24, dadurch gekennzeichnet, daß Guards meh
rere Zentralprozesse gleichzeitig überwachen.
27. Netzwerksystem nach einem der vorgehenden Ansprüche, dadurch gekennzeich
net, daß mehrere gleichartige System-Services gleichzeitig parallel ausgeführt wer
den und parallele stehende Verbindungen zu einer oder mehreren Zentralen
aufbauen bzw. von einer oder mehreren Zentralen akzeptieren, wobei jede Zentrale
allen gleichartigen System-Services mindestens eine für alle gleichartigen System-
Services der jeweiligen Zentrale identische logische Kennung - Service-Kennung
genannt - zuordnet, wobei die Service-Kennungen derselben System-Services in
verschiedenen Zentralen verschieden oder in allen Zentralen gleich sein können.
28. Netzwerksystem nach Anspruch 27, dadurch gekennzeichnet, daß jede Zentrale
alle an eine Service-Kennung gerichteten Nachrichten an genau einen der genann
ten gleichartigen System-Services mit derselben Service-Kennung weiterleitet und
derjenige System-Service, welcher die Transaktionsaufforderung erhalten hat, die
Transaktion durchführt und gegebenenfalls das Transaktionsresultat an den Ser
vice-Client sendet.
29. Netzwerksystem nach Anspruch 27, dadurch gekennzeichnet, daß jede Zentrale
alle an eine Service-Kennung gerichteten Transaktionsaufforderungen an minde
stens einen gleichartigen System-Services mit derselben Service-Kennung weiter
leitet.
30. Netzwerksystem nach Anspruch 29, dadurch gekennzeichnet, daß jeder System-
Service, welcher eine Transaktionsaufforderung erhält, die Transaktion ausführt
und gegebenenfalls ein Transaktionsresultat an den Service-Client sendet, wobei
der Service-Client nach Absendung einer Transaktionsaufforderung alle eintreffen
den Transaktionsresultate empfängt und das endgültige Transaktionsresultat in
geeigneter Weise bestimmt.
31. Netzwerksystem nach Anspruch 29, dadurch gekennzeichnet, daß die Zentrale die
Transaktionsresultate einer Transaktionsaufforderung aller gleichartigen System-
Services mit derselben Service-Kennung empfängt, und alle voneinander verschie
denen Transaktionsresultate zusammen mit ihrer Häufigkeitsverteilung an den Ser
vice-Client weiterleitet, der die Transaktionsaufforderung gesendet hat, und der
Service-Client daraus das endgültige Transaktionsresultat in geeigneter Weise
bestimmt.
32. Netzwerksystem nach Anspruch 29, dadurch gekennzeichnet, daß die Zentrale die
Transaktionsresultate einer Transaktionsaufforderung aller gleichartigen System-
Services mit derselben Service-Kennung empfängt, in geeigneter Weise das end
gültige Transaktionsresultat bestimmt, welches sie an den Service-Client weiterlei
tet, der die Transaktionsaufforderung gesendet hat.
33. Netzwerksystem nach einem der Ansprüche 30 bis 32, dadurch gekennzeichnet,
daß die Bestimmung des endgültigen Transaktionsresultates nach dem Mehrheits
prinzip - d. h. mehr als 50% der System-Services liefern das endgültige Resultat -
erfolgt und, falls keine Mehrheit zustandekommt, das Transaktionsresultat als
"unbestimmt" definiert wird.
34. Netzwerksystem nach einem der Ansprüche 30 bis 32, dadurch gekennzeichnet,
daß die Bestimmung des endgültigen Transaktionsresultates nach dem Proporz
prinzip - d. h. das häufigste Resultat wird endgültig - erfolgt und, falls mehrere
Resultate gleichhäufig auftreten, das Transaktionsresultat als "unbestimmt" defi
niert wird.
35. Netzwerksystem nach Anspruch 27, dadurch gekennzeichnet, daß jede Zentrale
alle an eine Service-Kennung gerichteten Transaktionsaufforderungen an alle
gleichartigen System-Services mit derselben Service-Kennung weiterleitet, und
daß jede Zentrale genau einen der gleichartigen System-Services als Master-
System-Service für die jeweilige Zentrale bestimmt wird, und daß der Master-
System-Senrice gegebenenfalls das Transaktionsresultat an einen Service-Client
sendet.
36. Netzwerksystem nach Anspruch 35, dadurch gekennzeichnet, daß alle gleicharti
gen System-Services einer Zentrale mit derselben Service-Kennung wie ein
Master-System-Service bis auf den Master-System-Service selbst nur zur Siche
rung des Master-System-Services im Hintergrund ausgeführt werden, und die
Transaktionsaufforderungen zum Abgleich ihrer internen Daten zwar empfangen
und gegebenenfalls verarbeiten, jedoch keine Transaktionsresultate an Service-Cli
ents senden.
37. Netzwerksystem nach Anspruch 36, dadurch gekennzeichnet, daß bei Abbruch der
Verbindung zwischen dem Master-System-Service einer Zentrale einer der gleich
artigen Hintergrund-System-Services mit derselben Service-Kennung wie der
Master-System-Service von der Zentrale als neuer Master-System-Service für
diese Zentrale derart bestimmt wird, daß das Gesamtsystem für alle Service-Cli
ents transparent ohne Unterbrechung fortfährt.
38. Netzwerksystem nach einem der Ansprüche 35 bis 37, dadurch gekennzeichnet,
daß ein im Hintergrund-Modus ausgeführter System-Service seine internen Daten
mit den internen Daten desjenigen Master-System-Service mit derselben logischen
Kennung des genannten Hintergrund-System-Services selbständig oder auf Anfor
derung mindestens einmal synchronisiert.
39. Netzwerksystem bestehend aus mindestens zwei Subnetzsystemen, dadurch
gekennzeichnet, daß jedes der Subnetzsysteme nach einem der Ansprüche 2 bis
38 ausgebildet ist, und daß die Subzentralen durch zueinander stehende bidirektio
nale Verbindungen zu einer beliebigen definierten Topologie verbindbar sind.
40. Netzwerksystem bestehend aus mindestens zwei Subnetzwerken, dadurch
gekennzeichnet, daß jedes der Subnetzsysteme nach einem der vorherigen
Ansprüchen ausgebildet ist, und daß die Subnetzsysteme durch spezielle Periphe
rieprozesse - Links genannt -, welche parallele Verbindungen zu zwei oder mehre
ren Subnetzwerkzentralen - Subzentralen genannt - aufbauen, zu einer beliebigen
definierten Topologie verbindbar sind.
41. Netzwerksystem nach einem der Ansprüche 39 oder 40, dadurch gekennzeichnet,
daß jede Subzentrale eine mindestens in ihrer unmittelbaren Umgebung - d. h. für
alle mit genannter Subzentrale direkt oder indirekt über genau einen Link verbun
denen Subzentralen - eindeutige logische Kennung besitzt.
42. Netzwerksystem nach Ansprüchen 40 und 41, dadurch gekennzeichnet, daß jeder
Link mindestens zwei Subzentralen miteinander verbindet und jeder Subzentrale,
mit welcher er verbunden ist mitteilt, welche anderen Subzentralen über genannten
Link zu erreichen sind.
43. Netzwerksystem nach Anspruch 40, dadurch gekennzeichnet, daß jeder Link eine
mindestens in seiner unmittelbaren Umgebung - d. h. für alle mit genanntem Link
verbundenen Subzentralen - eindeutige logische Kennung besitzt.
44. Netzwerksystem nach Anspruch 43, dadurch gekennzeichnet, daß jeder Link
genau zwei Zentralen verschiedener Subsysteme miteinander verbindet.
45. Netzwerksystem nach einem der Ansprüche 39 oder 40, dadurch gekennzeichnet,
daß jedem Peripherieprozeß eine im gesamten Netzwerksystem eindeutige logi
sche Kennung zugeordnet ist.
46. Netzwerksystem nach Anspruch 39 und 41, dadurch gekennzeichnet, daß die Sub
zentralen Nachrichten an Empfänger, welche mit anderen Subzentralen verbunden
sind als der Sender, an die Subzentralen der Empfänger weiterleiten, wobei jede
Adresse der Nachrichtenempfänger zusätzlich zur logischen Kennung des Empfän
gers eine eine oder mehrere Subzentralenkennungen umfassende Folge enthalten,
diese Folge beschreibt, über welche Subzentralen der Empfänger erreichbar ist,
und die Subzentralen die Nachrichten immer zur Subzentrale des jeweils in der
Folge nächsten Subnetzsystems weiterleiten, bis die Nachrichten die letzte Sub
zentrale der Folge erreicht haben und von letzterer Subzentrale zusammen mit der
umgekehrten Folge von Subzentralenkennungen an den Empfänger weitergeleitet
werden.
47. Netzwerksystem nach Anspruch 41 und 42, dadurch gekennzeichnet, daß die Sub
zentralen Nachrichten an Empfänger, welche mit anderen Subzentralen verbunden
sind als der Sender, an die Subzentralen der Empfänger weiterleiten, wobei jede
Adresse der Nachrichtenempfänger zusätzlich zur logischen Kennung des Empfän
gers eine eine oder mehrere Subzentralenkennungen umfassende Folge enthalten,
diese Folge beschreibt, über welche Subzentralen der Empfänger erreichbar ist,
und die Subzentralen Nachrichten immer an einen Link weiterleiten, über den die
jeweils in der Folge nächste Subzentrale erreichbar ist, und der Link die Nachrich
ten an letztere genannte Subzentrale weiterleitet, bis die Nachrichten diejenige
Subzentralen erreicht haben, mit welcher ihre Empfänger verbunden sind, und von
letzteren Subzentralen zusammen mit der umgekehrten Folge von Subzentralen
kennungen an die Empfänger weitergeleitet werden.
48. Netzwerksystem nach Anspruch 44, dadurch gekennzeichnet, daß die Subzentra
len Nachrichten an Empfänger, welche mit anderen Subzentralen verbunden sind
als der Sender, an die Subzentralen der Empfänger weiterleiten, wobei jede
Adresse der Nachrichtenempfänger zusätzlich zur logischen Kennung des Empfän
gers eine eine oder mehrere Linkkennungen umfassende Folge enthalten, diese
Folge beschreibt, über welche Links der Empfänger erreichbar ist, und die Subzen
tralen Nachrichten immer zum in der Folge nächsten Link weiterleiten, und dieser
Link die Nachrichten an die jeweils andere mit ihm verbundene Subzentrale weiter
leitet, bis die Nachrichten diejenige Subzentrale erreicht haben, mit welcher der
Empfänger verbunden ist, und von letzterer Subzentrale zusammen mit der umge
kehrten Folge von Linkkennungen an den Empfänger weitergeleitet werden.
49. Netzwerksystem nach Ansprüchen 41 und 45, dadurch gekennzeichnet, daß jede
Subzentrale über eine Routingdatenbasis verfügt, welche für jeden Peripheriepro
zeß des Gesamtsystems einen Eintrag mit einer Folge von Subzentralenkennun
gen enthält, über welche Subzentralen der Peripherieprozeß erreichbar ist.
50. Netzwerksystem nach Ansprüchen 44 und 45, dadurch gekennzeichnet, daß jede
Subzentrale über eine Routingdatenbasis verfügt, welche für jeden Peripheriepro
zeß des Gesamtsystems einen Eintrag mit einer Folge von Linkkennungen enthält,
und diese Folge beschreibt, über welche Links der Peripherieprozeß erreichbar ist.
51. Netzwerksystem nach Anspruch 49, dadurch gekennzeichnet, daß die Subzentrale
des Senders der logischen Kennung derjenigen Empfänger, welche mit anderen
Subzentralen verbunden sind als der Sender, die in dem Eintrag in der Routingda
tenbasis, welcher Eintrag dem jeweiligen Empfänger entspricht, enthaltene Folge
von Subzentralenkennungen hinzufügt, und die Subzentralen die Nachrichten
immer zur Subzentrale des jeweils in der Folge nächsten Subnetzsystems weiter
leiten, bis die Nachrichten die letzte Subzentrale der Folge erreicht haben und von
letzterer Subzentrale an den Empfänger weitergeleitet werden.
52. Netzwerksystem nach Anspruch 42 und 49, dadurch gekennzeichnet, daß die Sub
zentrale des Senders der in den Nachrichten enthaltenden logischen Kennung der
jenigen Empfänger, welche mit anderen Subzentralen verbunden sind als der
Sender, die in dem Eintrag in der Routingdatenbasis, welcher Eintrag dem jeweili
gen Empfänger entspricht, enthaltene Folge von Subzentralenkennungen hinzu
fügt, und die Subzentralen die Nachrichten anschießend immer an einen Link
weiterleiten, über den die jeweils in der Folge nächste Subzentrale erreichbar ist,
und der Link die Nachrichten an letztere genannte Subzentrale weiterleitet, bis die
Nachrichten diejenige Subzentrale erreicht haben, mit welcher ihre Empfänger ver
bunden sind, und von letzteren Subzentralen an die Empfänger weitergeleitet wer
den.
53. Netzwerksystem nach Anspruch 50, dadurch gekennzeichnet, daß die Subzentrale
des Senders der in den Nachrichten enthaltenden logische Kennung derjenigen
Empfänger, welche mit anderen Subzentralen verbunden sind als der Sender, die
in dem Eintrag in der Routingdatenbasis, welcher Eintrag dem jeweiligen Empfän
ger entspricht, enthaltene Folge von Linkkennungen hinzufügt, und die Subzentra
len die Nachrichten anschießend zum in der Folge nächsten Link weiterleiten, und
der Link die Nachrichten an die jeweils andere mit ihm verbundene Subzentrale
weiterleitet, bis die Nachrichten diejenige Subzentrale erreicht haben, mit welcher
der Empfänger verbunden ist, und von letzterer Subzentrale an den Empfänger
weitergeleitet werden.
54. Netzwerksystem nach einem der Ansprüche 51 bis 53, dadurch gekennzeichnet,
daß die Subzentralen die Routingdatenbasen selbständig oder auf Anforderung
untereinander austauschen und ihre eigenen Routingdatenbasis in Abhängigkeit
von den Routingdatenbasisn der anderen Subzentralen aktualisieren.
55. Netzwerksystem nach einem der Ansprüche 39 oder 40, dadurch gekennzeichnet,
daß die Subnetzsysteme zu einer Ringtopologie verbunden sind, so daß jede Sub
zentrale direkt oder über einen Link mit genau zwei anderen Subzentralen verbun
den ist, und durch unidirektionales Verfolgen der Subzentralen über diese
Verbindungen nacheinander alle Subzentralen des Gesamtsystems erreicht wer
den und schließlich die anfängliche Subzentrale wieder erreicht wird.
56. Netzwerksystem nach Ansprüchen 45 und 55, dadurch gekennzeichnet, daß die
Subzentralen Nachrichten an Empfänger, welche mit anderen Subzentralen ver
bunden sind als der Sender, an die Subzentralen der Empfänger weiterleiten,
wobei
- a) die Subzentrale des Senders die Nachrichten an eine beliebige mit ihr verbun dene Subzentrale bzw. Link weiterleitet,
- b) ein Link die Nachrichten an diejenige Subzentrale weiterleitet, von welcher er die Nachricht nicht empfangen hat,
- c) jede weitere Subzentrale die Nachrichten an die mit ihr verbundenen Empfän ger weiterleitet und, falls die Nachricht an weitere Empfänger gerichtet ist, die Nachrichten in derselben Richtung direkt oder über einen Link an die jeweils nächste Subzentrale weiterleitet, bis die Nachrichten an alle Empfänger wei tergeleitet wurden oder bis die Nachrichten die Subzentrale des Senders wie der erreicht haben und letztere Subzentrale die Nachrichten entweder an den Sender zurückschickt oder vernichtet.
57. Netzwerksystem nach einem der Ansprüche 39 bis 56, dadurch gekennzeichnet,
daß die Links oder Subzentralen eine Auswahl von Nachrichten, die von einem
Subnetzsystem zu einem anderen weitergeleitet werden dürfen, anhand von Krite
rien - Politik genannt - vornehmen.
58. Netzwerksystem nach Anspruch 57, dadurch gekennzeichnet, daß jeder Link oder
jede Subzentrale seine bzw. ihre eigene Politik besitzt.
59. Netzwerksystem nach Anspruch 57, dadurch gekennzeichnet, daß die Weiterlei
tung im gesamten Netzwerksystem nach derselben Politik erfolgt.
60. Netzwerksystem nach einem der Ansprüche 57 bis 59, dadurch gekennzeichnet,
daß die Politik der einzelnen Links und/oder Subzentralen während der Laufzeit
des Systems veränderbar ist.
61. Netzwerksystem nach einem der Ansprüche 57 bis 59, dadurch gekennzeichnet,
daß die Politik der einzelnen Links und/oder Subzentralen fest vorgegeben ist.
62. Netzwerksystem nach einem der Ansprüche 57 bis 60, dadurch gekennzeichnet,
daß die Links und/oder Subzentralen ihre Politik auf Anforderung oder selbständig
in regelmäßigen oder unregelmäßigen Abständen untereinander austauschen und
ihre eigene Politik in Abhängigkeit von den Politiken der anderen Links aktualisie
ren.
63. Netzwerksystem nach einem der Ansprüche 57 bis 62, dadurch gekennzeichnet,
daß die Politik der einzelnen Links und/oder Subzentralen mindestens von der
Qualität der Nachricht abhängt.
64. Netzwerksystem nach einem der Ansprüche 57 bis 63, dadurch gekennzeichnet,
daß die Politik der einzelnen Links und/oder Subzentralen mindestens von der Art
des Senders und/oder der Art des Empfängers und/oder dem Benutzer des Sen
ders und/oder dem Quellsystem und/oder dem Zielsystem und/oder der Übertra
gungseinrichtungen zwischen den Subnetzsystemen abhängt.
65. Netzwerksystem nach einem der Ansprüche 39 bis 64, dadurch gekennzeichnet,
daß mindestens ein Peripherieprozeß - insbesondere ein System-Service - nach
einem der Ansprüche 2 oder 4 gleichzeitig parallele Kommunikationsverbindungen
zu Zentralen mindestens zweier Subnetzsysteme aufbaut.
66. Netzwerksystem nach einem der Ansprüche 39 bis 65, dadurch gekennzeichnet,
daß mindestens ein Peripherieprozeß - insbesondere ein System-Service - nach
Anspruch 3 Verbindungen von den Zentralen mindestens zweier Subnetzsysteme
akzeptiert.
67. Netzwerksystem nach einem der vorherigen Ansprüche, dadurch gekennzeichnet,
daß die logische Struktur fest vorgegeben ist.
68. Netzwerksystem nach einem der vorherigen Ansprüche, dadurch gekennzeichnet,
daß die logische Struktur während der Laufzeit des Systems veränderbar ist.
69. Netzwerksystem nach einem der vorherigen Ansprüche, dadurch gekennzeichnet,
daß mindestens einem Peripherieprozeß die Informationen, welche Peripheriepro
zesse und/oder System-Services und/oder Links und/oder Zentralen mit welcher
Zentrale verbunden sind, zugänglich sind.
70. Netzwerksystem nach einem der vorherigen Ansprüche, dadurch gekennzeichnet,
daß mindestens einem Peripherieprozeß die Informationen, welchen Peripherie
prozessen und/oder System-Services und/oder Links und/oder Zentralen es erlaubt
ist, mit welcher Zentrale Verbindungen aufzubauen bzw. welche Zentrale zu wel
chen Peripherieprozessen und/oder System-Services und/oder Links und/oder
Zentralen Verbindungen aufbauen darf, zugänglich sind.
71. Netzwerksystem nach einem der vorherigen Ansprüche, dadurch gekennzeichnet,
daß mindestens einem Peripherieprozeß die Kriterien der Authorisierungsprüfun
gen, welche die Zentralen vor der Weiterleitung der Nachrichten durchführen, und/
oder die Übertragungspolitiken der Links und/oder Zentralen zugänglich sind.
72. Netzwerksystem nach einem der Ansprüche 69 bis 71, dadurch gekennzeichnet,
daß ein Peripherieprozeß, welchem die in einem der Ansprüche 69 bis 71 beschrie
benen System-Informationen zugänglich sind, ein System-Service ist und genann
ter System-Service genannte System-Informationen anderen Peripherieprozessen
zur Verfügung stellt.
73. Netzwerksystem nach Anspruch 68 und einem der Ansprüche 69 bis 71, dadurch
gekennzeichnet, daß mindestens ein Peripherieprozeß die in einem der Ansprüche
69 bis 71 beschriebenen System-Informationen modifizieren kann.
74. Netzwerksystem nach Anspruch 68 und 72, dadurch gekennzeichnet, daß der
System-Service, welchem die jeweiligen System-Informationen zugänglich sind,
die System-Informationen aufgrund einer Transaktionsaufforderung von einem Ser
vice-Client modifizieren kann.
75. Netzwerksystem nach einem der Ansprüche 73 oder 74, dadurch gekennzeichnet,
daß die betroffenen Zentralen und/oder Links und/oder Peripherieprozesse die
modifizierten System-Informationen unmittelbar übernehmen.
76. Netzwerksystem nach einem der vorherigen Ansprüche, dadurch gekennzeichnet,
daß mindestens eine Zentrale und/oder mindestens ein Peripherieprozeß außer
halb von allen Firewallschutzzonen ausgeführt wird/werden.
77. Netzwerksystem nach einem der vorherigen Ansprüche, dadurch gekennzeichnet,
daß mindestens eine Zentrale und/oder mindestens ein Peripherieprozeß innerhalb
von mindestens einer Firewallschutzzone ausgeführt wird/werden.
78. Netzwerksystem nach einem der vorherigen Ansprüche, dadurch gekennzeichnet,
daß mindestens ein Peripherieprozeß mindestens eine Verbindung zu mindestens
einem Service nach dem Stand der Technik - traditioneller Service genannt - auf
baut.
79. Netzwerksystem nach einem der vorherigen Ansprüche, dadurch gekennzeichnet,
daß mindestens ein Peripherieprozeß mindestens eine Verbindung von mindestens
einem Client nach dem Stand der Technik - traditioneller Client genannt - akzep
tiert.
80. Netzwerksystem nach einem der Ansprüche 78 oder 79, dadurch gekennzeichnet,
daß mindestens eine Verbindung zwischen einem Peripherieprozeß und einem tra
ditionellen Client und/oder traditionellen Service durch mindestens einen Firewall
hindurch führt.
81. Netzwerksystem nach einem der Ansprüche 78 bis 80, dadurch gekennzeichnet,
daß mindestens ein Peripherieprozeß, welcher mit mindestens einem traditionellen
Service und/oder Client verbunden ist, Daten oder Funktionen des(r) traditionellen
Service(s) und/oder Clients anderen Peripherieprozessen zur Verfügung stellt, so
daß genannte andere Peripherieprozesse Zugriff auf die Daten und Funktionen
des(r) traditionellen Services und/oder Clients erhalten ohne direkte Verbindungen
zu genanntem(n) traditionellen Service(s) und/oder Clients aufzubauen.
Priority Applications (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
DE29924093U DE29924093U1 (de) | 1999-04-26 | 1999-04-26 | Logisches Netzwerksystem (Interprozeßkommunikationssystem) |
DE19918896A DE19918896A1 (de) | 1999-04-26 | 1999-04-26 | Logisches Netzwerksystem |
EP00108706A EP1049013A2 (de) | 1999-04-26 | 2000-04-22 | Interprozesskommunikationssystem |
US09/558,435 US6807582B1 (en) | 1999-04-26 | 2000-04-25 | Interprocess communication system |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
DE19918896A DE19918896A1 (de) | 1999-04-26 | 1999-04-26 | Logisches Netzwerksystem |
Publications (1)
Publication Number | Publication Date |
---|---|
DE19918896A1 true DE19918896A1 (de) | 2000-11-02 |
Family
ID=7905891
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
DE19918896A Withdrawn DE19918896A1 (de) | 1999-04-26 | 1999-04-26 | Logisches Netzwerksystem |
Country Status (3)
Country | Link |
---|---|
US (1) | US6807582B1 (de) |
EP (1) | EP1049013A2 (de) |
DE (1) | DE19918896A1 (de) |
Families Citing this family (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7171434B2 (en) * | 2001-09-07 | 2007-01-30 | Network Appliance, Inc. | Detecting unavailability of primary central processing element, each backup central processing element associated with a group of virtual logic units and quiescing I/O operations of the primary central processing element in a storage virtualization system |
US7472231B1 (en) | 2001-09-07 | 2008-12-30 | Netapp, Inc. | Storage area network data cache |
FR2836731B1 (fr) * | 2002-03-01 | 2004-12-03 | Abdulai Danso | Procede pour la realisation et la mise en oeuvre d'un systeme de communication multifonctionnel et systeme obtenu conformement audit procede |
US20050182966A1 (en) * | 2004-02-17 | 2005-08-18 | Duc Pham | Secure interprocess communications binding system and methods |
JP4647392B2 (ja) * | 2005-05-23 | 2011-03-09 | 京セラ株式会社 | デバイス制御装置、デバイス制御方法およびプログラム |
US8056089B2 (en) * | 2006-11-07 | 2011-11-08 | International Business Machines Corporation | Shortcut IP communications between software entities in a single operating system |
US7941411B2 (en) * | 2007-06-29 | 2011-05-10 | Microsoft Corporation | Memory transaction grouping |
US8800002B2 (en) * | 2008-02-18 | 2014-08-05 | Microsoft Corporation | Inter-process networking for many-core operating systems |
US20100235515A1 (en) * | 2009-03-16 | 2010-09-16 | Posco Ict Company Ltd. | Method and apparatus for managing connection |
JP6056607B2 (ja) * | 2013-03-28 | 2017-01-11 | 富士通株式会社 | 情報処理システム及び情報処理システムの制御方法 |
JP6827327B2 (ja) * | 2017-01-05 | 2021-02-10 | 株式会社日立製作所 | 分散コンピューティングシステム |
Citations (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5274631A (en) * | 1991-03-11 | 1993-12-28 | Kalpana, Inc. | Computer network switching system |
DE4329172A1 (de) * | 1993-08-30 | 1995-03-02 | Sel Alcatel Ag | Verfahren zur Anruflenkung für ein privates, virtuelles Netz, sowie Dienstrechner und Vermittlungsstelle dafür |
DE19532421C1 (de) * | 1995-09-01 | 1996-12-12 | Philips Patentverwaltung | Lokales, nach dem asynchronen Transfermodus (ATM) arbeitendes Netzwerk zur Erzeugung von priorisierten Zellen |
US5596579A (en) * | 1993-10-01 | 1997-01-21 | International Business Machines Corporation | High performance machine for switched communications in a heterogeneous data processing network gateway |
DE19532422C1 (de) * | 1995-09-01 | 1997-01-23 | Philips Patentverwaltung | Lokales, nach dem asynchronen Transfermodus (ATM) arbeitendes Netzwerk mit wenigstens zwei Ringsystemen |
US5652751A (en) * | 1996-03-26 | 1997-07-29 | Hazeltine Corporation | Architecture for mobile radio networks with dynamically changing topology using virtual subnets |
EP0876067A1 (de) * | 1997-04-30 | 1998-11-04 | Alcatel | Virtuelle Privatnetze mit gemeinsamem Bestimmungsort |
EP0883310A2 (de) * | 1997-04-18 | 1998-12-09 | AT&T Corp. | Verfahren und Apparat zur Erstellung von virtuellen Multi-Netzwerk-Diensten |
EP0705463B1 (de) * | 1992-09-11 | 1999-05-06 | Memorylink, Inc. | System und verfahren zur leitweglenkung von daten und übertragung |
Family Cites Families (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5041963A (en) * | 1988-12-29 | 1991-08-20 | Intel Corporation | Local area network with an active star topology comprising ring controllers having ring monitor logic function |
US5287453A (en) * | 1990-09-18 | 1994-02-15 | Bull Hn Information Systems, Inc. | Fast remote file access facility for distributing file access requests in a closely coupled computer system |
US5644719A (en) | 1994-12-16 | 1997-07-01 | Unisys Corporation | Interprocess communication apparatus interposed between application processes and the operating systems of hosting computers in a system of networked computers |
US5909542A (en) * | 1996-11-20 | 1999-06-01 | Cfi Proservices, Inc. | Distributed computing system for executing intercommunicating applications programs |
-
1999
- 1999-04-26 DE DE19918896A patent/DE19918896A1/de not_active Withdrawn
-
2000
- 2000-04-22 EP EP00108706A patent/EP1049013A2/de not_active Withdrawn
- 2000-04-25 US US09/558,435 patent/US6807582B1/en not_active Expired - Fee Related
Patent Citations (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5274631A (en) * | 1991-03-11 | 1993-12-28 | Kalpana, Inc. | Computer network switching system |
EP0705463B1 (de) * | 1992-09-11 | 1999-05-06 | Memorylink, Inc. | System und verfahren zur leitweglenkung von daten und übertragung |
DE4329172A1 (de) * | 1993-08-30 | 1995-03-02 | Sel Alcatel Ag | Verfahren zur Anruflenkung für ein privates, virtuelles Netz, sowie Dienstrechner und Vermittlungsstelle dafür |
US5596579A (en) * | 1993-10-01 | 1997-01-21 | International Business Machines Corporation | High performance machine for switched communications in a heterogeneous data processing network gateway |
DE19532421C1 (de) * | 1995-09-01 | 1996-12-12 | Philips Patentverwaltung | Lokales, nach dem asynchronen Transfermodus (ATM) arbeitendes Netzwerk zur Erzeugung von priorisierten Zellen |
DE19532422C1 (de) * | 1995-09-01 | 1997-01-23 | Philips Patentverwaltung | Lokales, nach dem asynchronen Transfermodus (ATM) arbeitendes Netzwerk mit wenigstens zwei Ringsystemen |
US5652751A (en) * | 1996-03-26 | 1997-07-29 | Hazeltine Corporation | Architecture for mobile radio networks with dynamically changing topology using virtual subnets |
WO1997036444A1 (en) * | 1996-03-26 | 1997-10-02 | Hazeltine Corporation | An architecture for mobile radio networks with dynamically changing topology using virtual subnets |
EP0883310A2 (de) * | 1997-04-18 | 1998-12-09 | AT&T Corp. | Verfahren und Apparat zur Erstellung von virtuellen Multi-Netzwerk-Diensten |
EP0876067A1 (de) * | 1997-04-30 | 1998-11-04 | Alcatel | Virtuelle Privatnetze mit gemeinsamem Bestimmungsort |
Non-Patent Citations (3)
Title |
---|
"gated.proto(4)" Manpage Digital UNIX V4.0E * |
"inetd(8)"Manpage Digital UNIX V4.0E * |
"tcp(7)"Manpage Digital UNIX V4.0E * |
Also Published As
Publication number | Publication date |
---|---|
US6807582B1 (en) | 2004-10-19 |
EP1049013A2 (de) | 2000-11-02 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
DE60108927T2 (de) | Komputersysteme, insbesondere virtuelle private Netzwerken | |
EP1488611B1 (de) | Aaa serversystem zur effizienten zugangskontrolle und adresszuordnung | |
DE69933312T2 (de) | Auswahlsteuerung eines gateway-unterstützungsknotens | |
DE4430993C1 (de) | Verfahren zur adaptiven Wegesuche in einem Kommunikationsnetz | |
DE60317705T2 (de) | Verfahren und system zur cluster-verwaltung von netzwerkeinrichtungen | |
DE60122691T2 (de) | Verfahren und vorrichtung zum verteilten cachen | |
DE69334056T2 (de) | Kontrolleinrichtung zur Migrationskommunikation | |
DE60212289T2 (de) | Verwaltung privater virtueller Netze (VPN) | |
DE69818232T2 (de) | Verfahren und system zur verhinderung des herunterladens und ausführens von ausführbaren objekten | |
DE602005000025T2 (de) | Verfahren und Anordnung für den Betrieb eines offenen Netzwerks mit einem Proxy | |
DE112008002439T5 (de) | Architektur und Protokoll für die erweiterbare und skalierbare Kommunikation | |
EP1810523B1 (de) | Verfahren und produkte zum informationsabgleich zwischen manager und agent in einem managementnetz | |
DE19918896A1 (de) | Logisches Netzwerksystem | |
DE60127499T2 (de) | Routenaktualisierungsverfahren für ein Mikromobilitätsnetzwerk | |
EP3152884B1 (de) | Verfahren zur weiterleitung von daten zwischen computersystemen, computernetz-infrastruktur sowie computerprogramm-produkt | |
DE69812574T2 (de) | Verfahren und System zur Leitweglenkung von Agent-Programmen in einem Kommunikationsnetz | |
WO2020108998A1 (de) | Verteilerknoten, automatisierungsnetzwerk und verfahren zum übertragen von telegrammen | |
DE10332360B4 (de) | Verfahren und System zur Verwaltung und Übertragung von Ereignissen einer zu überwachenden technischen Anlage in einer web-basierten Client-Server-Umgebung | |
DE10024347B4 (de) | Sicherheitsservice-Schicht | |
WO2015185505A1 (de) | Verfahren zur verteilung von tasks zwischen computersystemen, computernetz-infrastruktur sowie computerprogramm-produkt | |
DE112004000125T5 (de) | Gesichertes Client-Server-Datenübertragungssystem | |
EP1977583B1 (de) | Verfahren zur Übermittlung einer Nachricht und Netzwerk | |
DE60303745T2 (de) | Mehrschichtiges Verfahren zum Verwalten von Multicast Teilnehmern | |
DE102011080676A1 (de) | Konfiguration eines Kommunikationsnetzwerks | |
EP1126677A2 (de) | Schutz von sicherheitskritischen Daten in Netzwerken |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
OP8 | Request for examination as to paragraph 44 patent law | ||
8122 | Nonbinding interest in granting licences declared | ||
8139 | Disposal/non-payment of the annual fee |