[go: up one dir, main page]

DE60100800T2 - Verfahren und einrichtung zur bereitstellung von einem hochverfügbaren computerdienst - Google Patents

Verfahren und einrichtung zur bereitstellung von einem hochverfügbaren computerdienst Download PDF

Info

Publication number
DE60100800T2
DE60100800T2 DE60100800T DE60100800T DE60100800T2 DE 60100800 T2 DE60100800 T2 DE 60100800T2 DE 60100800 T DE60100800 T DE 60100800T DE 60100800 T DE60100800 T DE 60100800T DE 60100800 T2 DE60100800 T2 DE 60100800T2
Authority
DE
Germany
Prior art keywords
server
session
user
servers
dtu
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.)
Expired - Fee Related
Application number
DE60100800T
Other languages
English (en)
Other versions
DE60100800D1 (de
Inventor
J. Robert BLOCK
G. James HANKO
Kent J. PEACOCK
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sun Microsystems Inc
Original Assignee
Sun Microsystems Inc
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Priority claimed from US09/513,015 external-priority patent/US7401114B1/en
Application filed by Sun Microsystems Inc filed Critical Sun Microsystems Inc
Publication of DE60100800D1 publication Critical patent/DE60100800D1/de
Application granted granted Critical
Publication of DE60100800T2 publication Critical patent/DE60100800T2/de
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1001Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004Server selection for load balancing
    • H04L67/1008Server selection for load balancing based on parameters of servers, e.g. available memory or workload
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1001Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1001Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1034Reaction to server failures by a load balancer
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1095Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/40Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass for recovering from a failure of a protocol instance or entity, e.g. service redundancy protocols, protocol state redundancy or protocol service redirection

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer And Data Communications (AREA)
  • Hardware Redundancy (AREA)

Description

  • HINTERGRUND DER ERFINDUNG
  • 1. BEREICH DER ERFINDUNG
  • Die vorliegende Erfindung bezieht sich auf den Bereich von vernetzten Computersystemen.
  • 2. HINTERGRUND DES STANDES DER TECHNIK
  • Computerbenutzer wünschen immer höhere Leistungen bei Computeranwendungen in sich ständig verändernden Computerumgebungen. Das Computerparadigma verschiebt sich. Neue Architekturen entstehen, die neue Lösungen erfordern, um mit dem Bedarf an Computeranwendungen hoher Leistung umzugehen. Eine solche Architektur ist die eines Thin-Client-Computersystems.
  • In der Thin-Client-Architektur ist die Funktionalität des Endbenutzer-Computers bis zu dem Punkt reduziert, daß zum größten Teil nur Eingabe- und Ausgabemöglichkeiten existieren. Der Endbenutzer-Computer ist über ein Computernetzwerk mit hoher Bandbreite mit einem leistungsfähigeren Server-Computer verbunden, der alle Funktionen durchführt, die traditionell einem Personalcomputer zugeordnet sind wie das Ausführen von Computerprogrammen und Verarbeiten von Daten.
  • Ein individueller Endbenutzer-Computer kann ein- und ausgeschaltet werden, und der Benutzer verliert keinen Zustand (z. B. die Dienste, die selbständig ablaufen, laufen weiter auf dem Server-Computer ab). In dieser Art von Architektur kann sich eine große Anzahl von Endbenutzern mit einer begrenzten Anzahl von Servern in dieser Weise verbinden, wobei mehrere Endbenutzer einen oder mehrere Computerprozesse auf demselben Server ausführen können. Ein dieser Architektur innewohnendes Problem ist die Gefahr, daß alle daran angeschlossenen Endbenutzerterminals ihren gesamten Zustand verlieren, wenn der zentrale Server-Computer herunter fährt (zum Beispiel während eines Stromausfalls). Dadurch sind die Terminals zu nichts zu gebrauchen, bis der zentrale Computer wieder verfügbar ist.
  • Die Entwicklung, die zu diesem Problem geführt hat, ist besser zu verstehen, wenn man die Entwicklung von Netzwerkverarbeitung Revue passieren läßt. Die Idee ist, daß Netzwerkcomputer auf D ten und Anwendungen über ein Computernetzwerk wie das Internet, ein Intranet, ein lokales Netzwerk oder ein Weitverkehrsnetzwerk zugreifen. Nur diejenigen Anwendungen, die für eine bestimmte Aufgabe benötigt werden, werden dem Netzwerkcomputer zur Verfügung gestellt. Wenn die Anwendungen nicht mehr benötigt werden, werden sie nicht auf dem Netzwerkcomputer gespeichert. Neuerdings hat sich eine neue Systemarchitektur von Computern entwickelt bzw. herausgebildet, die als die virtuelle Desktop-Architektur bezeichnet wird. Dieses System sorgt für eine Neuaufteilung der Funktionalität zwischen einer zentralen Server-Installation und der Benutzer-Hardware. Daten und Verarbeitungsfunktionalität werden von Datenquellen über eine zentralisierte Verarbeitungsanordnung bereitgestellt. Auf Seiten des Benutzers ist sämtliche Funktionalität im wesentlichen eliminiert außer derjenigen, die eine Ausgabe an den Benutzer erzeugt (z. B. eine Anzeige und Lautsprecher), Eingaben von dem Benutzer entgegennimmt (z. B. über eine Maus und eine Tastatur) oder andere Peripheriegeräte, mit denen der Benutzer interagieren kann (z. B. Scanner, Kameras, entfernbarer Speicher bzw. Wechselspeicher, etc.)
  • Sämtliche Verarbeitung wird von einem oder mehreren Servern verrichtet, die als zentrale Datenquellen dienen, und die Verarbeitung wird unabhängig von dem Ziel bzw. der Bestimmung der Daten, die erzeugt werden, vorgenommen. Die Ausgabe einer Datenquelle wird einem Tenninal übergeben, das hier als eine "Desktop-Einheit" (Desktop Unit, DTU) bezeichnet wird. Die DTU ist in der Lage, die Daten zu empfangen und die Daten anzuzeigen.
  • Die virtuelle Desktop-Systemarchitektur kann in Analogie zu anderen in hohem Maße aufgeteilten Systemen gesehen werden. Zum Beispiel hält eine öffentliche Telefongesellschaft leistungsfähige und hoch entwickelte Verarbeitungsleistung und große Datenbanken in Vermittlungsstellen vor. Jedoch ist die DTU (z. B. das Telefon) relativ einfach und erfordert keine Aktualisierung bzw. Aufrüstung, wenn neue Eigenschaften oder Dienste durch die Telefongesellschaft hinzugefügt werden. Das Telefon selbst wird zu einer Einrichtung bzw. einem Gerät mit niedrigen Kosten und veraltet extrem langsam. In ähnlicher Weise veraltet der Anzeigebildschirm der meisten Computersysteme kaum und kann typischerweise über die meisten Aktualisierungen bzw. Aufrüstungen von Desktop-Systemen hinweg beibehalten werden.
  • Die Bereitstellung von Diensten in der virtuellen Desktop-Systemarchitektur dreht sich um eine Abstraktion, die hier als eine "Session" bzw. "Sitzung" bezeichnet wird. Eine Sitzung ist eine Repräsentation derjenigen Dienste, die im Namen des Benutzers zu irgendeinem Zeitpunkt ausgeführt werden. Die Sitzungsabstraktion wird durch Einrichtungen bzw. Funktionen aufrecht erhalten, die als die Authentisierungs- und Sitzungsmanager bekannt sind, deren Aufgabe es ist, die Datenbankabbildungen zwischen Tokens (d. h. eindeutigen Bezeichnern bzw. Kennungen, die an Smartcards oder andere Mechanismen zur Authentisierung gebunden sind) und Sitzungen aufrecht zu erhalten und die Dienste, die jede Sitzung ausmachen, zu verwalten.
  • Für jeden Benutzer, dessen das System gewahr ist, gibt es eine oder mehrere Sitzungen. Der Sitzungsmanager bietet dem Benutzer einen Dienst es, der es ermöglicht, daß Sitzungen konfiguriert und neue Sitzungen erzeugt werden. Auf jedem Server laufen routinemäßig viele Sitzungen ab. Da die zentralen Server-Computer traditionell den gesamten Zustand für diesen potentiell riesigen Vorrat bzw. Pool von angeschlossenen DTUs aufrechterhalten, sind die DTUs nicht zu gebrauchen, wenn einer dieser zentralen Server-Computer ausfällt, bis der zentrale Computer wieder verfügbar ist. Somit ist der zentrale Server ein Single Point of Failure (zentraler Ausfallpunkt) für einen möglicherweise großen Pool von Benutzern. Wenn in dieser sich herausbildenden Computer-Architektur für eine Verarbeitungspraxis bzw. -anwendung mit hoher Leistung gesorgt werden soll, muß sich eine Lösung klarerweise mit dem Single-Point-of-Failure-Problem befassen.
  • Die US 5.991.892 offenbart ein Verfahren zur Ausführung einer Client-Server-Anwendung in einer Netzwerk-Konfiguration mit Server-Redundanz, um zu ermöglichen, daß ein Client-Terminal Dienste benutzt, die von einer Mehrzahl von Server-Terminals bereitgestellt werden Das Client-Terminal ist mit jedem Server-Terminal über ein ATM-(Asynchronous Transfer Mode)-Netzwerk verbunden.
  • ZUSAMMENFASSUNG DER ERFINDUNG
  • Die vorliegende Erfindung stellt ein Verfahren und eine Vorrichtung zur Verfügung, um einen rechnergestützten Dienst in einer Umgebung mit mehreren Server-Computern hochverfügbar zu machen. In dem Thin-Client-Verarbeitungsparadigma hängen Endbenutzer-DTUs von entfernten Server-Computern für den Betrieb bzw. das Funktionieren der meisten Funktionen ab, die traditionell Personalcomputern zugeordnet sind. Diese traditionellen Funktionen umfassen das Ablaufenlassen von Computerprogrammen und das Verarbeiten von Daten. Da viele Benutzer mit einem der zentralen Server-Computer verbunden sein können, fallen wahrscheinlich alle DTUs der Benutzer aus, wenn dieser zentrale Server-Computer ausfällt.
  • Die vorliegende Erfindung liefert eine Lösung durch das Implementieren einer Senner-Redundanz und einer DTU-Umlenkung, um die Verfügbarkeit der IT-Ressourcen in einer Situation, in der ein Server ausfällt, aufrecht zu erhalten. Wenn der Benutzer sich über eine DTU mit einem Server verbindet, kann der Benutzer anfangen, mit seiner Sitzung zu interagieren (z. B. die Eingabe kann von der DTU an den Server übergehen und die Ausgabe kann vom Server an die DTU zur Anzeige für den Benutzer übergehen). Diese Benutzerinteraktion kann permanent gespeicherte Daten benötigen, um die von dem Benutzer versuchten Interaktionen zu erfüllen (der Server, der die Sitzung beherbergt, wird zum Beispiel auf Dateien, Datenbanken. Mailserver, Heimatverzeichnisse oder Kalender zugreifen müssen).
  • Der Server, der die aktive Sitzung beherbergt, enthält nicht die einzige Kopie der permanenten Benutzerdaten. Diese Daten sind (auch) auf einem anderen Server gespeichert. Ein redundanter Senner, der die permanenten Benutzerdaten speichert, steht in Kommunikation mit dem Server, der die Sitzung beherbergt, und hat striktere Verfügbarkeitsanforderungen, aber stellt diese Daten zur Verfügung.
  • Der Server, der für einen Benutzer ausgewählt wird, hängt davon ab, ob dieser Benutzer eine oder mehrere existierende Sitzungen innerhalb der Ausfallssicherungs-Gruppe hat. Wenn es existierende Sitzungen gibt, ist der Benutzer an den Server gebunden, mit dem er zuletzt verbunden war. Wenn es keine existierenden Sitzungen gibt, wird ein Server unter Verwendung eines Lastausgleichsmechanismus ausgewählt, der versucht, den am wenigsten belasteten Server zu finden. Die DTU wird zu dem ausgewählten Server umgelenkt, der eine neue Sitzung für den Benutzer einrichtet.
  • KURZBESCHREIBUNG DER ZEICHNUNGEN
  • 1 stellt die virtuelle Desktop-Systemarchitektur der vorliegenden Erfindung dar.
  • 2 ist ein Blockdiagramm eines Beispiel-Computersystems, das mit der vorliegenden Erfindung verwendet werden kann.
  • 3 ist ein Blockdiagramm einer Ausführungsform einer DTU der vorliegenden Erfindung.
  • 4 stellt eine Einzelchip-DTU-Ausführungsform der vorliegenden Erfindung dar.
  • 5 stellt ein Beispiel der Sitzungsverwaltung und der -authentisierung in der vorliegenden Erfindung dar.
  • 6 stellt die virtuelle Desktop-Systemarchitektur dar, die den Gruppenmanager-Prozeß gemäß der vorliegenden Erfindung implementiert.
  • 7 ist ein Flußsteuerungsdiagramm der Schritte, die von dem Gruppenmanager-Prozeß gemäß der vorliegenden Erfindung durchgeführt werden.
  • 8 ist eine bildhafte Darstellung einer möglichen Netzwerktopologie, die von einem Gruppenmanager-Prozeß gemäß der vorliegenden Erfindung aufrecht erhalten werden kann.
  • 9a ist ein Flußsteuerungsdiagramm der Schritte, die von einer DTU durchgeführt werden, während sie gemäß der vorliegenden Erfindung mit dem Netzwerk gemäß dem Protokoll kommuniziert.
  • 9b ist ein Flußsteuerungsdiagramm der Serverumlenkung gemäß der vorliegenden Erfindung.
  • 9c ist ein Nachrichtenflußdiagramm der Serverumlenkung gemäß der vorliegenden Erfindung.
  • DETAILLIERTE BESCHREIBUNG DER ERFINDUNG
  • In der folgenden Beschreibung werden zahlreiche besondere Details dargelegt, um eine genauere Beschreibung von Ausführungsformen der Erfindung bereitzustellen. Es ist jedoch für Fachleute auf diesem Gebiet offenkundig, daß die Erfindung auch ohne diese besonderen Details in die Praxis umgesetzt werden kann. In anderen Fällen wurden wohlbekannte Merkmale nicht im Detail beschrieben, um die Erfindung nicht zu verschleiern.
  • Die vorliegende Erfindung stellt ein Verfahren und eine Vorrichtung bereit, um EDV-Dienste in einer Umgebung mit mehreren Server-Computern hochverfügbar zu machen. Die Erfindung implementiert Server-Redundanz und DTU-Umlenkung, um einen nahe gelegenen, beständigen Zugriff auf Rechnerressourcen in der Situation eines Serverausfalls aufrecht zu erhalten. Wenn sich der Benutzer über eine DTU mit einem Server verbindet, kann der Benutzer damit beginnen, mit seiner Sitzung zu interagieren (z. B. kann die Eingabe von der DTU an den Server übergehen und die Ausgabe kann von dem Server zu der DTU zur Anzeige für den Benutzer übergehen). Um die Bestrebungen bzw. Versuche des Benutzers zum Interagieren zu erfüllen, kann der Server permanente Daten benötigen und muß zum Beispiel auf Dateisysteme, Mail-Server oder Datenbanken zugreifen.
  • Permanente Benutzerdaten können zum Beispiel in einem oder mehreren Datenservern gespeichert werden, die mit dem die Sitzung beherbergenden Server in Kommunikation stehen, oder in einer solchen Weise gespeichert werden, daß die Daten im Fall eines Serverausfalls wiederhergestellt werden können. Der Server bzw. die Server, der bzw. die permanente Benutzerdaten speichert bzw. speichern, hat bzw. haben striktere Verfügbarkeitsanforderungen als diejenigen Server, die eine Sitzung beherbergen können. Da es die Architektur erlaubt, daß der die Sitzung beherbergende Server keinen permanenten Benutzerzustand hat (z. B. mehr oder weniger permanent gespeicherte Daten), sind alle eine Sitzung beherbergenden Server im Endeffekt untereinander austauschbar.
  • Wenn ein eine Sitzung beherbergender Server ausfällt, erkennt die vorliegende Erfindung den Ausfall und schaltet die DTUs, die diesen Senner verwenden auf einen anderen, Sitzungen beherbergenden Server um. Nach einer Ausführungsform wird es dem Benutzer ermöglicht, mehrere Sitzungen auf unterschiedlichen Servern in der Gruppe aufzurufen. Diese Ausführungsform stellt Mechanismen bereit, um zwischen diesen Sitzungen umzuschalten. Nach einer Ausführungsform verwendet die Erfindung ein Protokoll mit einem Mechanismus zum selbständigen Auffinden, der es der Erfindung ermöglicht, eine Liste von Servern (z. B. die Ausfallssicherungsgruppe) aufrecht zu erhalten, mit denen sich ein Satz von DTUs verbinden kann.
  • Auf jedem Server läuft ein Gruppenmanagerprozeß. Jeder Gruppenmanagerprozeß erzeugt von Zeit zu Zeit ein Paket und sendet das Paket per Rundsenden an das Netzwerk. Das Paket enthält eine Nachricht. Die Nachricht stellt Information über die Netzkonfigurationen des Servers bereit. Darüber hinaus horcht der Gruppenmanagerprozeß auf ähnliche rundgesendete Pakete von allen anderen Gruppenmanagerprozessen. Auf diese Weise kommuniziert jeder Server mit allen anderen Servern in der Gruppe, so daß jeder Server eine globale Übersicht der Netztopologie jedes Servers hat. Dieser Austausch von Nachrichten zwischen Servern ermöglicht es, daß eine Ausfallssicherungsgruppe von Servern sich selbst organisiert. Neue Server können einer Ausfallssicherungsgruppe durch den Austausch dieser Nachrichten ohne eine im Vorhinein vorgenommene Konfiguration beitreten.
  • Mit der Information in den rundgesendeten Paketen zeichnet jeder Gruppenmanagerprozeß eine vollständige Netztopologie auf. Wenn ein Server ausfällt, benutzen die Gruppenmanagerprozesse ihre Information, um die DTUs zu verfügbaren Servern umzulenken. Der redundante Speicher von permanenten Benutzerdaten bleibt unberührt, weil er auf einem Server außerhalb des Umlenkungsvorgangs liegt. Der umgelenkte Server, der auch mit dem permanenten Datenspeicher verbunden ist, der sich anderswo auf einem anderen Server befindet, hat ebenso Zugriff auf den permanenten Datenspeicher. Somit wird das Szenario eines ausgefallenen Servers, das nach dem Stand der Technik einen Verlust von EDV-Diensten für mehrere Benutzer zur Folge hätte, durch die Verwendung eines redundanten Servers mit einem permanenten Datenspeicher und Netzwerkumlenkung überwunden.
  • Die oben beschriebenen Mechanismen werden unter Bezug auf eine oder mehrere Systemarchitekturen genauer diskutiert. Eine solche Architektur ist die unten beschriebene virtuelle Desktop-Systemarchitektur.
  • Virtuelle Desktop-Systemarchitektur
  • Nach einer Ausführungsform wird die vorliegende Erfindung in der Computer-Systemarchitektur implementiert, die als die virtuelle Desktop-Systemarchitektur bezeichnet wird. Dieser Gegenstand wird in der gleichzeitig anhängigen U.S. Patentanmeldung 09/063.335 beschrieben, die am 20. April 1998 eingereicht wurde, mit dem Titel "Method and Apparatus for Providing a Virtual Desktop System Architecture" und die dem Inhaber des vorliegenden Patents übertragen wurde.
  • Die virtuelle Desktop-Systemarchitektur sorgt für eine Neuaufteilung der Funktionalität zwischen einer zentralen Serveranlage und der Benutzerhardware. Daten- und Berechnungsfunktionalität werden von Servern mittels einer zentralisierten Verarbeitungsanordnung zur Verfügung gestellt. Auf Seiten des Benutzers wird die gesamte Funktionalität entfernt mit Ausnahme derjenigen, die eine Ausgabe an den Benutzer erzeugt (z. B. Anzeige und Lautsprecher), eine Eingabe vom Benutzer entgegennimmt (z. B. Maus und Tastatur), oder anderer Peripheriegeräte, mit denen der Benutzer interagieren kann (z. B. Scanner, Kameras, entfernbarer Speicher, etc.).
  • Die gesamte Verarbeitung wird im Wesentlichen von den zentralen Servern vorgenommen und die Berechnung wird unabhängig von dem Ziel bzw. der Bestimmung der erzeugten Daten vorgenommen. Die Ausgabe des Servers wird an die DTU übergeben. Die DTU ist in der Lage, die Daten zu empfangen und die Daten anzuzeigen. Die Funktionalität des Systems ist zwischen einer Anzeige- und Eingabeeinrichtung und Servern aufgeteilt. Die Anzeige- und Eingabeeinrichtung ist die DTU. Die Aufteilung dieses Systems ist so, daß Zustands- und Berechnungsfunktionen von der DTU weggenommen sind und sich auf den Servern befinden. Nach einer Ausführungsform der Erfindung kommunizieren ein oder mehrere Server mit einer oder mehreren DTUs über eine gewisse Zwischenverbindungsstruktur wie ein Netzwerk.
  • Ein Beispiel eines solchen Systems ist in 1 dargestellt. In 1 besteht das System aus den Servern 100, die über die Zwischenverbindungsstruktur 101 Daten mit den DTUs 102 kommunizieren. Es sollte jedoch beachtet werden, daß die Strategien zur Hochverfügbarkeit nicht auf die virtuelle Desktop-Systemarchitektur beschränkt sind. Ausführungsformen der vorliegenden Erfindung werden in Verbindung mit einem Allzweckcomputer, wie dem in 2 beschriebenen, implementiert.
  • Ausführungsform der Allzweckcomputer-Umgebung
  • Eine Ausführungsform der Erfindung kann als Computersoftware in der Form von computerlesbarem Programmcode implementiert werden, der auf einem Allzweckcomputer wie dem in 2 abgebildeten Computer 200 ausgeführt wird. Eine Tastatur 210 und eine Maus 211 sind mit einem bidirektionalen Systembus 218 verbunden. Die Tastatur und die Maus dienen zum Einbringen von Benutzereingaben in das Computersystem und zum Kommunizieren dieser Benutzereingaben an die zentrale Verarbeitungseinheit (Central Processing Unit, CPU) 213. Andere geeignete Eingabeeinrichtungen können zusätzlich zu oder an Stelle der Maus 211 und der Tastatur 210 verwendet werden. Die I/O-(Input/output, Eingabe/Ausgabe)-Einheit 219, die an den bidirektionalen Systembus 218 angeschlossen ist, stellt solche I/O-Elemente wie einen Drucker, A/V (Audio/Video) I/O, etc. dar.
  • Der Computer 200 beinhaltet einen Videospeicher 214, einen Hauptspeicher 215 und einen Massenspeicher 212, die alle an den bidirektionalen Systembus 218 zusammen mit der Tastatur 210, der Maus 211 und der CPU 213 angeschlossen sind. Der Massenspeicher 212 kann sowohl feste als auch auswechselbare Medien wie magnetische, optische oder magneto-optische Speichersysteme oder jede andere verfügbare Massenspeichertechnologie enthalten. Der Bus 218 kann zum Beispiel zweiunddreißig Adreßleitungen zum Adressieren des Videospeichers 214 oder des Haupt speichers 215 beinhalten. Der Systembus 218 enthält zum Beispiel auch einen 32-Bit-Datenbus zum Übertragen von Daten zwischen den Komponenten wie der CPU 213, dem Hauptspeicher 215, dem Videospeicher 214 und dem Massenspeicher 212. Alternativ können statt separater Daten- und Adreßleitungen Multiplex-Daten/Adreßleitungen verwendet werden.
  • Nach einer Ausführungsform der Erfindung ist die CPU 213 ein von Motorola hergestellter Mikroprozessor wie der 680X0-Prozessor oder ein von Intel hergestellter Mikroprozessor wie der 80X86- oder Pentium-Prozessor oder ein SPARC-Mikroprozessor von Sun Microsystems. Jedoch kann jeder andere geeignete Mikroprozessor oder Mikrocomputer eingesetzt werden. Der Hauptspeicher 215 besteht aus dynamischem, wahlfrei zugreifbarem Speicher (Dynamic Random Access Memory, DRAM). Der Videospeicher 214 ist ein zweiseitig zugänglicher, wahlfrei zugreifbarer Videospeicher (Dual-Ported Video Random Access Memory). Ein Zugang des Videospeichers 214 ist an den Videoverstärker 216 angeschlossen. Der Videoverstärker 216 wird verwendet, um den Kathodenstrahlröhren-(Cathode Ray Tube, CRT)-Rastermonitor 217 zu betreiben. Der Videoverstärker 216 ist nach dem Stand der Technik wohlbekannt und kann durch jede geeignete Vorrichtung implementiert werden. Diese Schaltung wandelt Pixeldaten, die in dem Videospeicher 214 gespeichert sind, in Rastersignale um, die zur Verwendung durch den Monitor 217 geeignet sind. Der Monitor 217 ist eine Art von Monitor, die zur Anzeige von grafischen Bildern geeignet ist.
  • Der Computer 200 kann auch eine Kommunikationsschnittstelle 220 beinhalten, die an den Bus 218 angeschlossen ist. Die Kommunikationsschnittstelle 220 sorgt für eine Zweiwege-Datenkommunikationskopplung mittels einer Netzwerkverbindung 221 an ein lokales Netzwerk 222. Wenn zum Beispiel die Kommunikationsschnittstelle 220 eine ISDN- (Integrated Services Digital Network, Dienste-integrierendes, digitales Netzwerk)-Karte oder ein Modem ist, stellt die Kommunikationsschnittstelle 220 eine Datenkommunikationsverbindung zu der entsprechenden Art von Telefonleitung bereit, die einen Teil der Netzwerkverbindung 221 aufweist. Wenn die Kommunikationsschnittstelle 220 eine LAN- (Local Area Network, lokale Netzwerk)-Karte ist, stellt die Kommunikationsschnittstelle 220 eine Datenkommunikationsverbindung über die Netzwerkverbindung 221 zu einem kompatiblen LAN bereit. Drahtlose Verbindungen sind ebenso möglich. In jeder solchen Implementierung sendet und empfängt die Kommunikationsschnittstelle 220 elektrische, elektromagnetische oder optische Signale, die digitale Datenströme befördern, welche verschiedene Arten von Information darstellen.
  • Die Netzwerkverbindung 221 stellt typischerweise Datenkommunikation durch ein oder mehrere Netzwerke hindurch zu anderen Dateneinrichtungen bereit. Zum Beispiel kann die Netzwerkverbindung 221 eine Verbindung durch das lokale Netzwerk 222 zu dem Rostcomputer 223 oder zu einer Datenanlage bzw. -einrichtung, die von einem Internet-Dienstanbieter (Internet Service Provider, ISP) 224 betrieben wird, zur Verfügung stellen. Der ISP 224 seinerseits stellt Datenkommunikationsdienste über das weltweite Paketdatenkommunikationsnetzwerk bereit, das heutzutage gemeinhin als das "Internet" 225 bezeichnet wird. Das lokale Netzwerk 222 und das Internet 225 verwenden beide elektrische, elektromagnetische oder optische Signale, die digitale Datenströme befördern. Die Signale durch die verschiedenen Netzwerke und die Signale auf der Netzwerkverbin dung 221 und durch die Kommunikationsschnittstelle 220, die digitale Daten zu und von dem Computer 200 befördern, sind beispielhafte Formen von Trägerwellen, die Information transportieren.
  • Der Computer 200 kann durch das Netzwerke bzw. die Netzwerke, die Netzwerkverbindung 221 und die Kommunikationsschnittstelle 220 Nachrichten senden und Daten empfangen, einschließlich Programmcode. In dem Internetbeispiel könnte der Server 226 einen angeforderten Code für ein Anwendungsprogramm durch das Internet 225, den ISP 224, das lokale Netzwerk 222 und die Kommunikationsschnittstelle 220 übertragen.
  • Der empfangene Code kann von der CPU 213 ausgeführt werden, sowie er empfangen wird, und/oder in dem Massenspeicher 212 oder anderem nicht-flüchtigen Speicher zur späteren Ausführung gespeichert werden. Auf diese Weise kann der Computer 200 Anwendungscode in der Form einer Trägerwelle erhalten.
  • Die oben beschriebenen Computersysteme dienen nur als Beispiele. Eine Ausführungsform der Erfindung kann in jeder Art von Computersystem oder Programmier- oder Verarbeitungsumgebung implementiert werden.
  • IT-Dienstanbieter
  • Unter Bezug auf die virtuelle Desktop-Systemarchitektur befinden sich Rechenleistung und Zustandspflege bzw. -fortschreibung in den Dienstanbietern oder Diensten. Die Dienste sind nicht an einen spezifischen Computer gebunden, sondern können über ein oder mehrere traditionelle Desktop-Systeme, wie in Verbindung mit 2 beschrieben, oder bei bzw. mit traditionellen Servern verteilt werden. Ein Computer kann über einen oder mehrere Dienste verfügen, oder ein Dienst kann durch einen oder mehrere Computer implementiert werden. Der Dienst stellt den DTUs Berechnung, Zustand und Daten bereit und der Dienst ist unter der Kontrolle bzw. Steuerung einer gemeinsamen Autorität bzw. Befehlsgewalt oder eines gemeinsamen Managers. In 1 befinden sich die Dienste auf den Computern 110, 111, 112, 113 und 114. Es ist wichtig zu beachten, daß die zentrale Datenquelle auch Daten bereitstellen kann, die von außerhalb der zentralen Datenquelle 129 kommen, wie zum Beispiel dem Internet oder dem World Wide Web 130. Die Datenquelle könnte ebenso aus Rundfunk- bzw. Rundsendeeinheiten bestehen wie jene, die Daten wie Fernseh- oder Radiosignale 131 rundsenden. Ein Dienst ist hier ein Prozeß, der Ausgabedaten bereitstellt und auf Benutzeranforderungen und -eingaben antwortet.
  • Es liegt in der Verantwortung des Dienstes, die Kommunikation mit der DTU zu handhaben, die aktuell verwendet wird, um auf den gegebenen Dienst zuzugreifen. Dies bringt es mit sich, die Ausgabe von dem IT-Dienst entgegenzunehmen und sie in ein Standardprotokoll für die DTU umzuwandeln. Diese Datenprotokollumwandlung wird nach einer Ausführungsform der Erfindung von einer Middleware-Schicht behandelt wie dem X11-Server, der Microsoft-Windows-Schnittstelle, einem Videoformat-Codeumsetzer bzw. -Transcoder, der OpenGL-Schnittstelle oder einer Variante der java.awt.graphics-Klasse innerhalb der Maschine, die den Dienst erzeugt, obwohl auch andere Ausführungsformen im Schutzbereich der Erfindung liegen. Die Dienstmaschine behandelt die Übersetzung in und aus dem virtuellen Desktop-Architektur-Leitungsprotokoll Virtual Desktop Architecture Wire Protocol).
  • Die diensterzeugenden Computersysteme sind durch die Zwischenverbindungsstruktur direkt mit den DTUs verbunden. Es ist ebenso möglich, daß der Diensterzeuger ein Proxy für eine andere Einrichtung ist, die den IT-Dienst bereitstellt wie ein Datenbankcomputer in einer Drei-Stufen-Architektur (Three Tiered Architecture), wobei der Proxy-Computer nur Anfragen erzeugen und Benutzerschnittstellencode ausführen könnte.
  • Zwischenverbindungsstruktur
  • Die Zwischenverbindungsstruktur ist irgendeiner von mehreren geeigneten Kommunikationspfaden zum Übertragen von Daten zwischen den Diensten und den DTUs. Nach einer Ausführungsform ist die Zwischenverbindungsstruktur ein lokales Netzwerk, das als ein Ethernet-Netzwerk implementiert ist. Es kann auch jedes andere lokale Netzwerk eingesetzt werden. Die Erfindung betrachtet auch die Verwendung von Weitverkehrsnetzwerken (Wide Area Networks), des Internet, des Word Wide Web, eines Intranet, eines lokalen Netzwerks und anderer. Die Zwischenverbindungsstruktur kann mit einem physikalischen Medium wie einem Draht- oder Glasfaserkabel implementiert werden oder sie kann in einer drahtlosen Umgebung implementiert werden.
  • Desktop-Einheiten
  • Die DTU ist die Einrichtung, durch die Benutzer auf die Dienste zugreifen. 1 stellt die DTUs 121, 122 und 123 dar. Eine DTU kann aus einer Anzeige 126, einer Tastatur 124, einer Maus 125 und Audiolautsprechern 127 bestehen. Die DTU beinhaltet die benötigte Elektronik, um diese Einrichtungen mit der Zwischenverbindungsstruktur über Schnittstellen zu verbinden und Daten zu und von den Diensten zu übertragen und zu empfangen.
  • Ein Blockdiagramm einer DTU ist in 3 dargestellt. Die Komponenten der DTU sind intern an einen PCI-Bus 319 angeschlossen. Ein Netzwerk-Controller 302 kommuniziert mit der Zwischenverbindungsstruktur wie einem Ethernet über die Leitung 314. Ein Audio-Codec 303 empfängt Audiodaten auf der Schnittstelle 316 und ist an den Netzwerk-Controller 302 angeschlossen. USB-Datenkommunikation wird auf den Leitungen 313 zum USB-Controller 301 bereitgestellt.
  • Ein eingebetteter Prozessor 304 kann zum Beispiel ein Sparc2ep mit angeschlossenem Flashspeicher 305 und DRAM 306 sein. Der USB-Controller 301, der Netzwerk-Controller 302 und der eingebettete Prozessor 304 sind alle an den PCI-Bus 319 angeschlossen. Ebenso ist der Video-Controller 309 mit zugeordnetem SGRAM 307 an den PCI-Bus 319 angeschlossen. Der Video-Controller 309 kann zum Beispiel ein ATI RagePro+ Framepuffer-Controller sein, der SVGA-Ausgabe auf der Leitung 315 bereitstellt. Daten werden optional in den und aus dem Video-Controller durch den Video-Decoder 310 bzw. den Video-Encoder 311 übergeben. Diese Daten können digitale oder analoge Videosignale aufweisen (z. B. NTSC (National Television Systems Committee), PAL (Phase Alternate Line), etc.). Eine Smartcard-Schnittstelle 308 kann auch an den Video-Controller 309 angeschlossen sein.
  • Alternativ kann die DTU unter Verwendung einer Einzelchip-Lösung implementiert werden wie in 4 dargestellt. Die Einzelchip-Lösung enthält die benötigte Verarbeitungsfähigkeit, die mittels der CPU 401 und des Grafik-Wiedergebers bzw. -Erstellers 405 implementiert ist. Der Chipspeicher 407 steht zusammen mit dem bzw. der Video-Contoller/-Schnittstelle 406 zur Verfügung. Ein universeller serieller Bus- (Universal Serial Bus, USB) -Controller 402 steht zur Verfügung, um die Kommunikation mit einer Maus, einer Tastatur und anderen lokalen Einrichtungen, die an die DTU angeschlossen sind, zuzulassen. Ein Sound-Controller 403 und eine Verbindungsschnittstelle 404 stehen ebenso zur Verfügung. Die Video-Schnittstelle teilt sich den Speicher 407 mit der CPU 401 und dem Grafik-Erstellen 405. Die in dieser Ausführungsform verwendete Software könnte sich lokal in nicht-flüchtigem Speicher befinden, oder sie kann durch die Verbindungsschnittstelle geladen werden, wenn das Gerät bzw. die Einrichtung eingeschaltet wird.
  • BETRIEB DER VIRTUELLEN DESKTOP-SYSTEMARCHITEKTUR
  • Sitzungs-Behandlung bzw. -Handhabung
  • Die Bereitstellung von Diensten in der virtuellen Desktop-Systemarchitektur dreht sich um eine Abstraktion, die hier als eine Session bzw. Sitzung bezeichnet wird. Eine Sitzung ist eine Repräsentation derjenigen Dienste, die im Namen eines Benutzers zu irgendeinem Zeitpunkt ausgeführt werden. Eine neue Sitzung kann angelegt bzw. geschaffen werden, wenn ein neues Token dem Authentisierungsmanager durch die DTU übergeben wird. Ein Token ist ein eindeutiger Bezeichnen bzw. eine eindeutige Kennung, der bzw. die eine Ethernet-Adresse einer DTU (Pseudo-Token) oder die Seriennummer auf einer Smartcard sein kann.
  • Die Sitzungsabstraktion wird durch Einrichtungen aufrecht erhalten, die als die Authentisierungs- und Sitzungsmanager bekannt sind, deren Aufgabe es ist, die Datenbank der Abbildungen zwischen Tokens und Sitzungen aufrecht zu erhalten und die Dienste, die jede Sitzung ausmachen, zu verwalten. Für jedes Token, dessen das System gewahr ist, gilt die Tatsache, daß es eine oder mehrere Sitzungen gibt. Der Sitzungsmanager bietet dem Benutzer oder Administrator einen Dienst, der es ermöglicht, Sitzungen zu konfigurieren und neue Sitzungen zu erzeugen.
  • Eine Sitzung ohne Pseudo-Token ist nicht an irgendeine bestimmte DTU gebunden. Ein Token ist einer Benutzersitzung zugeordnet, und die Sitzung kann auf jeder beliebigen DTU angezeigt werden, an der der Benutzer seine Smartcard einsetzt bzw. einsteckt. Ein Softwareprozeß, der als der Authentisierungsmanager bekannt ist, ist dafür verantwortlich, die Legitimität bzw. Zulässigkeit eines Tokens sicherzustellen und ein Token einer gewünschten Sitzung zuzuordnen. Die DTU ist typischerweise im Schlaf-, Bereitschafts- bzw. Standby- oder im ausgeschalteten Modus, wenn sie nicht in Verwendung ist. Wenn ein Benutzer eine bestimmte DTU zu benutzen wünscht, wird der Zugang bzw. Zugriff des Benutzers in einem Authentisierungsaustausch validiert bzw. für gültig erklärt, der eines oder mehrere der folgenden aufweisen kann: eine Smartcard, einen Schlüssel, ein Paßwort, einen biometrischen Mechanismus oder irgendeinen anderen geeigneten Authentisie rungsmechanismus. Das Token, das aus diesem Austausch extrahiert wird, wird daraufhin verwendet, um eine Verbindung zu der passenden Sitzung aufzubauen.
  • Wenn der Authentisierungsmanager ein Token validiert, benachrichtigt er den Sitzungsmanager des Servers, der seinerseits sämtliche Dienste innerhalb der ausgewählten Sitzung benachrichtigt, und die Anzeige der Sitzung wird beim Server zusammengefügt und zum Desktop des Benutzers übertragen. Aus einer Sitzung heraus kann ein Benutzer mit vorhandenen Diensten interagieren, neue Dienste einleiten oder Dienste, die ausgeführt werden, beenden bzw. löschen. Wenn der Benutzer die DTU verläßt (z. B. durch Wegnehmen einer Smartcard), bemerkt der Authentisierungsmanager dies und benachrichtigt den Sitzungsmanager, der seinerseits sämtliche ihm zugehörige Dienste benachrichtigt, die ihre Anzeigefunktionen anhalten, und die DTU kehrt in ihren Ruhezustand zurück. Die Wirkung der Aktivierung und Deaktivierung eine DTU ist ähnlich dem Ausschalten des Anzeigemonitors an einem Desktop-System. Die Dienste der Benutzersitzung sind noch verfügbar und werden vielleicht ausgeführt, aber es wird keine Anzeige erzeugt. Ein Vorteil der vorliegenden Erfindung ist es, daß auf die in einer Sitzung verfügbaren Dienste an irgendeiner angeschlossenen DTU zugegriffen werden kann.
  • 5 liefert ein Beispiel der Sitzungsverwaltung und -autorisierung in der vorliegenden Erfindung. Dieser Gegenstand ist in der gleichzeitig anhängigen U.S.-Patentanmeldung/Seriennummer 09/063.339, eingereicht am 20. April 1998 mit dem Titel "Method and Apparatur for Session Management and User Authentication" beschrieben und auf den Inhaber des vorliegenden Patents überschrieben. Das Netzwerkterminal 502 ist eine DTU, die die Aufgabe hat, einem Benutzer die Ausgabe von Diensten anzuzeigen und die Eingabe an Dienste von dem Benutzer zu erhalten. Das Netzwerkterminal 502 hat die Fähigkeit, auf ein Kommando (z. B. ein Anzeigekommando), das zum Beispiel von einem auf einem IT-Dienstanbieter ausgeführten Softwareprogramm (z. B. den Diensten 530–538, dem Authentisierungsmanager 504 und dem Sitzungsmanager 506) empfangen wurde, zu antworten. Die von einem Benutzer empfangene Eingabe wird zum Beispiel an einen Dienst weitergeleitet, der eine Benutzeranforderung bedient.
  • Ein Dienst ist ein Programm, das einige Funktionen für einen Benutzer durchführt. Mehr als ein Server kann die Dienste ausführen, aus denen eine Sitzung besteht. Zum Beispiel werden in Sitzung 508 der Dienst 530 auf dem Server 510, die Dienste 532 und 534 auf dem Server 512 und die Dienste 536 und 538 auf dem Server 514 ausgeführt.
  • Ein Benutzer greift auf ein System (z. B. einen Server, eine Sitzung, einen Dienst und ein Netzwerkterminal) zu, indem er ein Login einleitet. Während des Login wird der Benutzer vom Authentisierungsmanager 504 validiert. Verschiedene Techniken können verwendet werden, um es dem Benutzer zu ermöglichen, ein Login einzuleiten. Zum Beispiel kann der Benutzer ein Login einleiten, indem er eine Taste auf dem Netzwerkterminal 502 drückt.
  • Nach einer Ausführungsform greift ein Benutzer auf das System zu, indem er eine Smartcard in einen Kartenleser (z. B. den Kartenleser 516) einführt, der am Netzwerkterminal 502 angebracht ist. Eine Smartcard ist eine Karte, die in der Lage ist, Information zu speichern wie zum Beispiel in einem Magnetstreifen oder Speicher der Smartcard. Die Smartcard kann Benutzerinformation wie eine Benutzerkennung (d. h. Benutzer-ID wie eine 64-Bit-Zahl) und optional einen geheimen Code (z. B. eine 128-Bit-Zufallszahl) speichern, die an das Netzwerkterminal 502 übermittelt wird. Der geheime Code kann während der Authentisierung verwendet werden.
  • Das Netzwerkterminal 502 ist sich seiner Verbindungsnetzwerkadresse und der Adresse des Authentisierungsmanagers 504 bewußt (oder kann sie sich verschaffen). Wenn ein Benutzer ein Login einleitet, leitet das Netzwerkterminal 502 eine Kommunikation mit dem Authentisierungsmanager 504 ein, um die Authentisierung zu beginnen. Der Authentisierungsmanager 504 ist ein Programm, das auf einem Server aktiv ist (z. B. ausgeführt wird), der mittels eines Verbindungsnetzwerks wie zum Beispiel eines lokalen Netzwerks (Local Area Network, LAN) mit dem Netzwerkterminal 502 verbunden ist. Es ist jedoch offenkundig, daß das Netzwerkterminal 502 mit dem Authentisienangsmanager 504 unter Verwendung anderer Verbindungsnetzwerktechnologien wie einer Glasfaserschleife bzw. -loop, einem Punkt-zu-Punkt-Kabel oder drahtloser Technologien verbunden sein kann. Das Netzwerkterminal 502 sendet eine Startanforderung an den Authentisierungsmanager 504, die eine Benutzerkennung (Benutzer-ID) beinhaltet.
  • Wenn das erwartete Ergebnis vom Benutzer empfangen wurde, benachrichtigt der Authentisierungsmanager 504 den Sitzungsmanager 506 (mittels einer Verbindungsnachricht), daß der Benutzer sich in das System auf dem Netzwerkterminal 502 eingeloggt hat. Die in der Authentisierungsdatenbank 518 enthaltene Sitzungsinformation wird verwendet, um den Server, den Anschluß bzw. Port und den Sitzungsbezeichner (ID) für den Sitzungsmanager 506 anzugeben bzw. zu identifizieren. Der Sitzungsmanager 506 ist ein Programm, das auf einem IT-Dienstanbieter aktiv ist und mit dem Authentisierungsmanager 504 und dem Netzwerkterminal 502 zum Beispiel über ein Verbindungsnetzwerk verbunden ist. Der Authentisierungsmanager 504 sendet eine Nachricht an den Sitzungsmanager 506, indem er die in der Authentisierungsdatenbank 518 enthaltene Server- und Portinformation des Sitzungsmanagers 506 verwendet.
  • Als Reaktion auf die Verbindungsnachricht vom Authentisierungsmanager 504 benachrichtigt der Sitzungsmanager 506 die Dienste in der aktuellen Sitzung des Benutzers (d. h. die Dienste in der Sitzung 508), daß der Benutzer an dem Netzwerkterminal 502 angeschlossen ist. Das heißt, der Sitzungsmanager 506 sendet eine Verbindungsnachricht an die Dienste 530–538, um die Ausgabe an das Netzwerkterminal 502 zu lenken. Der Sitzungsmanager 506 stellt sicher, daß die Dienste, die als notwendige Dienste der Sitzung betrachtet werden, ausgeführt werden. Falls nicht, veranlaßt der Sitzungsmanager 506, daß sie eingeleitet bzw. angestoßen werden. Der Benutzer kann mit den Diensten 530–538 innerhalb einer Sitzung (z.B. Sitzung 508) interagieren. Das Netzwerkterminal 502 ist mit den Servern 510, 512 und 514 (und den Diensten 530–538) über ein Verbindungsnetzwerk wie ein lokales Netzwerk oder andere Verbindungstechnologien verbunden. Der Benutzer kann auch neue Dienste starten oder vorhandene Dienste beenden.
  • Der Benutzer kann aufhören, das System zu verwenden, indem er die Karte aus dem Kartenleser 516 entfernt. Andere Mechanismen, um das System zu verlassen, können ebenso bei bzw. mit der Erfindung verwendet werden (z. B. eine "Abmelde"- bzw. "Sign-Off"-Taste bzw. -Knopf am Netzwerkterminal 502). Die Dienste 530–538 können weiterlaufen, auch nachdem der Benutzer die Karte aus dem Kartenleser 516 entfernt hat. Das heißt, eine zugeordnete Sitzung bzw. Sitzungen des Benutzers und die Dienste, aus denen eine Sitzung besteht, können während der Zeitspanne, in der der Benutzer vom System abgemeldet ist, weiterhin existieren. Wenn der Benutzer die Karte aus dem Kartenleser 516 entfernt, benachrichtigt das Netzwerkterminal 502 den Authentisierungsmanager 504 (z. B. mittels einer Verbindungsabbaunachricht), der den Sitzungsmanager 506 (z. B. mittels einer Verbindungsabbaunachricht) benachrichtigt. Der Sitzungsmanager 506 benachrichtigt die Dienste 530–538 (z. B. mittels einer Verbindungsabbaunachricht), was deren Übermittlung von Anzeigekommandos an das Netzwerkterminal 502 beendet. Die Dienste 530–538 setzen die Ausführung jedoch während der Zeit fort, in der der Benutzer vom Netzwerkterminal 502 weg ist. Der Benutzer kann sich wieder einloggen, indem er ein Netzwerkterminal wie das Netzwerkterminal 502 verwendet, um sich mit der Sitzung 508 zu verbinden und mit den Diensten 530–538 zu interagieren.
  • BETRIEB BZW. WIRKUNGSWEISE DES MECHANISMUS' ZUR SELBSTÄNDIGEN ENTDECKUNG
  • Eine Ausführungsform der vorliegenden Erfindung implementiert ein Protokoll, das einen Mechanismus zur selbständigen Entdeckung bzw. zum selbständigen Ausfindigmachen verwendet. Wenn ein Server ausfällt, weiß die DTU, daß der Server ausgefallen ist, da sie keine zeitgerechten Nachrichten vom Server mehr empfängt. Danach beginnt die DTU eine Verbindungssequenz, in der sie zum Beispiel unter Verwendung von DHCP beginnt, ihre Position und die Position eines potentiellen Servers zu erhalten, die die Form von IP-Adressen haben können. Sobald ein Server gefunden wurde, kann sich die DTU mit diesem Server verbinden.
  • Wenn die Verbindung scheitert, sendet die DTU Rundsende-Nachrichten (z. B. eine "serverQ"-Nachricht) an andere Senner. Die anderen Server antworten, und eine Verbindung zu einem der anderen Server wird aufgebaut. Da sich die einzige Kopie der permanenten Benutzerdaten weder auf dem ausgefallenen Server noch auf dem Zielserver für die Umlenkung befindet, sind sie aus der Sicht des Benutzers effektiv untereinander austauschbar. Sobald die Umlenkung erfolgt, ist auf dem neuen Host für die Sitzung des Benutzers der Zugriff auf die Daten möglich.
  • Der Gruppenmanagergrozeß Auf jedem Server läuft ein Gruppenmanagerprozeß. In 6 laufen die Gruppenmanagerprozesse 601a und 601b auf den Servern 600a und 600b ab und sind über ein Computernetzwerk mit den DTUs 602 verbunden. Der Gruppenmanagerprozeß arbeitet gemäß 7. Der Gruppenmanagerprozeß 700 sammelt und speichert eine Beschreibung der Netzwerktopologie 701, die in einer Tabelle gespeichert sein kann. Nach einer Ausführungsform liest der Gruppenmanager 700 die Netzwerkkonfiguration seines Servers, indem er auf den Kern schaut, um zu sehen, welche Netzwerkschnittstellen mit ihm verbunden sind. Der Gruppenmanagerprozeß erzeugt periodisch ein Paket, mit dem er diese Information 702 bzw. in Schritt 702 an das Netzwerk rundsendet und damit die Verfügbarkeit desjenigen Servers anzeigt, auf dem der Gruppenmanagerprozeß abläuft. Nach einer Ausführungsform geschieht dieses Rundsenden des Pakets unter Verwendung des unzuverlässigen Datagramm-Protokolls, bei dem das Rundsenden einer Nachricht eine uni-direktionale bzw. einseitig gerichtete Kommunikation ist.
  • Jeder Gruppenmanagerprozeß horcht in Schritt 703, um Pakete von Information von anderen Gruppenmanagerprozessen zu entdecken, welche die Verfügbarkeit anderer Server anzeigen. Mit dieser Information baut der Gruppenmanagerprozeß eine Tabelle von anderen Hosts auf, von denen er gehört hat. Diese Tabelle stellt die Topologie des Netzwerks dar. Der Gruppenmanagerprozeß horcht bei Schritt 704 zusätzlich auf Nachrichten auf dem Netzwerk, die von DTUs beim Versuch rundgesendet werden, eine Kommunikationsverbindung zu dem Server aufzubauen, auf dem sich der Gruppenmanagerprozeß befindet. Dieser Prozeß wiederholt sich von Zeit zu Zeit, wie durch den Übergang 705 angezeigt.
  • 8 ist eine bildhafte Darstellung einer möglichen Beschreibung einer Netzwerktopologie, die durch einen Gruppenmanagerprozeß aufgebaut wird. Die DTUs 1 bis x, bezeichnet mit 800808, verbinden sich über die Zwischenverbindungsstrukturen 809–817 mit einem Switch bzw. einer Vermittlung 818. Der Switch 818 verbindet sich seinerseits über die Zwischenverbindungsstrukturen 819-823 mit den Sitzungs-beherbergenden Servern s1 bis sx, bezeichnet mit 824828. Die Server selbst sind durch die Struktur über den Switch 818 miteinander verbunden, wodurch Umlenkung ermöglicht wird. Darüber hinaus enthält der Server sy 829 den permanenten Speicher der Benutzerdaten. Nach einer Ausführungsform ist der Server sy 829 über ein separates LAN (Local Area Network, Lokales Netzwerk) oder ein anderes Netzwerk mit den Sitzungs-beherbergenden Sennern s1–sx unter Verwendung der Netzwerkschnittstellen 830 und 832 bis 836 verbunden. Indem jeder Gruppenmanager seine Netzwerkinformation rundsendet, hat jeder Gruppenmanager in dem Netzwerk eine vollständige Sicht des Systems.
  • Nach einer Ausführungsform sendet jeder Gruppenmanager eine Rundsende- (oder Multicast-)-"Host"-Nachricht an die Netzwerkanschlüsse und zeigt damit die Konfiguration aller mit dem Server verbundenen Schnittstellen an. Nach dieser Ausführungsform horchen die Gruppenmanagerprozesse auf jedem Server auch auf den Anschlüssen auf Host-Nachrichten von anderen Servern in der Gruppe. Mit diesen Nachrichten richtet jeder Gruppenmanagerprozeß eine Liste von Servern und gemeinsam genutzten Schnittstellen einschließlich Information zur Netzwerkadressierung ein. Diese Information wird verwendet, um zu bestimmen, welche DTUs sich mit welchen Servern verbinden können, wenn es eine Vielzahl von Netzwerkschnittstellen auf den Servern gibt.
  • Als ein Beispiel kann ein Hostserver namens "mud" die folgende Hostnachricht auf allen Schnittstellen alle zwanzig Sekunden rundsenden:
    Figure 00140001
    wobei "host" der Hostname eines Servers (z. B. "mud"), "addr" die primäre Netzwerkadressedieses Hosts, "numifs" die Anzahl von Netzwerkschnittstellen auf diesem Host, "interface" der Name einer Netzwerkschnittstelle auf diesem Host, "ip" die IP-Adresse der vorstehenden Schnittstelle, "mask" die IP-Netzmaske der vorstehenden Schnittstelle, und "bcast" die IP-Broadcast- bzw. -Rundsende-Adresse der vorstehenden Schnittstelle sind. Darüber hinaus kann jede Hostnachricht von dem Gruppenmanagerprozeß des sendenden Servers unter Verwendung eines Gruppenmanagergeheimnisses signiert werden, das nur einer vertrauenswürdigen Gruppe von Servern bekannt ist.
  • Die Netzwerktopologie kann zum Beispiel als eine Tabelle von Hosts (d. h. Servern) und Netzwerkinformation, wie in Tabelle A unten veranschaulicht, dargestellt werden, die die Sicht der Netzwerktopologie des Gruppenmanagers eines Servers zeigt (die gezeigten Werte sind hexadezimal). Zusätzlich zu den Definitionen, die bezüglich der Hostnachricht oben angegeben wurden, gelten folgende Definitionen für die Tabelle A unten: "lastseen" ist die Anzahl von Sekunden, seit das letzte Paket von dem entsprechenden Host (Server) empfangen wurde; "timeoff" ist die Zeitdifferenz zwischen host05 (dem ersten aufgelisteten Server) und dem entsprechenden Host; "TRUSTED" gibt an, daß der entsprechende Host dasselbe Gruppenmanagergeheimnis verwendet, um Nachrichten zu signieren; und "lastpkt" ist die Zeit in Sekunden, seit ein Paket auf der vorstehenden Schnittstelle empfangen wurde (–1 zeigt an, daß auf dieser Schnittstelle noch nie ein Paket empfangen wurde). TABELLE A
    Figure 00150001
  • Jeder DTU wird eine Netzwerkadresse zugewiesen, wenn sie hochgefahren wird. Nach einer Ausführungsform kann diese Netzwerkadresse eine IP-Adresse sein, die unter Verwendung des dynamischen Hostkonfigurationsprotokolls bzw. des Dynamic Host Configuration Protocol (DHCP) zugewiesen wird. Mit dieser IP-Adresse und der Netzwerkinformation in Tabelle A kann ein Server die Teilmenge von Server bestimmen, mit der die DTU sich verbinden kann. Der Server verwendet diese Information auch zum Überwachen, welche der anderen Server hochgefahren sind und arbeiten. Ein Server oder eine Schnittstelle können als "heruntergefahren" bzw. "down" erklärt werden, wenn die "lastseen"-Zeit für den Host oder die "lastpkt"-Zeit für eine Schnittstelle einen Grenzwert übersteigen, z. B. sechzig Sekunden.
  • Das Protokoll zum selbständigen Ausfindig-Machen
  • Die DTU kommuniziert mit dem Netzwerk in der in 9A abgebildeten Weise. Zuerst greift ein Benutzer in Schritt 900 auf die DTU zu. Zum Beispiel kann der Benutzer die DTU an diesem Punkt 901 einschalten. Eine gegebene DTU hat immer eine Verbindung zu mindestens einem Server in dem Netzwerk. Diese Verbindung wird bei Schritt 901 aufgebaut, bei dem der Benutzer die DTU einschaltet. Bei Einschalten sendet die DTU Nachrichten per Rundsenden unter Verwendung eines Protokolls, das nach einer Ausführungsform auf dem Kern des Servers aufgerufen werden kann, und von dem Gruppenmanagerprozeß empfangen werden kann, der sich auf dem Server befindet, auf dem die Verbindung in Schritt 902 herzustellen ist.
  • Sobald eine Verbindung aufgebaut ist, empfängt die DTU 900 periodisch Nachrichten von dem Gruppenmanager bezüglich der Verfügbarkeit dieses Servers in Schritt 903. Wenn der Server in Schritt 904 verfügbar ist, geht der Ablauf entlang des Übergangs 905 weiter und die DTU horcht weiter auf Verfügbarkeitsnachrichten von dem Gruppenmanager. Wenn nach einer bestimmten Zeit keine Nachricht empfangen wird, wird angenommen, daß der Server abgestürzt ist, und der Ablauf geht entlang des Übergangs 906 weiter.
  • Danach beginnt die DTU in Schritt 907 auf Nachrichten von anderen Gruppenmanagerprozessen, die sich auf anderen Servern befinden, hinsichtlich ihrer Verfügbarkeit zu horchen. Die DTU entscheidet in Schritt 908, ob diese Server verfügbar sind. Wenn sie nicht verfügbar sind, geht der Ablauf entlang des Übergangs 909 weiter, und die DTU horcht weiterhin, bis sie verfügbar sind. Wenn sie verfügbar sind, geht der Ablauf entlang des Übergangs 910 weiter, die DTU baut eine Kommunikation mit dem Gruppenmanagerprozeß auf, der sich auf dem verfügbaren Server befindet, und der Prozeß wiederholt sich mit den Schatten 902–910.
  • Nach einer Ausführungsform sendet die DTU eine Rundsende-"serverQ"-Nachricht, die von einem oder mehreren anderen Servern auf dem Netzwerk zu empfangen ist, wenn der von der DTU beim Hochfahren angegebene Server nicht antwortet. Wenn ein anderer Server die serverQ-Nachricht empfängt, antwortet er mit einer serverR-Nachricht an die anfordernde DTU und gibt ihr Netzwerkinformation. Diese Information kann zum Beispiel die IP-Adresse des Servers auf dem Subnetz enthalten, zu dem die DTU gehört. Wenn serverR-Antworten von einem oder mehreren Servern empfangen werden, versucht die DTU, mit den entsprechenden Servern Verbindung aufzunehmen, bis es klappt.
  • Der Ablauf des Umlenkungsprozesses ist in 9B abgebildet. Der Gruppenmanagerprozeß 601 läuft auf Server s1. Eine DTU versucht, eine Sitzung auf dem ersten verfügbaren Server einzuleiten, der ihre Rundsende-Nachricht empfängt, zum Beispiel auf dem Server s1, indem sie ein "insert"-Ereignis mit einem Token bei Schritt 911 sendet. Der Gruppenmanagerprozeß auf Server s1 liest dann das Paket in Schritt 912, um festzustellen, ob eine Umlenkung aufgetreten ist. Wenn dem so ist, stellt der Gruppenmanager bei Schritt 913 fest, ob eine Sitzung auf s1 für dieses Token existiert. Wenn eine Sitzung existiert, wird die DTU mit dieser Sitzung bei Schritt 914 verbunden. Wenn keine Sitzung existiert, wird eine neue Sitzung bei Schritt 915 erzeugt.
  • Wenn bei Schritt 912 keine Umlenkung aufgetreten ist, bestimmt der Gruppenmanagerprozeß von Server s1 bei Schritt 916 die anderen Server (s2,. . ., sx), mit denen die DTU Verbindung aufnehmen kann. Als nächstes werden den Servern (s1,. . ., sx), mit denen die DTU Verbindung aufnehmen kann, von dem Gruppenmanagerprozeß von Server s1 bei Schritt 917 Nachrichten gesendet, die das Token von der DTU angeben. Danach empfängt der Gruppenmanagerprozeß von Server s1 bei Schritt 918 die Antworten von den Servern (s1,. . ., sx), die die Existenz (oder Nicht-Existenz) einer Sitzung für das gegebene Token angeben. Der Gruppenmanagerprozeß stellt bei Schritt 919 fest, ob auf zumindest einem Server eine Sitzung für das Token existiert. Wenn keine Sitzung existiert, wird bei Schritt 915 eine neue Sitzung für das Token auf Server s1 kreiert. Wenn eine Sitzung existiert, ist der bei Schritt 920 ausgewählte Zielserver derjenige mit der jüngsten Sitzung, der für das Token verfügbar ist. Der Gruppenmanagerprozeß stellt daraufhin bei Schritt 921 fest, ob der Zielserver der aktuelle Server ist. Wenn der Zielserver nicht der aktuelle Server ist, wird bei Schritt 922 eine Umlenkungsnachricht an die DTU gesendet, die ihr mitteilt, zu dem Zielserver st umzulenken. Wenn der Zielserver der aktuelle Server ist, wird ein Übergang zu Schritt 913 vorgenommen.
  • 9C liefert ein Nachrichtenflußdiagramm für eine Serverumlenkung. Die Server s1 923, s2 924 und s3 925 und die DTU 926 übergeben Nachrichten. Die DTU 926 sendet ein Einfüge- bzw. insert-Ereignis 927 (mit Grund = "insert") an den Server 923. Nach Übergabe der tokenQ- und tokenR-Nachrichten wird der Server 923 der Tatsache gewahr, daß eine Sitzung für das Token t1 auf dem Server 924 existiert. Der Server 923 sendet daher eine Umlenkungsnachricht an die DTU 926. Danach sendet die DTU 926 ein insert-Ereignis 928 an den Server 924. Es ist zu beachten, daß ein Teil der Nachricht anzeigt, daß dies eine Umlenkung ist (z. B. Ursache = "redirect"), wodurch eine wiederholter Authentisierungsversuch umgangen wird.
  • Nach dem Einsammeln von tokenR-Antworten von den in Frage kommenden Servern, wählt nach einer Ausführungsform der Gruppenmanagerprozeß auf dem Server, der ursprünglich das insert-Ereignis empfangen hat (Server 923) einen Server aus, an den die DTU weitergeleitet wird, indem die Sitzung mit dem spätesten Zeitpunkt der letzten Verbindung ausgewählt wird. Der Gruppenmanager sendet dann eine Umlenkungsnachricht an die DTU, die ihr mitteilt, zum dem neuen Server umzulenken. Die DTU bricht die Verbindung mit dem aktuellen Server ab, verbindet sich neu mit dem neuen Server und sendet ein insert-Ereignis mit einem Feld "Ursache" mit dem Wert "redi rect". Die "redirect"-Ursache verhindert, daß der neue Server die Serverauswahl noch einmal vornimmt. Die DTU ist mit der Sitzung verbunden, die durch das Token identifiziert wird.
  • Als eine Sicherheitsmaßnahme signiert eine Ausführungsform die Nachrichten, die per Rundsenden durch das Netzwerk gesendet werden. Zum Beispiel kann eine Ausführungsform einen SHA1-Hash-Algorithmus mit einem Schlüssel verwenden. Der Schlüssel wird von einer lokalen Schlüsseldatei auf jedem Server hergeleitet, der bzw. die auf allen Servern identisch sein muß, damit die Server einander vertrauen. Hostnachrichten werden immer akzeptiert. Nur Nachrichten mit der korrekten Signatur werden als "TRUSTED"-Hosts akzeptiert. TokenQ- und tokenR-Nachrichten werden nach dieser Ausführungsform nur zwischen TRUSTED-Hosts ausgetauscht.
  • Wenn ein Server ausfällt, erkennt die DTU nach einer Ausführungsform den Ausfall, wenn sie keine zeitgerechten Antworten auf "keep alive"-Nachrichten empfängt. Beim Scheitern, eine Nachricht auf die "keep alive"-Nachricht zu empfangen, sendet die DTU Nachrichten an einen neuen Server unter Verwendung des zuvor beschriebenen serverQ/serverR-Protokolls. Somit ermöglicht das Protokoll, wenn ein Server ausfällt, eine erneute Verbindung aller DTUs zu einem aktiven Server. Die vom Ausfall betroffene Sitzung kann auf dem neuen Server fortfahren und von den permanenten Benutzerdaten Gebrauch machen, die mit allen Hostservern in der Gruppe verbunden sind.
  • Somit wurde in Verbindung mit einer oder mehreren spezifischen Ausführungsformen ein Verfahren und eine Vorrichtung vorgelegt bzw. bereitgestellt, um einen IT-Dienst in einer Computerumgebung mit mehreren Servern hochverfügbar zu machen. Die Erfindung ist durch die Ansprüche und ihren vollständigen Bereich von Äquivalenzen definiert.

Claims (14)

  1. Verfahren zum Verfügbarmachen eines Computerdienstes mit: Initiieren einer Kommunikation zwischen einer Einheit (102) und einem erster Server (110), Bestimmen des Ortes einer Sitzung auf einem von einer Mehrzahl von Servern (100) und Umleiten der Einheit zu einem zweiten Server, welcher die Sitzung hat.
  2. Verfahren nach Anspruch 1, wobei das Initiieren aufweist: Versenden einer Nachricht der Einheit an die Mehrzahl von Servern; und Antworten des ersten Servers auf die Nachricht.
  3. Verfahren nach Anspruch 1, wobei das Initiieren in Reaktion darauf erfolgt, daß ein früherer Server ausfällt.
  4. Verfahren nach Anspruch 1, wobei die Sitzung einer Wertmarke bzw. einem Kürzel zugeordnet ist.
  5. Verfahren nach Anspruch 4, wobei das Bestimmen aufweist: Senden einer Nachricht des ersten Servers an die Mehrzahl von Servern, wobei die Nachricht die Wertmarke bzw. das Kürzel aufweist; und Antworten der Mehrzahl von Servern an den ersten Server mit Sitzungsinformation, welche dem Kürzel zugeordnet ist.
  6. Verfahren nach Anspruch 1, welches weiterhin das Bestimmen einer jüngsten bzw. letzten Sitzung aus einer Mehrzahl von Sitzungen aufweist.
  7. Verfahren nach Anspruch 1, welche weiterhin das Absichern der Nachrichten zwischen der Einheit und den Servern aufweist.
  8. Verfahren nach Anspruch 7, wobei das Absichern mit einer verschlüsselten Hash-Signatur durchgeführt wird.
  9. Vorrichtung zum Verfügbarmachen von Computerdiensten, mit: einem ersten Server (100), der eine Hostnachricht von einem zweiten Server (100) empfängt; wobei der erste Server Einrichtungen zum Ausbilden einer Netzwerktopologie unter Verwendung der Hostnachricht umfaßt.
  10. Vorrichtung nach Anspruch 9, wobei die Hostnachricht wiederholt gesendet wird.
  11. Vorrichtung nach Anspruch 10, welche weiterhin das Aktualisieren des Zustandes in der Netzwerktopologie auf der Basis einer Beziehung zwischen mehreren Hostnachrichten aufweist.
  12. Vorrichtung nach Anspruch 9, wobei die Hostnachricht an eine Gruppe von Servern ausgesendet wird.
  13. Vorrichtung nach Anspruch 12, welche weiterhin das Sichern der Nachricht mit einem Schlüssel aufweist, welcher einer zuverlässigen Gruppe von Servern bekannt ist.
  14. Computerprogramm zum Implementieren des Verfahrens nach einem der Ansprüche 1 bis 8.
DE60100800T 2000-02-25 2001-02-23 Verfahren und einrichtung zur bereitstellung von einem hochverfügbaren computerdienst Expired - Fee Related DE60100800T2 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US09/513,015 US7401114B1 (en) 1998-04-20 2000-02-25 Method and apparatus for making a computational service highly available
US513015 2000-02-25
PCT/US2001/005754 WO2001063402A2 (en) 2000-02-25 2001-02-23 Method and apparatus for making a computational service highly available

Publications (2)

Publication Number Publication Date
DE60100800D1 DE60100800D1 (de) 2003-10-23
DE60100800T2 true DE60100800T2 (de) 2004-07-01

Family

ID=24041567

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60100800T Expired - Fee Related DE60100800T2 (de) 2000-02-25 2001-02-23 Verfahren und einrichtung zur bereitstellung von einem hochverfügbaren computerdienst

Country Status (4)

Country Link
EP (1) EP1258127B1 (de)
AU (1) AU2001241685A1 (de)
DE (1) DE60100800T2 (de)
WO (1) WO2001063402A2 (de)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102005035698A1 (de) * 2005-07-27 2007-02-08 Fujitsu Siemens Computers Gmbh Verfahren zum Aufbau einer direkten, netzübergreifenden und abhörsicheren Kommunikationsverbindung
DE102005035697A1 (de) * 2005-07-27 2007-02-08 Siemens Ag Verfahren zum Aufbau einer direkten netzübergreifenden Kommunikationsverbindung
DE102009017791A1 (de) 2009-04-20 2010-10-21 Ronald Walther Telefonanordnung

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7401114B1 (en) * 1998-04-20 2008-07-15 Sun Microsystems, Inc. Method and apparatus for making a computational service highly available
US7730014B2 (en) * 2003-03-25 2010-06-01 Hartenstein Mark A Systems and methods for managing affiliations
JP4787684B2 (ja) 2006-06-15 2011-10-05 日本電気株式会社 セッション管理システム、セッション管理方法、及びプログラム
JP4293234B2 (ja) * 2006-12-05 2009-07-08 日本電気株式会社 シンクライアントにおける接続管理方法及び接続管理サーバ
US12353303B2 (en) * 2023-04-20 2025-07-08 International Business Machines Corporation Offloading a task from an edge server that is integrated with a moving vehicle

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3008850B2 (ja) * 1996-06-11 2000-02-14 日本電気株式会社 ネットワークサーバの冗長構成方式

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102005035698A1 (de) * 2005-07-27 2007-02-08 Fujitsu Siemens Computers Gmbh Verfahren zum Aufbau einer direkten, netzübergreifenden und abhörsicheren Kommunikationsverbindung
DE102005035697A1 (de) * 2005-07-27 2007-02-08 Siemens Ag Verfahren zum Aufbau einer direkten netzübergreifenden Kommunikationsverbindung
DE102009017791A1 (de) 2009-04-20 2010-10-21 Ronald Walther Telefonanordnung

Also Published As

Publication number Publication date
DE60100800D1 (de) 2003-10-23
EP1258127A2 (de) 2002-11-20
EP1258127B1 (de) 2003-09-17
WO2001063402A2 (en) 2001-08-30
WO2001063402A3 (en) 2002-02-21
AU2001241685A1 (en) 2001-09-03

Similar Documents

Publication Publication Date Title
DE60101841T2 (de) Verfahren und vorrichtung zum verteilen der last in einer rechnerumgebung
DE60100624T2 (de) Verfahren und vorrichtung zum verbessern der verwendung eines betriebsmittels auf einem verteilten klient
DE69328666T2 (de) Verfahren und Gerät um eine Anzahl Rechner als einen einzigen Host auf dem Netz erscheinen zu lassen
DE69933852T2 (de) Hausnetz- autokonfigurierung
DE60122782T2 (de) Adressierungsverfahren und system zur verwendung einer anycast-adresse
US7401114B1 (en) Method and apparatus for making a computational service highly available
DE60026231T2 (de) Verfahren und Vorrichtung zur Durchführung eines Schnellen Dienstnachschlagen in einem Neztwerkgruppen
DE60112115T2 (de) Erweiterungen eines signalisierungs-übertragungsprotokolls für lastausgleich undserverpool-unterstützung
DE60223264T2 (de) System und verfahren zur adressierung eines mobilen gerätes in einem ip-basierten drahtlosen netzwerk
DE10116640B4 (de) Auf URL beruhende Token für schwierige Verteilungen, die einen serverseitigen Cookiebehälter benutzen
DE69731965T2 (de) Zugriff auf rechnerbetriebsmittel von aussen durch eine firewall
DE60133648T2 (de) System und verfahren zum führen von laufzeitdaten in einem server-netzwerk
DE112020001459T5 (de) Konsistente Route-Ankündigungen zwischen redundanten Controllern im globalen Netzwerk-Access-Point
DE69915871T2 (de) Verfahren und vorrichtung für ein tcp/ip lastausgleich und wiederherstellung eines prozesses in einem internet protocol (ip) netzwerkgruppensystem.
DE60200451T2 (de) Herstellung einer gesicherten Verbindung mit einem privaten Unternehmensnetz über ein öffentliches Netz
DE69925996T2 (de) Verfahren und vorrichtung zur sitzungsverwaltung und benutzerauthentifizierung
DE69927713T2 (de) Angekündigte Sitzungsbeschreibung
DE69719963T2 (de) Proxyserversystem zur verbesserung der funktionalität von rechnern, die auf internetserver zugreifen
DE602005003301T2 (de) Verfahren zum Aufbau einer Verbindung zwischen Peer-Gruppen
DE60025129T2 (de) Verfahren und Vorrichtung zur Bereitstellung von skalierbaren Diensten unter Benutzung einer Paketverteilungstabelle
DE69533733T2 (de) Netzwerkverwaltungsverfahren
DE60102234T2 (de) Verfahren und vorrichtung zur ermittlung von benachbarten diensten
DE60212289T2 (de) Verwaltung privater virtueller Netze (VPN)
DE60311396T2 (de) Verfahren zur Gestaltung eines Peer-to-Peer Netzwerks mit Hilfe eines gemeinsamen Gruppenetiketts
DE60024763T2 (de) Verfahren und Vorrichtung zur Packetfragmentenweiterleitung

Legal Events

Date Code Title Description
8364 No opposition during term of opposition
8339 Ceased/non-payment of the annual fee