DE602004010703T2 - Eine persistente und zuverlässige sitzung, die neztwerkkomponenten unter verwendung eines verkapselungsprotokolls sicher durchläuft - Google Patents

Eine persistente und zuverlässige sitzung, die neztwerkkomponenten unter verwendung eines verkapselungsprotokolls sicher durchläuft Download PDF

Info

Publication number
DE602004010703T2
DE602004010703T2 DE602004010703T DE602004010703T DE602004010703T2 DE 602004010703 T2 DE602004010703 T2 DE 602004010703T2 DE 602004010703 T DE602004010703 T DE 602004010703T DE 602004010703 T DE602004010703 T DE 602004010703T DE 602004010703 T2 DE602004010703 T2 DE 602004010703T2
Authority
DE
Germany
Prior art keywords
ticket
client
protocol
connection
service
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 - Lifetime
Application number
DE602004010703T
Other languages
English (en)
Other versions
DE602004010703D1 (de
Inventor
Anatoliy Bellevue PANASYUK
Andre Cambourne KRAMER
Bradley Jay Parkland PEDERSEN
David Sean Lauderdale By-The-Sea STONE
Terry Highland Beach TREDER
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.)
Citrix Systems Inc
Original Assignee
Citrix Systems 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 US10/683,881 external-priority patent/US7562146B2/en
Application filed by Citrix Systems Inc filed Critical Citrix Systems Inc
Publication of DE602004010703D1 publication Critical patent/DE602004010703D1/de
Application granted granted Critical
Publication of DE602004010703T2 publication Critical patent/DE602004010703T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0209—Architectural arrangements, e.g. perimeter networks or demilitarized zones
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00—Digital computers in general; Data processing equipment in general
    • G06F15/16—Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
    • G06F15/163—Interprocessor communication
    • G06F15/173—Interprocessor communication using an interconnection network, e.g. matrix, shuffle, pyramid, star, snowflake
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H04L12/4633—Interconnection of networks using encapsulation techniques, e.g. tunneling
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0272—Virtual private networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0281—Proxies
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/166—Implementing security features at a particular protocol layer at the transport layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40—Support for services or applications

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Computing Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Mathematical Physics (AREA)
  • General Physics & Mathematics (AREA)
  • Multimedia (AREA)
  • Computer And Data Communications (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Communication Control (AREA)

Description

  • TECHNISCHES GEBIET
  • Die Erfindung betrifft allgemein Netzkommunikationen. Genauer erläutert, betrifft die Erfindung Systeme und Verfahren zur Wiederherstellung von Client-Kommunikationen, indem mittels Verwendung eines verkapselnden Kommunikationsprotokolls Netzkomponenten durchlaufen werden, um die Beständigkeit und Zuverlässigkeit einer Sitzung bereitzustellen.
  • HINTERGRUND-INFORMATION
  • Kommunikationen über ein Netz zwischen zwei Computern, z. B. einem Client und einem Server, können mittels Verwendung vielerlei bekannter Kommunikationsprotokolle implementiert werden. Für gewöhnlich kommuniziert der Client mit dem Server, um über das Netz den Inhalt vom Server herunterzuladen. Zum Beispiel kann der Server eine oder mehrere Applikationen, auf die der Client zugreifen kann, unterbringen (hosten). Darüber hinaus kann der Client über einen Proxy, der für gewöhnlich ein Sicherheits-Gateway wie beispielsweise ein Router oder eine Firewall ist, durch den der Inhalt vom Server passiert, mit dem Server kommunizieren. Zusätzlich kann der Server ein Firewall einschließen, um nicht authorisierte Kommunikationen an den und vom Server zu verbieten. Der Client erlangt mittels der Sicherheit des Proxys und der Firewall des Servers Zugriff auf den Server. Jedoch ist häufig die Netzverbindung, die den Server über einen Proxy durchläuft, für einen Zusammenbruch anfällig. Zum Beispiel ist eine drahtlose Verbindung zwischen einem Client und einem Proxy oftmals unzuverlässig. In anderen Fällen ist die Netzverbindung intermittierend. Als solche kann eine Verbindung verloren gehen, wenn man in einen Aufzug oder Tunnel tritt, und kann nur wiederhergestellt werden, wenn man dem Ausgang aus dem Aufzug oder aus dem Tunnel folgt.
  • Wenn eine zwischen dem Client und dem Computer des Servers errichtete Kommunikation auf eine anormale Weise endet, muss der Client im allgemeinen die Verbindung widerherstellen, indem er eine neue Kommunikationssitzung beginnt. Um die neue Kommunikationssitzung anzufangen, muss der Anwender für gewöhnlich erneut seine Authentifikationslegitimierung wie beispielsweise das Login/Passwort-Paar an den Proxy und Server-Computer senden, so dass der Anwender für die neue Kommunikationssitzung berechtigt werden kann. Diese Neuübertragung seiner Authentifikationslegitimierung in einer Vielzahl von Kommunikationssitzungen setzt die Authentifikationslegitimierung dieses Anwender wiederholt möglichen Angriffen aus, wodurch der Sicherheitsgrad der Authentifikationslegitimierung gesenkt wird. Wenn ein Angreifer die Sicherheit des Proxys oder der Firewall des Servers umgeht, kann der Angreifer darüber hinaus Zugriff auf den Inhalt innerhalb des Servers erlangen, ohne auf zusätzliche Sicherheitskontrollen zu stoßen. Zusätzlich ist die Wiedereingabe der Authentifikationslegitimierung für den Anwender oftmals ein langsamer Vorgang, der zur Frustration und Ineffizienz des Anwenders führen kann.
  • Wenn man über eine Netzverbindung mittels Verwendung vieler aktueller Protokolle kommuniziert, gehen Datenpakete verloren, wenn die Netzverbindung unterbrochen wird. Wenn man z. B. über eine Standard-TCP-Netzverbindung kommuniziert, werden z. B. Datenpuffer bei Unterbrechung der Verbindung für gewöhnlich geflusht. Somit kann eine vernetzte Applikation wie beispielsweise eine Anwender-Sitzung an einem Server nicht mehr dort wiederaufgenommen werden, wo sie unterbrochen wurde, wenn die Netzverbindung wiederhergestellt wird. Für gewöhnlich wird eine Fehlernachricht angezeigt, womit der Anwender unvorteilhafter noch frustrierter wird. Außerdem erfordert das Kommunizieren über ein Netz mit vielen Protokollen oft das häufige Wiederherstellen der Transportverbindung. Indem man z. B. das HTTP entweder selber oder in Verbindung mit einem Proxy-Protokoll verwendet, um eine Webseite über eine Standard-TCP-Verbindung zu browsen, ist zusätzlich zu einer neuen HTTP-Verbindung für jede Ressource die Schließung einer vorherige TCP/Proxy-Protokoll-Verbindung und das Öffnen einer neuen TCP/Proxy-Protokoll-Verbindung für jede Ressource erforderlich.
  • Solchermaßen ist es wünschenswert, eine Technik zum Wiederherstellen einer Kommunikationssitzung zwischen einem Client-Computer und einem Server-Computer bereitzustellen, ohne die wiederholte Übertragung der Authentifikationslegitimierung des Clients nötig zu haben, während der Schutz des Servers vor unberechtigten Anwendern erhöht wird. Verbesserte Systeme und Verfahren sind zum Wiederherstellen einer Kommunikationssitzung zwischen einem Client-Computer und einem Server-Computer erforderlich, ohne wiederholt die Authentifikationslegitimierung zu übertragen, damit mehrere Netzkomponenten sicher durchlaufen werden.
  • Die US-Veröffentlichung 2003/0163569 betrifft allgemein einen Pro-Hop-Ticket-Mechanismus, um jede der mehreren Verbindungen zwischen einem Client und einem Server zu authentifizieren. Die Veröffentlichung WO/0223362 betrifft allgemein einen Mechanismus, der an der Transportschnittstelle des Netzstapels arbeitet, der Kommunikationen aus einer Applikation abfängt und sie mittels Verwendung eines Remote-Prozedur-Aufrufs über ein Internet-Mobilitäts-Protokoll sendet, um Kommunikationen zwischen einem Proxy-Server und jedem Mobil-Endsystem zu errichten.
  • Zusammenfassung der Erfindung
  • Die vorliegende Erfindung betrifft Systeme und Verfahren zum Wieder-Verbinden eines Clients für eine persistente und zuverlässigen Verbindung mit einem Host-Service, in dem die Verbindung auf eine sichere Weise Netzkomponenten durchläuft. Das Wieder-Verbinden des Clients schließt das Wiederherstellen der Client-Verbindung mit dem Host-Service und die Wieder-Authentifizierung des Anwenders des Clients für den Host-Service ein, und zwar einschließlich der Wieder-Authentifizierung von einer oder mehreren Verbindungen zwischen dem Client und dem Host-Service. Eine persistente und zuverlässige Verbindung mit einem Host-Service wird durch einen oder mehrere erste Protokoll-Service im Auftrag eines Clients erhalten. Die ersten Protokoll-Service gewährleisten, dass die zwischen dem Client und dem Host-Service kommunizierten Daten gepuffert werden und während jeder Unterbrechung in der Netzverbindung zwischen dem Client und dem Host-Service erhalten bleiben. Eine vorübergehende Unterbrechung in einer Netzverbindung kann z. B. auftreten, wenn ein Client wie beispielsweise ein Mobil-Client zwischen verschiedenen Zugangspunkten im selben Netz roamt oder wenn ein Client zwischen Netzen schaltet (z. B. von einem verdrahteten Netz zu einem drahtlosen Netz).
  • Zusätzlich zum Beibehalten der gepufferten Daten während einer Netzunterbrechung wieder-authentifiziert der erste Protokoll-Service den Client für den Host-Service, wenn die Verbindung des Clients mit dem ersten Protokoll-Service wiederhergestellt wird. Dies verhindert, dass der Anwender des Clients neuerlich Authentifikationslegitimierung eingeben muss, um seine Verbindung mit dem Host-Service wiederherzustellen. Außerdem wird jede der mehreren Verbindungen zwischen dem Client und dem Host-Service z. B. über einen als Proxy wirkenden Protokoll-Service wieder-authentifiziert, um den zusätzlichen Sicherheitsschutz beim Zugreifen auf den Host-Service bereitzustellen. Nach der Wieder-Authentifizierung wieder-verbindet der erste Protokoll-Service die Verbindung des Clients mit dem Host-Service. Zusammengefasst sorgt die vorliegende Erfindung für das Wiederherstellen einer Netzverbindung zwischen einem Client und einem Host-Service, um auf sichere Weise Netzkomponenten bis zum Server zu durchlaufen, und ohne dass der Anwender neuerlich Authentifikationslegitimierung eingeben muss.
  • In einer Hinsicht betrifft die vorliegende Erfindung ein Verfahren zum Wieder-Verbinden eines Clients mit einem Host-Service. Das Verfahren umfasst den Schritt zum Bereitstellen einer Kommunikationssitzung zwischen einem Client und einem Host-Service über eine erste Verbindung zwischen dem Client und einem ersten Protokoll-Service und eine zweite Verbindung zwischen dem ersten Protokoll-Service und dem Host-Service. Das Verfahren umfasst weiterhin das Erfassen einer Unterbrechung entweder in der ersten Verbindung oder der zweiten Verbindung und das Aufrechterhalten der jeweils anderen Verbindung, entweder der ersten oder der zweiten Verbindung. In einem anderen Verfahrensschritt erhält der erste Protokoll-Service ein erstes Ticket und ein zweites Ticket und validiert das erste Ticket, um die unterbrochene Verbindung wiederherzustellen. Der erste Protokoll-Service validiert das zweite Ticket, um mit der Benutzung der aufrechterhaltenen Verbindung fortzufahren, und verbindet die wiederhergestellte Verbindung mit der aufrechterhaltenen Verbindung.
  • In einer Ausführungsform umfasst das Verfahren das Beibehalten der Kommunikationssitzung während der Unterbrechung in der unterbrochenen Verbindung. In einer anderen Ausführungsform umfasst das Verfahren weiterhin das Erzeugen entweder des ersten Tickets oder des zweiten Tickets zumindest entweder durch den ersten Protokoll-Service oder eine Ticket-Autorität. Das Verfahren kann einschließen, dass durch die Ticket-Autorität mindestens entweder das erste Ticket oder das zweite Ticket validiert werden.
  • In einer anderen Ausführungsform umfasst das Verfahren weiterhin, dass der Client für einen Web-Server berechtigt wird und dem Client durch den Web-Server das erste Ticket zugesendet wird. Das Verfahren kann weiterhin umfassen, dass der Host-Service den Client für das Errichten der Kommunikationssitzung berechtigt. In einer Ausführungsform schießt das Verfahren das Senden des ersten Tickets an den ersten Protokoll-Service durch den Client ein.
  • In einer weiterhin Ausführungsform umfasst der erste Protokoll-Service einen Proxy-Server. In einer anderen Ausführungsform umfasst der erste Protokoll-Service ein Sicherheits-Gateway. Das Verfahren kann weiterhin einschließen, dass der Client und der erste Protokoll-Service mittels Verwendung eines ersten Protokolls, das ein zweites Protokoll beinhaltet, kommunizieren, und dass der erste Protokoll-Service und der Host-Service mittels Verwendung des zweiten Protokolls kommunizieren.
  • In einer anderen Ausführungsform ist das erste Ticket für die erste Verbindung gültig und das zweite Ticket für die zweite Verbindung gültig. Wahlweise kann das zweite Ticket gesperrt werden, bis das erste Ticket validiert ist. In einer Ausführungsform wird die wiederhergestellte Verbindung mit der aufrechterhaltenen Verbindung verbunden, nachdem das erste Ticket und das zweite Ticket validiert wurden.
  • In einer weiteren Ausführungsform können entweder die erste Verbindung oder die zweite Verbindung oder beide Verbindungen mehrere Verbindungen umfassen, die über einen Zwischenknoten oder einen oder mehrere erste Protokoll-Dienste verbunden werden. Das Verfahren kann weiterhin das Erzeugen eines dritten Tickets für mindestens eine der mehreren Verbindungen einschließen. Das dritte Ticket kann für mindestens eine der mehreren Verbindungen gültig sein.
  • In einer anderen Hinsicht betrifft die vorliegende Erfindung ein System zum Wieder-Verbinden eines Clients mit einem Host-Service. Das System umfasst einen Client und einen ersten Protokoll-Service. Der Client errichtet über eine erste Verbindung eine Kommunikationssitzung mit einem Host-Service. Der erste Protokoll-Service errichtet die erste Verbindung mit dem Client und eine zweite Verbindung mit dem Host-Service. Der erste Protokoll-Dienst hält eine Verbindung aufrecht, die mindestens eine Verbindung, die erste oder die zweite, umfasst. Darüber hinaus validiert der erste Protokoll-Dienst ein erstes Ticket, um eine unterbrochene Verbindung entweder in der ersten oder zweiten Verbindung wiederherzustellen, und validiert ein zweites Ticket, um die jeweils andere Verbindung, entweder die erste oder die zweite, zu verwenden. Das System schließt weiterhin den ersten Protokoll-Dienst ein, der die wiederhergestellte Verbindung mit der aufrechterhaltenen Verbindung verknüpft.
  • In einer Ausführungsform umfasst das System weiterhin eine Ticket-Autorität, die zumindest ein Ticket, das erste oder das zweite Ticket, erzeugt. In einer anderen Ausführungsform hält der erste Protokoll-Dienst die Kommunikationssitzung während einer Unterbrechung in der unterbrochenen Verbindung aufrecht. In einer weiteren Ausführungsform erzeugt der erste Protokoll-Dienst zumindest entweder ein erstes Ticket oder ein zweites Ticket. Das System kann die Ticket-Autorität einschließen, die mindestens ein Ticket, das erste oder das zweite, validiert.
  • In einer anderen Ausführungsform umfasst das System weiterhin einen Web-Server. Der Web-Server berechtigt den Client und sendet in einer anderen Ausführungsform das erste Ticket an den Client. In einer weiteren Ausführungsform sendet der Client das erste Ticket an den ersten Protokoll-Dienst. In wiederum einer anderen Ausführungsform berechtigt der Host-Dienst den Client beim Errichten der Kommunikationssitzung.
  • In einer anderen Ausführungsform umfasst der erste Protokoll-Dienst einen Proxy-Server und in einer anderen Ausführungsform kann der erste Protokoll-Dienst ein Sicherheits-Gateway umfassen. Das System kann den Client und den ersten Protokoll-Dienst, die mittels Verwendung eines ersten Protokolls kommunizieren, das ein zweites Protokoll beinhaltet, und den ersten Protokoll-Dienst und den Host-Dienst einschließen, die mittels Verwendung des zweiten Protokolls kommunizieren.
  • In einer weiteren Ausführungsform ist das erste Ticket für die erste Verbindung gültig und das zweite Ticket für die zweite Verbindung gültig. Zusätzlich kann das zweite Ticket gesperrt werden, bis das zweite Ticket validiert ist. In einer Ausführungsform verbindet der erste Protokoll-Dienst die wiederhergestellte Verbindung mit der aufrechterhaltenen Verbindung, nachdem das erste Ticket und das zweite Ticket validiert wurden.
  • In wiederum einer weiteren Ausführungsform umfasst entweder die erste Verbindung oder die zweite Verbindung mehrere Verbindungen, die über einen Zwischenknoten und einen oder mehrere erste Protokoll-Dienste verbunden sind. Das System schließt weiterhin das Erzeugen eines dritten Tickets für mindestens eine der mehreren Verbindungen ein, und in einer Ausführungsform ist das dritte Ticket für mindestens eine der mehreren Verbindung gültig.
  • Die Details der verschiedenen Ausführungsformen der Erfindung werden in den begleitenden Zeichnungen und in der Beschreibung unten geschildert.
  • Kurze Beschreibung der Zeichnungen
  • Die vorherigen und andere Aufgaben, Aspekte, Merkmale und Vorteile der Erfindung werden offensichtlicher und besser verständlich, wenn man auf die folgende Beschreibung Bezug nimmt, die in Verbindung mit den begleitenden Zeichnungen vorgenommen wird, in denen:
  • 1A ein Blockdiagramm eines Systems gemäß einer darstellenden Ausführungsform der Erfindung ist, um einem Client eine zuverlässige Verbindung mit einem Host-Dienst zur Verfügung zu stellen;
  • 1B ein Blockdiagramm eines Systems gemäß einer anderen darstellenden Ausführungsform der Erfindung ist, um einem Client eine zuverlässige Verbindung zu einem Host-Dienst zur Verfügung zu stellen;
  • 2B gemäß einer anderen darstellenden Ausführungsform der Erfindung Kommunikationen zeigt, die in einem Netz auftreten;
  • 3 ein Verfahren gemäß einer darstellenden Ausführungsform der Erfindung zum Einschließen mehrerer sekundärer Protokolle in einem ersten Protokoll zeigt, um über ein Netz zu kommunizieren;
  • 4 ein Ablaufdiagramm ist, das in Übereinstimmung mit der Erfindung eine Ausführungsform des Betriebs des Kommunikationssystems der 1A–1B darstellt;
  • 5A ein Blockdiagramm einer anderen Ausführungsform eines Kommunikationssystems ist, das in Übereinstimmung mit der Erfindung aufgebaut ist;
  • 5B ein Ablaufdiagramm ist, das in Übereinstimmung mit der Erfindung eine Ausführungsform des Betriebs des Kommunikationssystems der 5A darstellt;
  • 6A ein Blockdiagramm des darstellenden Systems aus 1A ist, das gemäß einer darstellenden Ausführungsform der Erfindung Komponenten zum Wieder-Verbinden des Clients mit einem Host-Dienst einschließt;
  • 6B ein Blockdiagramm des darstellenden Systems aus 6A ist, das gemäß einer anderen darstellenden Ausführungsform der Erfindung Komponenten zum anfänglichen Verbinden des Clients mit einem Host-Dienst einschließt;
  • 6C ein Blockdiagramm des darstellenden Systems der
  • 6B ist, das gemäß einer anderen darstellenden Ausführungsform der Erfindung eine Komponente zum anfänglichen Verbinden des Clients mit dem Host-Dienst und zum Wieder-Verbinden des Clients mit dem Host-Dienst einschließt;
  • 6D ein Blockdiagramm einer alternativen Ausführungsform des Systems aus 6C ist;
  • 7 ein Ablaufdiagramm eines Verfahrens für Netzkommunikationen gemäß einer darstellenden Ausführungsform der Erfindung ist;
  • die 8A–8C Ablaufdiagramme eines Verfahrens zum Verbinden eines Clients mit mehreren Host-Diensten gemäß einer darstellenden Ausführungsform der Erfindung sind;
  • 9 ein Ablaufdiagramm eines Verfahrens gemäß einer darstellenden Ausführungsform der Erfindung ist, um einem Client eine zuverlässige Verbindung mit Host-Diensten zur Verfügung zu stellen und um den Client neuerlich mit den Host-Diensten zu verbinden; und
  • die 10A–10B Ablaufdiagramme eines Verfahrens gemäß einer darstellenden Ausführungsform der Erfindung zum Wieder-Verbinden eines Clients mit Host-Diensten sind.
  • Beschreibung
  • Gewisse Ausführungsformen der vorliegenden Erfindung werden unten beschrieben. Es sei jedoch ausdrücklich angemerkt, dass die vorliegende Erfindung nicht auf diese Ausführungsformen eingeschränkt ist, sondern es die Absicht ist, dass innerhalb des Schutzumfangs der Erfindung auch Zusätze und Modifikationen dessen, was hierin ausdrücklich beschrieben wird, eingeschlossen sind. Es sollte ebenfalls verständlich sein, dass die Merkmale der hierin beschriebenen verschiedenen Ausführungsformen für beide Seiten nicht ausschließlich sind und, ohne sich vom Geist und Schutzumfang der Erfindung zu lösen, in verschiedenen Kombinationen und Vertauschungen existieren können, selbst wenn diese Kombinationen und Vertauschungen nicht ausdrücklich hierin vorgenommen werden.
  • Die darstellende Ausführungsform der vorliegenden Erfindung stellt Systeme und Verfahren bereit, um eine zuverlässige und persistente Verbindung zwischen einem Client und einem Host-Dienst zu errichten und die Verbindung wiederherzustellen, wenn es in der Verbindung eine Unterbrechung gibt. Ein Client errichtet mithilfe einer ersten Verbindung zwischen einem Client und einem ersten Protokoll-Dienst und einer zweiten Verbindung zwischen dem ersten Protokoll-Dienst und dem Host-Dienst eine Kommunikationssitzung mit einem Host-Dienst. Der Client kommuniziert mittels Verwendung eines ersten Protokolls mit dem ersten Protokoll-Dienst und der erste Protokoll-Dienst kommuniziert mittels Verwendung eines zweiten Protokolls mit dem Host-Dienst. Das zweite Protokoll wird vom Client dem ersten Protokoll-Dienst mitgeteilt, der in den ersten Protokoll-Kommunikationen eingeschlossen ist. Wenn entweder in der ersten Verbindung oder der zweiten Verbindung eine Unterbrechung erfasst wird, stellt der erste Protokoll-Dienst die unterbrochene Verbindung wieder auf, während er die Verbindung aufrechterhält, die nicht unterbrochen wurde. Die unterbrochene Verbindung wird mit der aufrechterhaltenen Verbindung verknüpft, um den Client wieder mit dem Host-Dienst zu verbinden.
  • Darüber hinaus stellt die darstellende Ausführungsform der vorliegenden Erfindung Systeme und Verfahren bereit, um beim Errichten und Wieder-Verbinden eines Clients mit einem Host-Dienst auf sichere Weise Netzkomponenten zu durchlaufen. Der erste Protokoll-Dienst kann als Proxy zwischen dem Client und dem Host-Dienst wirken und somit ein Sicherheits-Gateway umfassen. Der erste Protokoll-Dienst erhält ein erstes Ticket und ein zweites Ticket von einer Ticket-Autorität. Das erste Ticket wird verwendet, um die Verbindung zwischen dem Client und dem ersten Protokoll-Dienst zu validieren, und das zweite Ticket wird verwendet, um die Verbindung zwischen dem ersten Protokoll-Dienst und dem Host-Dienst zu validieren. Das zweite Ticket kann gesperrt werden, bis das erste Ticket validiert ist. Der erste Protokoll-Dienst validert das erste Ticket beim Wiederherstellen oder Aufrechterhalten der Verwendung der ersten Verbindung und validert das zweite Ticket beim Wiederherstellen oder Aufrechterhalten der Verwendung der ersten Verbindung. Wenn das erste und zweite Ticket validiert sind und die Verbindungen wie derhergestellt sind, verbindet der erste Protokoll-Dienst die erste Verbindung mit der zweiten Verbindung, um die Kommunikationssitzung des Clients mit dem Host-Dienst aufrechtzuerhalten. Zusätzliche Tickets können für das Wiederherstellen oder Beibehalten der zusätzlichen Anwender-Verbindung oder "Hops" zwischen dem Client und dem Host-Dienst erzeugt und validiert werden. Auf diese Weise wird jede Verbindung oder jeder "Hop" zwischen dem Client und dem Host-Dienst validiert.
  • Auf 1A Bezug nehmend, betrifft die Erfindung Netzkommunikationen und kann besonders nützlich dabei sein, einem Client eine zuverlässige Verbindung mit einem Host-Dienst bereitzustellen. In einem allgemeinen Überblick schließt ein System 100 für Netzkommunikationen einen Client 108 (z. B. eine erste Computervorrichtung) ein, die über ein Netz 104 mit einem ersten Protokoll-Dienst 112 (z. B. eine zweite Computervorrichtung) in Kommunikation steht. Im System 100 sind auch mehrere Host-Dienste 116a–116n eingeschlossen, die an einem Host-Knoten 188 (z. B. dritte Computervorrichtung) residieren und mit dem ersten Protokoll-Dienst 112 in Verbindung stehen und mittels des ersten Protokoll-Dienstes 112 und über das Netz 104 mit dem Client in Verbindung stehen. Alternativ werden in einer anderen darstellenden Ausführungsform der Erfindung und jetzt unter Bezugnahme auf 1B der erste Protokoll-Dienst 112 und die Host-Dienste 116a–116n, wie in 1A gezeigt, nicht an unabhängigen Computervorrichtungen implementiert, sondern lieber in derselben Computervorrichtung wie beispielsweise dem Host-Knoten 118a eingeschlossen. In 1B kommunizieren die Host-Dienste 116a–116n über das Netz 104' mit dem ersten Protokoll-Dienst 112. Das System 100 kann ein, zwei oder irgendeine Anzahl an Host-Knoten 118a–118n einschließen.
  • In einer Ausführungsform sind die Netze 104 und 104' getrennte Netze wie in 1B. Die Netze 104 und und 104' können, wie in 1A gezeigt, dasselbe Netz 104 sein. In einer Ausführungsform ist das Netz 104 und/oder das Netz 104' z. B. ein lokales Netz (LAN) wie beispielsweise ein Intranet einer Gesellschaft oder ein weiträumiges Netz (WAN) wie beispielsweise Internet oder das World Wide Web. Der Client 108, der erste Protokoll-Dienst 112, die Host-Dienste 116a–116n und/oder die Host-Knoten 118a–118n können mittels einer Vielfalt an Verbindungen einschließlich (ohne darauf beschränkt zu sein) Standard-Telefonleitungen, LAN- oder WAN-Verbindungen (z. B. 802.11, T1, T3, 56kb, X.25) Breitbandverbindungen (z. B. ISDN, Frame Relay, ATM), drahtlosen Verbindungen oder irgendeiner Kombination aus einigen oder allen oben aufgeführten Verbindungen mit den Netzen 104 und/oder 104' verbunden werden.
  • Der Client 108 steht über den ersten Client-Protokoll-Dienst-Nachrichtenkanal 135 mit dem ersten Protokoll-Dienst 112 in Verbindung und auch über den Client-Web-Server-Nachrichtenkanal 140 mit dem Web-Server 120 in Verbindung. Der erste Protokoll-Dienst 112 steht über einen ersten Protokoll-Dienst-Autoritäts-Nachrichtenkanal 145 mit der Ticket-Autorität 136 in Verbindung, und der Web-Server 120 steht über einen Web-Server-Autoritäts-Nachrichtenkanal 150 mit der Ticket-Autorität 136 in Verbindung. Der erste Protokoll-Dienst 112 steht auch über erste Protokoll-Dienst-Server-Nachrichtenkanäle 124a–124n mit dem Host-Knoten 118 in Verbindung. In einer anderen Ausführungsform kann der Web-Server 120 über einen Agent-Server-Nachrichtenkanal 155 mit dem Host-Knoten 118 kommunizieren. Ähnlich kann der Host-Knoten 118 über einen Ticket-Server-Nachrichtenkanal 157 mit der Ticket-Autorität 136 kommunizieren. In einer Ausführungsform werden die jeweiligen Nachrichtenkanäle 124a–124n, 135, 140, 145, 160, 155, 157 über das Netz 104 errichtet.
  • Exemplarische Ausführungsformen der Nachrichtenkanäle 124a–124n, 135, 140, 144, 150, 155, 157 schließen Standard-Telefonleitungen, LAN- oder WAN-Verbindungen (z. B. T1, T3, 56kb, X.25) Breitbandverbindungen (z. B. ISDN, Frame Relay, ATM) und drahtlose Verbindungen ein. Die Verbindungen über die Nachrichtenkanäle 124a–124n, 135, 140, 144, 150, 155, 157 können mittels Verwendung einer Vielfalt an Kommunikationsprotokollen (z. B. HTTP, HTTPS, TCP/IP, IPX, SPX, NetBIOS, Ethernet, RS232, ein Messaging-Application-Programming-Interface-(MAPI)-Protokoll, Echtzeit-Streaming-Protokoll (RTSP), Echtzeit-Streaming-Protokoll, das für ein Anwender-Datagram-Protokoll-Schema (RTSPU) verwendet wird, das von RealNetworks, Inc. aus Seattle, WA, entwickelte Progressive Networks Multimedia-(PNM)-Protokoll, das Manufacturing-Message-Specification-(MMS)-Protokoll und direkte asynchrone Verbindungen) verbunden werden.
  • In einem anderen Aspekt zeigt 1A ein Blockdiagramm einer Ausführungsform eines Kommunikationssystems 100 für die sichere Abgabe von Inhalten. In einer Ausführungsform umfasst der erste Protokoll-Dienst 112 einen Proxy 115 und das System 100 schließt einen Web-Server 120 und eine Ticket-Autorität 136 ein. Das System 100 schließt auch zwei Firewalls 160, 161 ein, die die nicht berechtigten Mitteilungen an den/vom Host-Knoten 118 verbieten. Das Netz zwischen den Firewalls 160, 161 wird häufig als eine "entmilitarisierte Zone" (DMZ) 130 bezeichnet. In einer Ausführungsform schließt. die DMZ 130 den Ticket-Protokoll-Dienst 112 ein, der einen Proxy 115 und den Web-Server 120 umfasst.
  • Die DMZ 130 trennt die Host-Dienste 116a–116n von den Komponenten (z. B. erster Protokoll-Dienst 112) des Systems 100, auf die durch nicht berechtigte Personen zugegriffen werden kann. Wie oben beschrieben, wird die DMZ 130 mit zwei Firewalls 160, 161 entworfen, die die nicht berechtigte Kommunikation verbieten. Der erste Firewall 160 und der zweite Firewall 161 legen jeweils eine Reihe von taktisch festgelegten Regeln an, um zu bestimmen, welche Nachrichten die DMZ 130 durchlaufen können. In einer Ausführungsform legen der erste Firewall 160 und der zweite Firewall 161 dieselbe Gruppe an taktisch vereinbarten Regeln an. Alternativ können der erste Firewall 160 und der zweite Firewall 161 verschiedene Gruppen an taktisch vereinbarten Regeln anlegen. Jeder Firewall 160, 161 kann ein Router, Computer oder irgendeine andere Netz-Zugriff-Steuervorrichtung sein. In einer anderen Ausführungsform schließt das System 100 einen der Firewalls 160, 161 oder keinen Firewall 160, 160 ein. In einer anderen Ausführungsform wird einer der Firewalls 160, 161 am Host-Knoten 118 eingesetzt. In einer anderen Ausführungsform (nicht gezeigt) wird einer oder mehrere der Firewalls 160, 161 an einem Zwischenknoten eingesetzt.
  • In einer Ausführungsform schießt der erste Protokoll-Dienst 112 einen Proxy 115 ein, der ein Sicherheits-Gateway umfasst, durch das Nachrichten über den ersten Client-Protokoll-Dienst-Nachrichtenkanal 135 dringen müssen. In einer Ausführungsform lehnt der Netz-Firewall 160 alle ankommenden Nachrichten vom ersten Client-Protokoll-Dienst-Nachrichtenkanal 135 ab, die nicht den ersten Protokoll-Dienst 112 als ihren Bestimmungsort haben. Auf ähnliche Weise lehnt der Netz-Firewall 160 lehnt der Netz-Firewall alle herausgehenden Nachrichten für den ersten Client-Protokoll-Dienst-Nachrichtenkanal 135 ab, sofern ihre Quelle der erste Protokoll-Dienst 112 ist. Obwohl als ein Proxy 115 des ersten Protokoll-Dienstes 112 dargestellt, kann das Sicherheits-Gateway alternativ ein Router, Firewall, Relais oder irgendeine Netzkomponente sein, die die erforderliche Sicherheit bereitstellen kann. In einer anderen Ausführungsform ist der Proxy 115 eine vom ersten Protokoll-Dienst 112 unabhängige Komponente, die an derselben Computervorrichtung des ersten Protokoll-Dienstes 112 oder an einer anderen Computervorrichtung ablaufen kann. Zum Beispiel ist der Proxy 115 in 1B vom ersten Protokoll-Dienst 112 getrennt. Der Proxy 115 ist die DMZ 130 mit dem Web-Server 120. Mehrere Instanzen des ersten Protokoll-Dienstes 112 laufen auf jedem der Host-Knoten 118a-118n. Jeder erste Protokoll-Dienst 112 kommuniziert über den Nachrichtenkanal 135, der der erste Client-Protokoll-Dienst-Nachrichtenkanal 135 ist, mit dem Proxy 115. In diesem Fall ist die Proxy-(115)-Komponente ein Zwischenknoten für das sichere Weiterleiten der Kommunikationen zwischen dem Client 108 und dem ersten Protokoll-Dienst 112.
  • Das Netz 104 kann ein lokales Netz (LAN), ein weiträumiges Netz (WAN) oder ein Netzwerk aus Netzen wie beispielsweise Internet oder dem World Wide Web (d. h. Web) sein. Die jeweiligen Nachrichtenkanäle 124a–124n, 135, 140, 145, 150, 155, 157 können jeweils ein Teil eines anderen Netzes sein. Zum Beispiel kann der erste Client-Protokoll-Dienst-Nachrichtenkanal 135 einem ersten Netz (z. B. dem World Wide Web) angehören und der Client-Web-Server-Nachrichtenkanal 140 einem zweiten Netz (z. B. einem gesicherten Extranet oder Virtual Private Network (VPN)) angehören. In anderen Ausführungsformen überbrückt das Netz 104 die DMZ 230 und auch die Serverfarm 169, und darin wird dasselbe Kommunikationsprotokoll verwendet. In einigen Ausführungsformen trennt kein Firewall 160 den ersten Protokoll-Dienst 112 und Web-Server 120 vom Host-Knoten 115 und der Ticket-Autorität 136.
  • Exemplarische Ausführungsformen der Nachrichtenkanäle 124a–124n, 135, 140, 144, 150, 155, 157 schließen Standard-Telefonleitungen, LAN- oder WAN-Verbindungen (z. B. 802.11, T1, T3, 56kb, X.25) Breitbandverbindungen (z. B. ISDN, Frame Relay, ATM) und drahtlose Verbindungen ein. Die Verbindungen über die Nachrichtenkanäle 124a–124n, 135, 140, 144, 150, 155, 157 können mittels Verwendung einer Vielfalt an Kommunikationsprotokollen (z. B. HTTP, HTTPS, TCP/IP, IPX, SPX, NetBIOS, Ethernet, RS232, ein Messaging-Application-Programming-Interface-(MAPI)-Protokoll, Echtzeit-Streaming-Protokoll (RTSP), Echtzeit-Streaming-Protokoll, das für ein Anwender-Datagram-Protokoll-Schema (RTSPU) verwendet wird, das von RealNetworks, Inc. aus Seattle, WA, entwickelte Progressive Networks Multimedia-(PNM)-Protokoll, das Manufacturing-Message-Specification-(MMS)-Protokoll und direkte asynchrone Verbindungen) verbunden werden.
  • Der Client 108 kann irgendeine Workstation, ein Desktoprechner, Laptop, Hand-Computer, Mobiltelefon, ein intelligentes oder ein dummes Terminal, ein Netzcomputer, eine drahtlose Vorrichtung, Informationsvorrichtung, ein Minicomputer, Großrechner oder eine andere Coputer- oder Telekommunikationsvorrichtungsform sein, die zum Kommunizieren in der Lage ist und genug Prozessorleistung und Speicherkapazität hat, um die hierin beschriebenen Betriebe durchzuführen. Zusätzlich kann der Client 108 ein lokaler Desktop-Client an einem lokalen Netz 104 oder ein Fernanzeige-Client eines unabhängigen Netzes 104' sein. Der Client 108 kann z. B. eine visuelle Anzeigevorrichtung (z. B. ein Computerbildschirm), eine Dateneingabevorrichtung (z. B. eine Tastatur), ein ständiger oder flüchtiger Speicher (z. B. Computerspeicher), ein Prozessor und eine Mouse sein. Vom Client 108 unterstützte Betriebssysteme können irgendein Glied aus der Windows-Familie an Betriebssystemen von der Microsoft Corporation aus Redmond, Washington, ein Macintosh-Betriebssystem, JavaOS und verschiedene Varianten von Unix (z. B. Solaris, SunOS, Linux, HP-UX, A/IX und BSD-zugrundeliegende Verteiler) oder irgendein anderes Betriebssystem sein, das in der Lage ist, einen Client 108 beim Durchführen der hierin beschriebenen Betriebe zu unterstützen.
  • In einer Ausführungsform schließt der Client 108 einen Web-Browser 162 wie beispielsweise INTERNET EXPLORER ein, der von der Microsoft Corporation in Redmond, WA entwickelt ist, um sich mit dem Web zu verbinden. In einer weiteren Ausführungsform verwendet der Web-Browser 162 die bestehende Secure Socket Layer-(SSL)-Unterstützung, um den sicheren Client-Web-Server-Nachrichtenkanal 140 mit dem Web-Server 120 zu verbinden. Der SSL ist ein Sicherheitsprotokoll, das von der Netscape Communication Corporation aus Mountain View, Kalifornien, entwickelt wurde und jetzt ein Standard ist, der von der Internet Engineering Task Force (IETF) verbreitet wird.
  • In einigen Ausführungsformen ist, wie in den 1A und 1B gezeigt, ein Client-Agent 128 im Client 108 eingeschlossen. Der Client-Agent 128 kann zum Errichten und Austauschen von Kommunikationen mit dem Host-Dienst 116a–116n über den ersten Client-Protokoll-Dienst-Nachrichtenkanal 135 verwendet werden. Der Client-Agent 128 kann z. B. als Software-Programm und/oder Hardware-Vorrichtung wie beispielsweise ein ASIC oder ein FPGA implementiert sein. Der Client-Agent 128 kann jede Protokollart verwenden und kann z. B. ein HTTP-Client-Agent, ein FTP-Client-Agent, ein Oscar-Client-Agent oder ein Telnet-Client-Agent sein. In einer Ausführungsform ist der Client-Agent 128 ein ICA-Client, der von Citrix Systems, Inc. aus Fort Lauderdale, Florida entwickelt ist und der hiernach als ICA-Client 128 bezeichnet wird. Andere Ausführungsformen des Client-Agents 128 umfassen einen RDP-Client, der von der Microsoft Corporation aus Redmond, Washingten entwickelt wurde, einen Dateneingabe-Client in einer herkömmlichen Client/Server-Applikation, eine ActiveX-Steuerung oder ein Java-Applet. In einigen Ausführungsformen ist der Client-Agent 128 seinerseits aufgebaut, um mittels Verwendung des ersten Protokolls zu kommunizieren. In einigen Ausführungsformen (nicht gezeigt) schließt der Client 108 mehrere Client-Agenten 128a–128n, die jeweils mit einem Host-Dienst 116a–116n kommunizieren. Außerdem kann die Ausgabe einer Applikation, die am Host-Dienst 116a–116n ausgeführt wird, über z. B. den Client-Agent 128 oder den Web-Browser 162 am Client angezeigt werden.
  • In einer anderen Ausführungsform ist ein selbständiger Client-Agent aufgebaut, um dem Client 108 zu erlauben, mittels Verwendung des ersten Protokolls zu kommunizieren. Der selbständige Client-Agent kann innerhalb des Clients 108 eingebaut werden oder der selbständige Client-Agent kann alternativ vom Client 108 getrennt sein. Der selbständige Client-Agent ist z. B. ein lokaler Host-Proxy. Im allgemeinen kann der selbständige Client-Agent jede der hierin beschriebenen Funktionen mit Bezug auf den Client-Agent 128 implementieren.
  • Mit Bezug auf 1A können auf ähnliche Weise jeweils der erste Protokoll-Dienst 112 und die Host-Dienste 116a–116n an irgendeiner Computervorrichtung bereitgestellt werden, die zum Kommunizieren in der Lage ist und genug Prozessorleistung und Speicherkapazität hat, um die hierin beschriebenen Betriebe durchzuführen. Da wo die Funktionalität des ersten Protokoll-Dienstes 112 und der Host-Dienste 116a–116n in derselben Computervorrichtung wie beispielsweise einem der Host-Knoten 118a–118n wie in 1B enthalten ist, können der erste Protokoll-Dienst 112 und/oder die Host-Dienste 116a–116n als Softwareprogramm, das an einem Allzweckcomputer abläuft, und/oder als Spezialzweck-Hardware-Vorrichtung wie beispielsweise ein ASIC oder ein FPGA implementiert werden.
  • Gleich dem Client 108 können die Host-Knoten 118a–118n jeweils irgendeine oben beschriebene Computervorrichtung (z. B. ein Personalcomputer) sein, die zum Kommunizieren in der Lage ist und genug Prozessorleistung und Speicherkapazität hat, um die hierin beschriebenen Betriebe durchzuführen. Jeder der Host-Knoten 118a–118n kann mittels Verwendung einer Vielfalt an Kommunikationsprotokollen (z. B. ICA, HTTP, TCP/IP und IPX), SPX, NetBIOS, Ethernet, RS232 und direkten asynchronen Verbindungen) eine Kommunikation über die Nachrichtenkanäle 124a–124n errichten.
  • In einer Ausführungsform unterbringt jeder der Host-Dienste 116a–116n ein oder mehrere Applikationsprogramme, die für den Client 108 aus der Ferne verfügbar sind. Applikationen, die dem Client für eine Verwendung zur Verfügung gestellt werden, können als veröffentlichte Applikationen bezeichnet werden. Dasselbe Applikationsprogramm kann von einem oder irgendeiner Anzahl an Host-Diensten 116a–116n untergebracht werden. Beispiele für solche Applikationen schließen Textverarbeitung-Programme wie beispielsweise MICROSOFT WORD und Spreadsheet-Rechenprogramme wie beispielsweise MICROSOFT EXEL ein, die beide von der Microsoft Corporation aus Redmond, Washington, erhältlich sind. Andere Beispiele für Applikationsprogramme, die durch irgendeinen oder alle Host-Dienste 116a–116n untergebracht werden können, schließen Finanzmitteilungsprogramme, Kundenregistrierungsprogramme, Programme, die eine technische Unterstützungsinformation bereitstellen, Kunden-Datenbankapplikationen und Applikationsgruppen-Manager ein. Außerdem sind in einer Ausführungsform ein oder mehrere Host-Dienste 116a–116n ein Audio/Video-Streaming-Server, der dem Client 108 ein Audio- und/oder Streaming-Video bereitstellt. In einer anderen Ausführungsform schließen die Host-Dienste 116a–116n Datei-Server ein, die dem Client 108 irgendeine/alle Dateiarten zur Verfügung stellen. In einer Ausführungsform können die Host-Dienste 116a–116n mit dem Client 108 kommunizieren, indem ein Präsentationsprotokoll wie beispielsweise ein ICA von Citrix Systems, Inc. aus Ft. Lauderdale, Fl., oder ein RDP der Microsoft Corporation aus Redmond, Washington, verwendet wird.
  • In einer weiteren Ausführungsform ist der Host-Knoten 118 ein Glied einer Serverfarm 169 oder eines Servernetzes, die eine logische Gruppe aus einem oder mehreren Servern darstellen, die wie eine einzige Einheit verwaltet werden. In einer Ausführungsform schließt eine Serverfarm 19 mehrere Host-Knoten 118a–118n (im allgemeinen 118) ein. Obwohl die in 1B gezeigte Ausführungsform drei Host-Knoten 118a–118n hat, kann die Serverfarm 169 irgendeine Anzahl an Host-Knoten 118 oder Servern haben. In anderen Ausführungsformen ist die Serverfarm 169 ein geschütztes Netz wie beispielsweise das gemeinsame Intranet, Virtual Private Network (VPN) oder ein sicheres Extranet, das für nicht berechtigte Personen nicht zugreifbar ist. Zusätzlich können die Server, die die Serverfarm 169 bilden, über irgendeines der oben beschriebenen Netze (z. B. WAN, LAN) mittels Verwendung irgendeines erörterten Protokolls kommunizieren.
  • Die Ticket-Autorität 136, die in der in 1A gezeigten Ausführungsform ein Teil der Serverfarm 169 ist, gibt ein oder mehrere Tickets aus, um den Client 108 zu authentifizieren. Vor allem ermöglicht die Ticket-Autorität 136 die Authentifizierung des Clients 108 über einen Nachrichtenkanal (d. h. den Client-Web-Server-Nachrichtenkanal 140) auf der Grundlage von Authentifikationslegitimierungen. Die Ticket-Autorität 136 erlaubt dem Client 108 weiterhin, für einen anderen Nachrichtenkanal (d. h. den ersten Client-Protokoll-Dienst-Nachrichtenkanal 135) zu authentifizieren, ohne dass der Client 108 wiederholt die Authentifikationslegitimierung auf dem anderen Nachrichtenkanal bereitstellen muss.
  • In einer Ausführungsform ist die Ticket-Autorität 136 eine selbständige Netzkomponente. In anderen Ausführungsformen ist eine modulare Ticket-Autorität 136 ein Softwaremodul, das an einem oder mehreren Host-Knoten 118 liegt. Zum Beispiel kann es, wie in 1B gezeigt, eine Ticket-Autorität 136 für jeden der Host-Knoten 118a–118n geben. In dieser Ausführungsform kann der Web-Server 120 über den Agent-Server-Nachrichtenkanal 155 mit der Ticket-Autorität 136 und/oder dem Host-Knoten 118 kommunizieren. In einer anderen Ausführungsform kann die Ticket-Autorität 136 an einem Zwischenknoten residieren, der getrennt von irgendeinem der Host-Knoten 118a–118n liegt.
  • In einer Ausführungsform erzeugt die Ticket-Autorität 136 ein erstes Ticket und ein zweites Ticket. In einigen Ausführungsformen sind die Tickets beide Ad-hoc-Bildungen. In weiteren Ausführungsformen werden die Tickets mittels Verwendung eines Schlüssel-Zufallszahlgenerators erzeugt, dem auf geeignete Weise eine Zufälligkeit eingeimpft wurde. Das erste Ticket wird an den Client 108 gesendet und wird verwendet, um eine erste Kommunikationssitzung zwsichen dem Client 108 und dem ersten Protokoll-Dienst 112 zu errichten. Das zweite Ticket wird an den ersten Protokoll-Dienst 112 übertragen und wird verwendet, um eine zweite Kommunikationssitzung zwischen dem ersten Protokoll-Dienst 112 und dem Host-Knoten 118 zu errichten.
  • In einer Ausführungsform stellt der Web-Server 120 dem Client 108 Webseiten zu. Der Web-Server 120 kann irgendein Personalcomputer (z. B. Macintosh-Computer, ein Personalcomputer, der einen Intel-Mikroprozessor hat und von der Intel Corporation von Santa Clara, Kalifornien, entwickelt wird, ein Personalcomputer, der einen AMD-Mikroprozessor hat, der von Advanced Micro Devices, Inc. aus Sunnyvale, Kalifornien, usw. entwickelt wird), ein Endgerät, dem Windows zugrundeliegt, ein Netzcomputer, eine drahtlose Vorrichtung (z. B. Mobiltelefon), eine Informationsvorrichtung, ein RISC-Leistungs-PC, eine X-Vorrichtung, eine Workstation, ein Minicomputer, ein Main-Frame-Computer, ein Personal-Digital-Assistant oder eine andere Kommunikationsvorrichtung sein, die in der Lage ist, den sicheren Client-Web-Server-Nachrichtenkanal 140 mit dem Client 108 zu errichten.
  • In einer anderen Ausführungsform stellt der Web-Server 120 dem Client 108 ein Firmen-Portal zur Verfügung, auf das als Enterprise Information Portal Bezug genommen wird. Unternehmen-Portale sind Webseiten einer Gesellschaft, die für Anwender Applikationen, Daten und Inhalt sammeln, personalisieren und sie damit bedienen, während sie das Verwaltungs-Werkzeug zum wirkungsvollen Organisieren und Verwenden anbieten. In einigen Ausführungsformen stellt der Web-Server 120 dem Client 108 ein Web-Portal oder Internet-Portal zur Verfügung. Ein Web-Portal gleicht einem Firmen-Portal, schließt jedoch für gewöhnlich keine Geschäfts-spezifische Information ein.
  • In einer Ausführungsform benutzt ein Anwender des Clients 108 den Web-Browser 162, um den Anwender für den Web-Server 120 zu authentifizieren. In einer Ausführungsform sendet der Client 108 Anwender-Legitimierungen wie beispielsweise eine Login- und Password-Information an den Web-Server 120. Der Web-Server 120 prüft, dass der Anwender Zugriff aud das Servernetz 169 hat.
  • In einer weiteren Ausführungsform verwendet der Web-Browser 162 das SSL, um den sicheren Client-Web-Server-Nachrichtenkanal 140 zu errichten. Der Web-Browser 162 kann den Web-Server 120 alternativ mittels Verwendung anderer Sicherheitsprotokolle wie beispielsweise, ohne darauf eingeschränkt zu sein, das von Terisa Systems of Los Altos, CA entwickelte Secure Hypertext Transfer Protocol (SHTTP), HTTP über SSL (HTTPS), die von der Microsoft Corporation aus Redmond, Washington, entwickelte Private Communication Technology (PCT) und den von der Internet Engineering Task Force (IETF) verbreiteten Transport Security Level-(TLS)-Standard über den Client-Web-Server-Nachrichtenkanal 140 mit dem Web-Server 120 verbinden. In einer Ausführungsform sendet der Web-Server 120 ein wie oben beschriebenes Web-Portal oder Unternehmens-Portal beim Validieren des Anwenders am Client 108, um zu ermöglichen, dass der Client 108 aus der Ferne eine Applikation verlangen kann, oder dass dem Client z. B. aus der Ferne ein Server-Desktop gezeigt wird.
  • Der Client-Web-Server-Nachrichtenkanal 140 ist irgendein sicherer Nachrichtenkanal. In einigen Ausführungsformen werden Kommunikationen über den Kanal 140 verschlüsselt. In bestimmten anderen Ausführungsformen können der Client 108 und der Web-Server 120 mittels Verwendung von Secure Socket Layer (SSL) vom Hypertext Transfer Protocol (HTTPS) kommunizieren. Alternativ dazu können der Client 108 und der Web-Server andere Verschlüsselungstechniken wie beispielsweise symmetrische Verschlüsselungstechniken verwenden, um Kommunikationen zu schützen.
  • Weiterhin kann der erste Client-Protokoll-Dienst-Nachrichtenkanal 135 in einer Ausführungsform beispielsweise mittels Verwendung eines Präsentationsprotokolls wie das von Citrix Systems, Inc. aus Fort Lauderdale, Florida, hergestellte Independent Computing Architecture-(ICA)-Protokoll errichtet werden. ICA ist ein Allzweck-Präsentationsdienste-Protokoll, das aufgebaut ist, um mittels Verwendung von Industrie-Standard-Transport-Protokollen wie beispielsweise ISDN, einem Datenübertragungs-Relais und asynchronen Übertragungsmodus (ATM) über Industrie-Standard-Netz-Protokolle wie beispielsweise TCP/IP, IPX/SPX, NetBEUL zu laufen. Das ICA-Protokoll sorgt für virtuelle Kanäle, die Sitzungs-orientierte Übertragungsverbindungen darstellen, die von einem Verarbeitungsschichtcode verwendet werden können, um Befehle für den Austausch von Daten auszugeben. In anderen Ausführungsformen kann der erste Client-Protokoll-Dienst-Nachrichtenkanal 135 mittels Verwendung des Thin X-Protokolls oder des Remote Display Protocol (RDP) errichtet werden, die von der Microsoft Corporation aus Redmond, Washington, entwickelt wurden.
  • Obwohl die Kommunikationssitzung so beschrieben wird, als würde sie eine erste Kommunikationssitzung zwischen dem Client 108 und dem ersten Protokoll-Dienst 112 und eine zweite Kommunikationssitzung zwischen dem ersten Protokoll-Dienst 112 und dem Host-Knoten 118 errichten, kann sie als eine einzige logische Kommunikationssitzung zwischen dem Client 108 und dem Host-Dienst 116 betrachtet werden.
  • Immer noch auf die darstellenden Ausführungsformen der 1A und 1B Bezug nehmend, ist der Client 108 aufgebaut, um mittels Verwendung eines ersten Protokolls über das Netz 104 eine Verbindung 135 zwischen dem Client 108 und einem ersten Protokoll-Dienst 112 zu errichten. Für seinen Teil ist der erste Protokoll-Dienst 11w aufgebaut, die Verbindung 135 anzunehmen. Der Client 108 und der erste Protokoll-Dienst 112 können daher mittels Verwendung des mit Bezug auf die 2A–2B und 3 unten beschriebenen ersten Protokolls miteinander kommunizieren.
  • Wie ebenfalls weiter unten beschrieben, ist der erste Protokoll-Dienst 112 in einer Ausführungsform seinerseits aufgebaut, um mittels Verwendung des ersten Protokolls zu kommunizieren. Der erste Protokoll-Dienst 112 ist aufgebaut, um jeweils eine Verbindung 124a–124n zwischen dem ersten Protokoll-Dienst 112 und dem Host-Dienst 116a–116n zu errichten. Der erste Protokoll-Dienst 112 kann z. B. eine Verbindung 124a zwischen dem ersten Protokoll-Dienst 112 und einem Host-Dienst 116a und eine Verbindung 124b zwischen dem ersten Protokoll-Dienst 112 und einem anderen Host-Dienst 116b errichten. In einer Ausführungsform errichtet der erste Protokoll-Dienst 108 auf unabhängige Weise diese Verbindungen 124a–124n (d. h. der erste Protokoll-Dienst 112 errichtet eine Verbindung auf einmal). In einer anderen Ausführungsform errichtet der erste Protokoll- Dienst 112 gleichzeitig zwei oder mehrere dieser Verbindungen 124a–124n.
  • In noch einer anderen Ausführungsform kann der erste Protokoll-Dienst 112 gleichzeitig mehrere Verbindung 124a–124n errichten und aufrechterhalten. Der erste Protokoll-Dienst 112 ist aufgebaut, um zwei oder mehr Verbindungen 124a–124n bereitzustellen, ohne die Verbindung 135 mit dem Client 108 zu unterbrechen. Der erste Protokoll-Dienst 112 kann z. B. aufgebaut sein, um die Verbindung 124a zwischen dem ersten Protokoll-Dienst 112 und dem Host-Dienst 116a zu errichten, wenn ein Anwender des Clients 108 die Ausführung eines ersten Applikationsprogramms verlangt, das am Host-Dienst 116a residiert. Wenn der Anwender die Durchführung des ersten Applikationsprogramms beendet und mit der Durchführung eines zweiten Applikationsprogramms beginnt, das z. B. am Host-Dienst 116b residiert, ist der erste Protokoll-Dienst 112 in einer Ausführungsform z. B. aufgebaut, um die Verbindung 124a zu unterbrechen und die Verbindung 124b zwischen dem ersten Protokoll-Dienst 112 und dem Host-Dienst 116b zu errichten, ohne die Verbindung 135 zwischen dem ersten Protokoll-Dienst 112 und dem Client 108 zu unterbrechen.
  • Der erste Protokoll-Dienst 112 und die Host-Dienste 116a–116n können jeweils über Verbindungen 124a–124n kommunizieren, indem sie irgendeines einer Vielfalt an sekundären Protokollen einschließlich, ohne darauf beschränkt zu sein, HTTP, FTP, Oscar, Telnet, das ICA-Fernanzeige-Protokoll von Citrix Systems, Inc. aus Fort Lauderdale, Florida und/oder das RDP-Fernanzeige-Protokoll der Microsoft Corporation aus Redmond, Washington, verwenden. Der erste Protokoll-Dienst 112 und der Host-Dienst 116a können z. B. mittels Verwendung des ICA-Fernanzeige-Protokolls über die Verbindung 124a kommunizieren, während der erste Protokoll-Dienst 112 und der Host-Dienst 116b mittels Verwendung des RDP-Fernanzeige-Protokolls über die Verbindung 124b kommunizieren können.
  • In einer Ausführungsform schließt das sekundäre Protokoll, das zum Kommunizieren zwischen dem ersten Protokoll-Dienst 112 und einem Host-Dienst 116 verwendet wird, beispielsweise das ICA-Fernanzeige-Protokoll, mehrere virtuelle Kanäle ein. Ein virtueller Kanal ist eine Sitzungs-orientierte Übertragungsverbindung, die vom Verarbeitungsschichtcode verwendet wird, um Befehle zum Austausch von Daten auszugeben. Zum Beispiel können die mehreren virtuellen Kanäle jeweils mehrere Protokollpakete einschließen, die die Funktionalität am Fern-Client 108 ermöglichen. In einer Ausführungsform schließt einer der mehreren virtuellen Kanäle Protokollpakete zum Übertragen graphischer Bildschirmbefehle von einem Host-Dienst 116 mittels des ersten Protokoll-Dienstes 112 an den Client 108 ein, um zu veranlassen, dass der Client 108 ein graphische Anwender-Schnittstelle (GUI) anzeigt. In einer anderen Ausführungsform schließt einer der mehreren virtuellen Kanäle Protokollpakete ein, um mittels des ersten Protokoll-Dienstes 112 Druckerbefehle von einem Host-Dienst 116 an den Client 108 zu übertragen, um zu veranlassen, dass ein Dokument am Client 108 ausgedruckt wird.
  • In einer anderen Ausführungsform ist das erste Protokoll ein Tunnel-Protokoll. Der erste Protokoll-Dienst 112 kapselt mehrere sekundäre Protokolle ein, die jeweils für die Kommunikation zwischen einem der Host-Dienste 116a–116n und dem ersten Protokoll-Dienst 112 innerhalb des ersten Protokolls verwendet werden. Somit kommunizieren die Host-Dienste 116a–116n und der erste Protokoll-Dienst 112 über mehrere sekundäre Protokolle mit dem Client 108. In einer Ausführungsform ist das erste Protokoll z. B. ein Applikationsebene-Transport-Protokoll, das in der Lage ist, mehrere sekundäre Protokolle über eine TCP/IP-Verbindung zu tunneln.
  • Auf 2A Bezug nehmend, nehmen Kommunikationen zwischen dem Client 108 und dem ersten Protokoll-Dienst 112 über die Verbindung 135 die Form mehrerer sekundärer Protokolle 200a–200n (z. B. HTTP, FTP, Oscar, Telnet, ICA und/oder RDF) ein, die in einem ersten Protokoll 204 eingeschlossen sind. Dies wird durch die Stellung der sekundären Protokolle 200a–200n im ersten Protokoll 204 angezeigt. Wenn nicht nach einer sicheren Kommunikation verlangt wird, kann das erste Protokoll 204, wie in 2A dargestellt, über eine nicht gesicherte TCP/IP-Verbindung 208 kommuniziert werden.
  • Nimmt man jetzt auf 2B Bezug, wird, wenn die sichere Kommunikation verwendet wird, das erste Protokoll 204 über eine verschlüsselte Verbindung wie beispielsweise eine TCP/IP-Verbindung 212 mitgeteilt, die durch Verwendung eines Sicherheitsprotokolls 216 wie beispielsweise das Secure Socket Layer (SSL) gesichert wird. SSL ist ein Sicherheitsprotokoll, das als erstes von der Netscape Communication Corporation aus Mountain View, Kalifornien, entwickelt wurde und jetzt ein Standard ist, der von der Internet Engineering Task Force (IETF) als Transport Layer Security(TLS)-Protokoll verbreitet und in IETF RFC-2246 beschrieben wird.
  • Solchermaßen wird die Mehrzahl der sekundären Protokolle 200a–200n im ersten Protokoll 204 mit (2B) einem Sicherheitsprotokoll 216 oder ohne ein Sicherheitsprotokoll 216 (2A) über die Verbindung 135 kommuniziert. Die sekundären Protokolle, die verwendet werden können, um über die Verbindungen 124a–124n zu kommunizieren, umfassen, ohne darauf eingeschränkt zu sein, HTTP, FTP, Oscar, Telnet, ICA und RDP. Außerdem schließt in einer Ausführungsform mindestens eines der sekundären Protokolle, wie oben beschrieben, mehrere virtuelle Kanäle ein, von denen jeder mehrere Protokollpakete einschließen kann, die die Funktionalität am entfernten Client 108 erlauben. In einer Ausführungsform ist z. B. ein Host-Dienst 116a ein Web-Server, der mittels Verwendung des HTTP-Protokolls über die Verbindung 124a mit dem ersten Protokoll-Dienst 112 kommuniziert, und ist ein anderer Host-Dienst 116b ein Applikations-Server, der mittels Verwendung des ICA-Protokolls über die Verbindung 124b mit dem ersten Protokoll-Dienst 112 kommuniziert. Der Host-Dienst 116 erzeugt sowohl Protokollpakete zum Übertragen graphischer Bildschirmbefehle an den Client 108, um zu veranlassen, dass der Client 108 eine graphische Anwender-Schnittstelle anzeigt, als auch Protokollpakete zum Übertragen von Druckerbefehlen an den Client 108, um zu veranlassen, dass ein Dokument am Client 108 ausgedruckt wird.
  • Ein anderer Aspekt der vorliegenden Erfindung liegt darin, dass das Verfahren und die Systeme, die hierin beschrieben sind, die Anzahl reduzieren, mit der Netzverbindungen geöffnet und geschlossen werden. In einer Ausführungsform erlaubt das erste Protokoll 204, dass die darin getunnelten sekundären Protokoll-Verbindungen 200a–200n wie beispielsweise eine HTTP-Verbindung 200n jeweils geöffnet und geschlossen werden, ohne auch die Transportverbindung zu benötigen, über die das erste Protokoll 204 kommuniziert wird (z. B. die TCP-Verbindung 208 und/oder 212), wobei die sichere Protokoll-Verbindung 216 oder die erste Protokoll-Verbindung 204 selbst auf ähnliche Weise wiederholt geöffnet und/oder geschlossen werden. Ohne das Einschließen des ersten Protokolls 204, kann das sekundäre Protokoll 200a–200n Netzverbindungen wie beispielsweise TCP-Verbindungen häufig öffnen und schließen. Dies würde das System bedeutend verzögern und einen Verwaltungsaufwand daran hinzufügen. Diese Verzögerungen und der Verwaltungsaufwand würden durch die Verwendung eines sicheren Einkapselungsprotokolls 214 wie das SSL weiter erhöht werden, das beim Errichten der Netzverbindungen einen bedeutenden Verwaltungsaufwand mit sich bringt. Indem das sekundäre Protokoll 200a–200n im ersten Protokoll 204 eingeschlossen und die Verbindung der Transportverbindung (208, 212) aufrechterhalten werden, brauchen die sekundären Protokolle 200a–200n als Teil der Nutzlast des ersten Protokolls 204 nicht das häufige und teure Öffnen und Schließen der Netzverbindung 135 durchzuführen. Da die sekundären Protokolle 200a–200n im ersten Protokoll 204 mit einem Sicherheitsprotokoll 216 kommuniziert werden, müssen darüber hinaus die sekundären Protokolle 200a–200n gesicherte Verbindungen wie beispielsweise mit SSL nicht öffnen und schließen. Die Transportverbindung (208, 212) errichtet und erhält aufrecht die Netzverbindung 135, so dass die eingeschlossenen zweiten Protokolle 200a–200n kommuniziert werden können, ohne wiederholt die gesicherte oder ungesicherte Netzverbindung zu öffnen und zu schließen. Dies erhöht bedeutend die Betriebsgeschwindigkeit beim Kommunizieren der sekundären Protokolle 200a–200n.
  • Wie oben beschrieben, führen die sekundären Protokolle 200a –200n Protokollpakete mit sich, die Applikationen betreffen, die diese Protokolle als HTTP, FTP, Oscar, Telnet, RDA oder ICA verwenden. Die sekundären Protokollpakete 304a–304n transpor tieren Daten, die die Applikationsfunktionalität betreffen, die zwischen dem Client 108 und dem Host-Dienst 116a–116n abgewickelt wird. Zum Beispiel kann ein Anwender am Client 108 mit einer Webseite in Wechselwirkung treten, die von einem Host-Dienst 116a–116n bereitgestellt wird. Bei Transaktionen zwischen dem Client 108 und dem Host-Dienst 116a–116n kann das im ersten Protokoll 204 eingeschlossene sekundäre Protokoll 200a–200n Http-Protokollpakete haben, die das Anzeigen der Webseite und das Empfangen irgendeiner Anwender-Wechselwirkung für das Kommunizieren mit dem Host-Dienst 116a–116n betreffen. Da die Transportverbindung (208, 212) nicht durch die sekundären Protokolle 200a–200n aufrechterhalten werden, brauchen die sekundären Protokolle 200a–200n nicht irgendwelche Verbindungsunterbrechungen auf Netzebene abzuwickeln. Somit können die sekundären Protokolle 200a–200n in ihren Nutzlasten nicht irgendeine Verbindungsunterbrechungsinformation auf Netzebene bereitstellen. Im obigen Beispiel würden die an den Client 108 übertragenen Http-betreffenden sekundären Protokollpakete 304a–304n des sekundären Protokolls 200a–200n keine Mitteilung bereitstellen, dass eine Netzunterbrechung auftrat, z. B. eine Fehlernachricht auf einer Webseite. Daher werden dem Anwender am Client 108 mittels des sekundären Protokolls 200a–200n keine Verbindungsunterbrechungen auf Netzebene gemeldet. Dies verbirgt auf wirkungsvolle Weise Netzverbindungsunterbrechungen vor dem Anwender während der Verwendung der die sekundären Protokolle 200a–200n betreffenden Applikationen.
  • Auf 3 Bezug nehmend, schließt ein Beispielverfahren 300, das vom ersten Protokoll-Dienst 112 und dem Client-Agent 128 des Clients 108 verwendet wird, die mehreren sekundären Protokolle 200 (z. B. HTTP, FTP, Oscar, Telnet, ICA und/oder RDP) innerhalb des ersten Protokolls 204 für die Kommunikation über die Verbindung 135 ein. Wie unten beschrieben, komprimiert und/oder verschlüsselt das exemplarische Verfahren 300, das vom ersten Protokoll-Dienst 112 und vom Client-Agent 128 des Clients 108 verwendet wird, wahlweise die Kommunikationen auf der Ebene des ersten Protokolls vor den Kommunikationen über die Verbindung 135. Vom Standpunkt des ersten Protokoll-Dienstes 112 aus, werden sekundäre Protokollpakete 304a–304n über die Verbindungen 124a–124n am ersten Protokoll-Dienst empfangen. Zum Beispiel werden die beiden sekundären Protokollpakete 304a und 304b vom ersten Protokoll-Dienst 112 empfangen. Ein, zwei oder irgendeine Anzahl an sekundären Protokollpaketen 304a–304n können empfangen werden. In einer Ausführungsform werden die sekundären Protokollpakete 304a–304n durch die Host-Dienste 116 über die Verbindung 124 an den ersten Protokoll-Dienst 112 übertragen. Die sekundären Protokollpakete 304a–304n schließen eine Kopfzeile 308 und ein Datenpaket 312 ein, auf das auch als eine Datennutzlast Bezug genommen wird.
  • Im Anschluss an den Empfang der sekundären Protokollpakete 304a–304n schließt der erste Protokoll-Dienst 112 ein oder mehrere sekundäre Protokollpakete 304 in einem ersten Protokollpaket 316. In einer Ausführungsform erzeugt der erste Protokoll-Dienst 112 eine erste Protokollpaket-Kopfzeile 320 und schießt in der Datennutzlast 324 des ersten Protokollpakets 316 ein oder mehrere sekundäre Protokollpakete 304a–304n beispielsweise die beiden sekundären Protokollpakete 304a und 304b ein. In einer anderen Ausführungsform wird nur ein sekundäres Protokollpaket 304a in jedem ersten Protokollpaket 316 eingeschlossen.
  • In einer Ausführungsform werden die ersten Protokoll-Dienste 316 daraufhin über die Verbindung 135 wie beispielsweise über die mit Bezug auf die 2A beschriebene Verbindung 208 an den Client-Agent 128 des Clients 108 übertragen. Alternativ ist der erste Protokoll-Dienst 112 in einer anderen Ausführungsform weiterhin aufgebaut, um vor der Übertragung irgendwelcher ersten Protokollpakete 316 Kommunikationen auf der Ebene des ersten Protokolls 204 zu verschlüsseln. In einer solchen Ausführungsform werden die ersten Protokollpakete 316 verschlüsselt, indem z. B. das mit Bezug auf 2B beschriebene SSL-Protokoll verwendet wird. Als Ergebnis wird ein sicheres Paket 328, das als Datennutzlast 336 eine Kopfzeile 332 und ein verschlüsseltes erstes Protokollpaket 316' einschließt, erzeugt. Das sichere Paket 328 kann dann über die Verbindung 135, z. B. über die in 2B dargestellte sichere TCP/IP-Verbindung 212, an den Client-Agent 128 des Clients 108 übertragen werden.
  • In einer anderen Ausführungsform ist der erste Protokoll-Dienst 112 weiterhin aufgebaut, um vor der Übertragung irgendwelcher ersten Protokollpakete 316 Kommunikationen auf der Ebene des ersten Protokolls 204 zu komprimieren. In einer Ausführungsform komprimiert der erste Protokoll-Dienst 112 vor dem Verschlüsseln des ersten Protokollpakets 316 mittels Verwendung einer Standard-Komprimierungstechnik das erste Protokollpaket 316. Somit wird die Wirksamkeit des Systems 100 verbessert.
  • Nimmt man wiederum auf die 1A–1B Bezug, stellt das System 100 der vorliegenden Erfindung in einer Ausführungsform dem entfernten Client 108 eine persistente Verbindung mit einem Host-Dienst 116 wie beispielsweise dem Host-Dienst 116a zur Verfügung. Wenn der Client 108 z. B. eine Verbindung 135 zwischen dem Client 108 und dem ersten Protokoll-Dienst 112 errichtet und der erste Protokoll-Dienst 112 eine Verbindung 124a zwischen dem ersten Protokoll-Dienst 112 und dem Host-Dienst 116a errichtet, sind entweder der Client-Agent 128, der erste Protokoll-Dienst 112 oder beides aufgebaut, eine Warteschlange der ersten Protokoll-Datenpakete zu unterhalten, die zuletzt über die Verbindung 135 übertragen wurden. Zum Beispiel können die in eine Warteschlange gesetzten Datenpakete sowohl vor als auch nach einem Ausfall der Verbindung 135 durch den Client-Agent 128 und/oder den ersten Protokoll-Dienst 112 aufrechterhalten werden. Bei einem Ausfall der Verbindung 135 sind der erste Protokoll-Dienst 112 und gleichermaßen der Host-Dienst außerdem aufgebaut, um die Verbindung 124a aufrechtzuerhalten.
  • Im Anschluss an einen Ausfall der Verbindung 135, errichtet der Client 108 eine neue Verbindung 135 mit dem ersten Protokoll-Dienst 112, ohne irgendwelche Daten zu verlieren. Genauer: Da die Verbindung 124a bei einem Ausfall der Verbindung 135 aufrechterhalten wird, kann eine neu errichtete Verbindung 135 mit der aufrechterhaltenen Verbindung 124a verbunden werden. Da die zuletzt übertragenen ersten Protokoll-Datenpakete in Warteschlangen gesetzt werden, können sie weiterhin über die neu errichtete Verbindung 135 wieder vom Client 108 an den ersten Protokoll-Dienst 112 und/oder vom ersten Protokoll-Dienst 112 an den Client 108 übertragen werden. Somit ist die Kommunikationssitzung zwischen dem Host-Dienst 116a und dem Client 108 mittels des ersten Protokoll-Dienstes 112 beständig und verläuft ohne Datenverlust.
  • In einer Ausführungsform numerieren der Client-Agent 128 des Clients 108 und/oder der erste Protokoll-Dienst 112 die Datenpakete, die sie über die Verbindung 135 senden. Zum Beispiel numerieren der Client-Agent 128 und der erste Protokoll-Dienst 112 jeweils unabhängig ihre eigenen übertragenen Datenpakete, und zwar ohne Rücksicht darauf, wie der andere seine Datenpakete numeriert. Außerdem kann die Numerierung der Datenpakete absolut, ohne Neu-Numerierung der Datenpakete sein, d. h. das vom Client 128 und/oder ersten Protokoll-Dienst 112 übertragene erste Datenpaket 112 kann mit Nr. 1 numeriert werden, wobei jedes über die Verbindung 135 vom Client-Agent 128 und/oder vom ersten Protokoll-Dienst 112 jeweils übertragene Datenpaket danach fortlaufend numeriert wird.
  • In einer solchen Ausführungsform informiert der Client-Agent 128 und/oder der erste Protokoll-Dienst den jeweils anderen im Anschluss an eine unterbrochene und wiederhergestellte Verbindung 135 über das nächste Datenpaket, das er benötigt. Wenn der Client-Agent 128 z. B. die Datenpakete Nrn. 1–10 vor der Unterbrechung der Verbindung 135 empfangen hat, teilt der Client-Agent 128 dem erste Protokoll-Dienst 112 beim Wiederherstellen der Verbindung 135 mit, dass er jetzt das Datenpaket Nr. 11 benötigt. Ebenso kann auch der erste Protokoll-Dienst 112 arbeiten. In einer anderen solchen Ausführungsform informiert der Client-Agent 128 und/oder der erste Protokoll-Dienst 112 den anderen über das zuletzt empfangene Datenpaket. Wenn der Client-Agent 128 z. B. vor der Unterbrechung der Verbindung 135 Datenpakete Nrn. 1–10 empfangen hat, teilt der Client-Agent 128 dem ersten Protokoll-Dienst 112 beim Wiederherstellen der Verbindung mit, dass er zuletzt das Datenpaket Nr. 10 empfangen hat. Wiederum kann auch der erste Protokoll-Dienst 112 auf diese Weise arbeiten. In noch einer anderen teilt der Client-Agent 128 und/oder der erste Protokoll-Dienst 112 dem jeweils anderen beim Wiederherstellen der Verbindung 135 sowohl das zuletzt empfangene Datenpaket als auch das nächste Datenpaket mit, das er benötigt.
  • In diesen Ausführungsformen können der Client-Agent 128 und/oder der erste Protokoll-Dienst 112 beim Wiederherstellen der Verbindung 135 die nicht vom anderen empfangenen gepufferten Datenpakete neuerlich übertragen, womit die Kommunikationssitzung zwischen einem Host-Dienst 116 und dem Client 108 mittels des ersten Protokoll-Dienstes 112 erlaubt wird, um ohne Datenverlust fortzufahren. Beim Wiederherstellen der Verbindung 135 kann der Client-Agent 128 und/oder der erste Protokoll-Dienst 112 aus jedem ihrer jeweiligen Puffer außerdem die gepufferten Datenpakete ausräumen, von denen bekannt ist, dass sie vom anderen empfangen wurden.
  • Obwohl das Puffern der Daten für eine persistente Verbindung allgemein im Sinne eines einzigen Protokoll-Dienstes 112 erörtert wird, lassen sich die Datenpufferungs- und Wieder-Verbindungstechniken auf eine ähnliche Art und Weise auch an eine Kommunikationssitzung des Clients mit einem Host-Dienst 116 anlegen, der mehrere erste Protokoll-Dienste 112 durchläuft. Einer oder mehrere des zusätzlichen ersten Protokoll-Dienstes 112 können den gesamten Datenverkehr oder einen Teil davon zwischen dem Client 108 und dem Host-Dienst 116 Puffern. In einer anderen Ausführungsform kann ein Protokoll-Dienst 112, der einen der "Hops" zwischen einem Client und dem Host-Dienst 116 verwaltet, die Daten Puffern, die an diesen "Hop" gesandt und davon empfangen werden. Somit können ein oder mehrere erste Protokoll-Dienste 112 verwendet werden, um Datenpakete beim Wiederherstellen einer unterbrochenen Verbindung zwischen dem Client 108 und dem Host-Dienst 116 neuerlich zu senden.
  • Indem dem Client 108 eine zuverlässige und persistente Verbindung mit einem Host-Dienst 116a–116n zur Verfügung gestellt wird, vermeidet die vorliegende Erfindung das Verfahren zum Öffnen einer neuen Anwender-Sitzung mit dem Host-Dienst 116a–116n mittels der Aufrechterhaltung der Anwender-Sitzung durch Netzverbindungsunterbrechungen. Für jede Anwender-Sitzung mit einem Host-Dienst 116a–116n können der Client 108 und der Host-Dienst 116a–116n den/die Sitzungs-spezifischen Zusammenhang und Caches sowie andere Applikations-spezifische Mechanismen, die diesen Fall der Anwender-Sitzung betreffen, aufrechterhalten.
  • Für jede wiederhergestellte Sitzung eines neuen Anwenders müssen diese Sitzungs-spezifischen Zusammenhänge und Caches wieder besetzt oder wieder errichtet werden, um die neue Sitzung widerzuspiegeln. Zum Beispiel kann ein Anwender am Client 108 eine Http-Sitzung mit einem Host-Dienst 116a–116n haben. Der Host-Dienst 116a–116n kann den Zusammenhang aufbewahren, der für das Bereitstellen dieses Falls der Http-Sitzung mit dem Client 108 spezifisch ist. Der Zusammenhang kann im Speicher des Servers, in Dateien des Servers, in einer Datenbank oder anderen Komponente gespeicher werden, die das Bereitstellen der Funktionalität des Host-Dienstes 116a–116n betrifft. Der Client 108 kann auch einen lokalen Zusammenhang haben, der für den Fall der Http-Sitzung spezifisch ist, z. B. ein Mechanismus zum Bewahren einer Spur für eine außergewöhnliche Anfrage an den Host-Dienst 116a–116. Dieser Zusammenhang kann im Speicher des Clients 108, in Dateien am Client 108 oder in einer anderen Softwarekomponente gespeichert werden, die eine Schnittstelle mit dem Client 108 bildet. Wenn die Verbindung zwischen dem Client 108 und dem Host-Dienst 116a–116n nicht beständig ist, dann muss eine neue Anwender-Sitzung mit einem für die neue Sitzung spezifischen Zusammenhang am Host-Dienst 116a–116n und am Client 108 errichtet werden. Die vorliegende Erfindung hält die Sitzung so, dass eine neue Sitzung und daher ein neuer spezifischer Sitzungszusammenhang nicht wiederhergestellt werden muss.
  • Die vorliegende Erfindung hält die Anwender-Sitzung während Verbindungsunterbrechungen auf Netzebene und ohne Mitteilung an den Anwender des Clients, dass die Sitzung unterbrochen wurde, aufrecht. In Ausführung dieses Aspekts der Erfindung errichtet der erste Protokoll-Dienst 112 eine erste Verbindung mit einem Client 108 und eine zweite Verbindung mit einem Host-Dienst 116a–116n und hält sie aufrecht. Über die erste Verbindung und die zweite Verbindung wird eine Sitzung zwischen dem Client 108 und dem Host-Dienst 116a–116n errichtet. Der erste Protokoll-Dienst 112 kann irgendeine Sitzungs-betreffende Information wie beispielsweise Authentifikationslegitimierung und den Client-(108)- und Host-Dienst-(116a–116n)-Zusammenhang für die errichtete Sitzung speichern und aufrechterhalten. Ein Anwender am Client 108 wird die vom Host-Dienst 116a–116n bereitgestellte Funktionalität mittels der errichteten Sitzung ausüben. Somit werden die betreffenden sekundären Protokollpaket 304a–304n Daten enthalten, die die Transaktion dieser Funktionalität betreffen. Diese sekundären Protokollpakete 304a–304n als Teil des sekundären Protokolls 200a–200n werden in einem ersten Protokoll 204 eingeschlossen und kommuniziert. Beim Erfassen einer Unterbrechung entweder in der ersten Verbindung oder der zweiten Verbindung kann der erste Protokoll-Dienst 112 die unterbrochene Verbindung widerherstellen, während die andere Verbindung aufrechterhalten wird, die nicht unterbrochen wurde. Die Netzverbindungsunterbrechungen können eine Unterbrechung der Sitzung zwischen dem Client 108 und dem Host-Dienst 116a–116n bewirken. Da jedoch der Transportmechanismus nicht von den sekundären Protokollen 200a–200n bewahrt wird, kann die Sitzung wiederhergestellt werden, nachdem die Netzverbindung neu errichtet wurde, ohne dass dem Anwender am Client 108 mitgeteilt werden muss, dass die Sitzung unterbrochen wurde. Das sekundäre Protokoll 200a–200n braucht keine irgendeine Unterbrechung betreffende Information zu enthalten, die sie an den Client 108 senden muss. Solchermaßen wird die Unterbrechung der von der Netzverbindungsunterbrechung verursachten Sitzung aufgrund der Einkapselung des ersten Protokolls 204 wirkungsvoll verborgen.
  • Der erste Protokoll-Dienst 112, der die Sitzungs-betreffende Information aufrechterhält, kann die Sitzung zwischen dem Client 108 und dem Host-Dienst 116a–116n widerherstellen. Wenn z. B. die erste Verbindung zwischen dem Client 108 und dem ersten Protokoll-Dienst 116 unterbrochen wird, kann der erste Protokoll-Dienst 112 die Sitzung des Clients 108 zwischen dem ersten Protokoll-Dienst 11 und dem Host-Dienst 116a–116n aktiv oder offen halten. Nachdem die erste Verbindung wiederhergestellt ist, kann der erste Protokoll-Dienst 112 die Sitzung des Clients 108 mit der aufrechterhaltenen Sitzung zwischen dem ersten Protokoll-Dienst 112 und dem Host-Dienst 116 verbinden. Die erste Protokoll-Dienst 112 kann dem Client 108 irgendwelche Daten zusenden, die vor der Unterbrechung in der ersten Verbindung in eine Warteschlange gesetzt wurden. Somit wird der Client 108 dieselbe Sitzung vor der Unterbrechung benutzen, und der Host-Dienst 116a–116n und der Client 108 können mit der Verwendung irgendeines Sitzungs-spezifischen Zusammenhangs fortfahren, der im Speicher oder anderswo gespeichert wurde. Aufgrund der Zwischenstellung des ersten Protokoll-Dienstes 112 kann darüber hinaus der Host-Dienst 116a–116n die Netzunterbrechung zwischen dem ersten Protokoll-Dienst 112 und dem Client 108 nicht wahrnehmen.
  • In einem anderen Beispiel kann der erste Protokoll-Dienst, wenn die zweite Verbindung zwischen dem ersten Protokoll-Dienst 112 und dem Host-Dienst 116a–116n unterbrochen wird, die erste Verbindung mit dem Client 108 aufrechterhalten, während die zweite Verbindung mit dem Host-Dienst 116a–116n wiederhergestellt wird. Nach dem Wiederherstellen der zweiten Verbindung kann der Protokoll-Dienst 112 die Sitzung des Clients für den Client mit dem Host-Dienst 116a–116n neuerlich errichten. Da der erste Protokoll-Dienst 112 jede Sitzungsbezugsinformation aufrechterhielt, kann der erste Protokoll-Dienst dieselbe Sitzung oder eine ähnliche Sitzung widerherstellen, so dass der Client 108 die Unterbrechung in der zweiten Netzverbindung und die daraus hervorgehende Unterbrechung für die Sitzung zwischen dem ersten Protokoll-Dienst 112 und dem Host-Dienst 116a–116n nicht wahrnimmt. Während der neuerlichen Errichtung der zweiten Netzverbindung und der Sitzung, kann der erste Protokoll-Dienst 112 alle Sitzungstransaktionen, die während der Unterbrechung vom Client 108 gesendet werden, in eine Warteschlange setzen. Dann, nach der neuerlichen Errichtung der Sitzung mit dem Host-Dienst 116a–116n, kann der erste Protokoll-Dienst 112 die in Warteschlangen gesetzten Transaktionen an den Host-Dienst 116a–116n übertragen und die Sitzung kann normal fortfahren. Auf diese Weise fährt der Client 108 fort zu arbeiten, wenn es keine Unterbrechung für die Sitzung gab.
  • Zusätzlich vermeidet die vorliegende Erfindung durch die Bereitstellung einer zuverlässigen und persistenten. Verbindung Unterbrechungen in Bezug auf Transaktionen, Befehle oder Betriebe als Teil der Funktionalität, die zwischen dem Client 108 und einem Host-Knoten 118 oder einem Host-Dienst 116a–116n ausgeübt wird. Es wurde z. B. noch kein Datei-Kopierbetrieb mittels Verwendung von Window Explorer entwickelt, um mit der Arbeit fortzufahren, nachdem es eine Unterbrechung in einer Netzverbindung gibt. Ein Anwender am Client 108 kann das Datei-Kopier-Merkmal von Windows Explorer verwendet, um eine Datei vom Client 108 an einen Host-Knoten 118 zu kopieren. Aufgrund der Größe der Datei oder Dateien, kann dieser Betrieb bis zur Beendigung ziemlich lang dauern. Wenn es bei der Hälfte des Betriebs der Kopie der Datei an den Host-Knoten 118 eine Unterbrechung in der Netzverbindung zwischen dem Client 108 und dem Host-Knoten 118 gibt, wird die Datei-Kopie scheitern. Ist die Netzverbindung einmal wiederhergestellt, wird der Anwender einen anderen Datei-Kopierbetrieb von Windows Explorer starten müssen, um die Datei vom Client 108 an den Host-Knoten 118 zu kopieren. Mit der vorliegenden Erfindung bräuchte der Anwender keinen weiteren Datei-Kopier-Betrieb zu starten. Die Netzverbindung würde als Teil der ersten Protokoll-(204)-Verbindung wiederhergestellt werden. Die Datei-Kopierbetriebe würden in der Nutzlast der sekundären Protokolle 200a–200n eingeschlossen werden. Somit würde der Datei-Kopier von Windows Explorer die Unterbrechung in der Netzverbindung nicht mitgeteilt werden und deshalb nicht ausfallen. Der erste Protokoll-Dienst 112 würde alle Verbindungen widerherstellen und alle in Warteschlange gesetzten Daten senden, so dass der Betrieb ohne Ausfall fortfahren kann. Der erste Protokoll-Dienst 112 würde eine Warteschlange der Daten aufrechterhalten, die die Datei-Kopierbetriebe betreffen, die wegen der Unterbrechung in der Netzverbindung nocht nicht an den Host-Knoten 118 übertragen wurden. Ist die Netzverbindung einmal wiederhergestellt, kann der erste Protokoll-Dienst 112 die in Warteschlange gesetzten Daten übertragen und auf der Dauer mit der Überführung der Daten fortfahren, die den Datei-Kopierbetrieb betreffen.
  • Cbwohl dieser Aspekt der Erfindung im Sinne eines Datei-Kopierbetrieb-Beispiels beschrieben wird, wird ein Fachmann auf dem Gebiet erkennen, dass jeder Betrieb, jede Transaktion, jeder Befehl, Funktionsaufruf, usw., die zwischen dem Client 108 und dem Host-Knoten 118 oder dem Host-Dienst 116a–116n abgewickelt werden, ohne Ausfall von der Netzverbindungsunterbrechung und darüber hinaus ohne dass der Client 108 erkennt, das es eine Unterbrechung gab, oder ohne dass er die Unterbrechung merkt, aufrechterhalten und fortgesetzt werden können.
  • Durch die Bereitstellung einer zuverlässigen und persistenten Verbindung erlaubt die vorliegende Erfindung einem Client 108 darüber hinaus, verschiedene Netztopologien zu durchqueren, ohne wieder eine Sitzung oder eine Applikation am Client 108 zu beginnen. Zum Beispiel kann der Client 108 ein Computer-Notebook mit einer drahtlosen Netzverbindung sein. Wenn sich der Client 108 von einem ersten drahtlosen Netz zu einem zweiten drahtlosen Netz bewegt, kann die Netzverbindung 135 des Clients vorübergehend vom ersten drahtlosen Netz unterbrochen werden, da eine Netzverbindung mit dem zweiten drahtlosen Netz errichtet wird. Das zweite drahtlose Netz kann dem Client 108 einen neuen Netzbezeichner wie beispielsweise einen Host-Namen oder eine Internet-Protokolladresse erteilen. Dieser neue Netzbezeichner kann sich vom Netzbezeichner unterscheiden, der dem Client 108 vom ersten drahtlosen Netz erteilt wurde. In einem anderen Beispiel kann der Client 108 mittels eines Internetkabels physisch mit einem Port des Netzes verbunden werden. Die physische Verbindung kann ohne Stecker sein und der Client sich an eine andere Stelle zum Einstecken in einen neuen Port im Netz bewegt haben. Dies würde eine Unterbrechung in der Netzverbindung 135 und womöglich eine Änderung im erteilten Netzbezeichner bewirken. Ohne die vorliegende Erfindung können alle Sitzungen mit einem Host-Dienst 116a–116n am Client 108 oder einer Applikation am Client 108, die auf das Netz zugreifen, infolge der Änderung der Netztopologie, der Unterbrechung in der Netzverbindung 135 und/oder der Änderung im erteilten Netzbezeichner neu gestartet werden müssen. Durch das Verfahren und die Systeme, die hierin beschrieben werden, hält die vorliegende Erfindung die Netzverbindung für den Client aufrecht und stellt die Netzverbindung des Clients 108 wieder her, und zwar einschließlich der Abwicklung von Änderungen in der Netztopologie und im Netzbezeichner. Der Client 108 und alle Applikationen oder Sitzungen am Client können fortfahren zu arbeiten, als ob es keine Netzverbindungsunterbrechung oder Änderung im Netzbezeichner gegeben hätte. Darüber hinaus kann der Anwender am Client 108 nicht erkennen, dass es irgendwelche Unterbrechungen oder Änderungen gab, und der Client 108 kann keine Mitteilung zu diesen Unterbrechungen empfangen.
  • In einem Aspekt betrifft die vorliegende Erfindung das sichere Errichten einer Kommunikationssitzung zwischen dem Client 108 und dem Host-Dienst 116 über mehrere Verbindungen oder "Hops", die mehrere Netzkomponenten durchlaufen, wie z. B. ein Proxy, Sicherheits-Gateway, Firewall oder ein Router. Das Errichten der mehreren Hop-sicheren Kommunikationssitzungen kann weiterhin mittels Verwendung des SSL über einen sicheren Client-Web-Server-Nachrichtenkanal 149, z. B. zwischen dem Web-Browser 162 und dem Web-Server 120 errichtet werden. Die Ticket-Autorität 136 kann Tickets für jeden der Sprünge wie die erste Client-Protokoll-Dienstverbindung 135 und den ersten Protokoll-Dienst mit den Host-Dienstverbindungen 124a–124n bereitstellen. Auf diese Weise wird der Client 108 durch alle Verbindungen zwischen dem Client 108 und dem Host-Dienst 116a–116n berechtigt.
  • Während des Betriebs und auch unter Bezugnahme auf 4, fordert der Client-Anwender (Schritt 400), dass der Inhalt (z. B. eine Applikation, ein Server-Desktop) entfernt am Client 108 (d. h. am ICA-Client 128) angezeigt wird. In einer anderen Ausführungsform verwendet der Client 108 den Web-Browser 162, um eine Applikation anzufordern, und der Web-Server 129 berechtigt dann den Anwender. Nach Empfangen der Anfrage, validiert der Web-Server 120 die Anfrage mit der Ticket-Autorität 136 (Schritt 405). Die Ticket-Autorität 136 erzeugt dann (Schritt 410) ein Ticket, das ein erstes Ticket oder ein Client-Ticket und ein zweites Ticket oder erstes Protokoll-Dienst-Ticket einschließt. Das erste und zweite Ticket sind Tickets für den einmaligen Gebrauch, die nach ihrer Verwendung keinen weiteren Wert mehr haben. In einer weiteren Ausführungsform müssen das erste und zweite Ticket innerhalb einer vorbestimmten Zeitspanne verwendet werden.
  • In einer Ausführungsform speichert die Ticket-Autorität 136 das erste und zweite Ticket im Speicher (z. B. RAM), bis das Ticket verwendet wird. Alternativ speichert die Ticket-Autorität 136 das erste und zweite Ticket in einer Speichervorrichtung (nicht gezeigt), bis das Ticket verwendet wird. Die Speichervorrichtung kann z. B. eine Datenbank oder einen dauerhaften Speicher (z. B. an einem Floppy-Disk, Festplattenlaufwerk) einschließen. Die Ticket-Autorität 136 sendet danach (Schritt 415) das Client-Ticket an den Web-Server 120, und der Web-Server 120 leitet dann (Schritt 420) das Client-Ticket zum Client 108 weiter.
  • Der Client 108 beginnt dann (Schritt 425) eine Kommunikationssitzung mit dem ersten Protokoll-Dienst 112, indem er eine Proxy-Verbindungsanfrage über den ersten Client-Protokoll-Dienst-Nachrichtenkanal 135 sendet. Die Proxy-Verbindungsanfrage schließt das Client-Ticket ein. In einer Ausführungsform schließt die Proxy-Verbindungsanfrage auch ein Pseudo-Password ein, das durch den ersten Protokoll-Dienst 112 ausgetauscht werden kann, wenn eine Kommunikationssitzung mit dem Host-Knoten 118 errichtet wird. In einer weiteren Ausführungsform sendet der Web-Server 120 das Pseudo-Password für die zukünftige Erzeugung einer Proxy-Verbindungsanfrage, die ein Format hat, das für den ersten Protokoll-Dienst 112 annehmbar ist, an den Client 108. Der erste Protokoll-Dienst 112 setzt dann (Schritt 430) das Client-Ticket aus der Proxy-Verbindungsanfrage frei und leitet das Client-Ticket für das Validieren an die Ticket-Autorität 136 weiter. Die Ticket-Autorität 136 validiert dann (Schritt 435) das erste Ticket. In einer Ausführungsform prüft die Ticket-Autorität 136 das erste Ticket, indem sie in ihrer Speichervorrichtung (z. B. Datenbank) nach dem ersten erwarteten Ticket sucht.
  • Wenn die Ticket-Autorität 136 das erste Ticket in der Speichervorrichtung nicht findet (als ob das erste Ticket bereits verwendet wurde), beendet die Ticket-Autorität 136 die Kommunikationssitzung. Wenn das empfangene Ticket mit dem Client-Ticket übereinstimmt, das die Ticket-Autorität 136 erwartet, wird das Client-Ticket validiert. Die Ticket-Autorität 136 sendet dann (Schritt 440) das zweite oder erste Protokoll-Dienst-Ticket an den ersten Protokoll-Dienst 112. Zusätzlich löscht die Ticket-Autorität 136 das Client-Ticket aus der Speichervorrichtung, da das Client-Ticket jetzt einmal verwendet wurde. In einer anderen Ausführungsform sendet die Ticket-Autorität 136 auch die Internetprotokoll-(IP)-Adresse des Host-Knotens 118 an den ersten Protokoll-Dienst 112. In wiederum einer anderen Ausführungsform sendet die Ticket-Autorität 136 den Domänennamen des Host-Knotens 118 für die zukünftige Umwandlung in die IP-Adresse an den ersten Protokoll-Dienst 112.
  • Der erste Protokoll-Dienst 112 empfängt das zweite Ticket oder das erste Protokoll-Dienst-Ticket und öffnet danach die Kommunikationen quer durch den Proxy-Server-Nachrichtenkanal 145, indem er das zweite Ticket an den Host-Knoten 118 sendet (Schritt 445). Der Host-Knoten 118 empfängt das erste Protokoll-Dienst-Ticket und sendet dann das Ticket für die Validierung über den Ticketserver-Nachrichtenkanal 157 an die Ticket-Autorität 136 (Schritt 447). In einer Ausführungsform sendet die Ticket-Autorität 136, wenn die Ticket-Autorität 136 bestimmt, dass das vom Host-Knoten 118 empfangene erste Protokoll-Dienst-Ticket zuvor benutzt worden war oder nicht den richtigen Wert hat (d. h. denselben Wert wie der in der dazugehörigen Speichervorrichtung gespeicherte Wert), eine Fehlernachricht an den ersten Protokoll-Dienst 112 (oder den Web-Server 120), um die errichtete Kommunikationssitzung mit dem Client 108 zu beenden. Wenn die Ticket-Autorität 136 das erste Protokoll-Dienst-Ticket validiert (Schritt 448), dann läßt der Host-Knoten 118 die veröffentlichte ICA-Applikation ablaufen (Schritt 450). Der Host-Knoten 118 sendet dann (Schritt 453) die Applikationsinformation für die Fern-Anzeige der Applikation am Client 108 (Schritt 455) mittels Verwendung des ICA-Clients 128 an den ersten Protokoll-Dienst 112.
  • In einer weiteren Ausführungsform läßt der Client 108 den ICA-Client 128 ablaufen, wenn im Schritt 425 die Kommunikationen mit dem ersten Protokoll-Dienst 112 anfangen. In anderen Ausführungsformen läßt der Client 108 den ICA-Client 128 ablaufen, wenn der Client 108 im Schritt 453 die Applikationsinformation vom ersten Protokoll-Dienst 112 empfängt.
  • Solchermaßen nimmt der Client 108 nicht das erste Protokoll-Dienst-Ticket sondern nur das Client-Ticket wahr. Außerdem kann der ICA-Client 128 nicht auf den Host-Knoten 118 zugreifen, ohne mit dem ersten Protokoll-Dienst 112 zu kommunizieren und das Client-Ticket zu präsentieren.
  • Die Ticket-Autorität 136 könnte im Schritt 440 das erste Protokoll-Dienst-Ticket auch als Anwender-Password für den Anwender des Clients 108 an den ersten Protokoll-Dienst 112 senden. Dies erlaubt dem ersten Protokoll-Dienst 112, das erste Protokoll-Dienst-Ticket als Login-Password zu verwendet, um Zugriff auf den Host-Knoten 118 zu erlangen, ohne die Login-Password des Anwender dem ungeschützten Teil des Webs auszusetzen (d. h. den nicht sicheren ersten Client-Protokoll-Dienst-Nachrichtenkanal 135 während des Schritts 425). Solchermaßen könnte das Kommunikationssystem 100 in einer Ausführungsform eine zentralisierte Password-Abbildungs-Datenbank einschließen, die von der Ticket-Autorität 136 verwaltet und zusammen mit dem Host-Knoten 118 aufgestellt wird, um das erste Protokoll-Dienst-Ticket mit einer Password des Anwenders abzubilden.
  • Daher kann die Password beide Tickets (d. h. das erste Protokoll-Dienst-Ticket und das Client-Ticket) begleiten, oder die Password kann eines der beiden Tickets begleiten. Wie oben beschrieben, ist das erste Protokoll-Dienst-Ticket die Password, wenn die Password eines der beiden Tickets wie beispielsweise das Client-Ticket begleitet. In einer Ausführungsform kann die Password eine System-Password sein, deren Wert sich nicht ändert, oder kann eine Password für den einmaligen Gebrauch sein, wie beispielsweise jene, die von SecurID-Tokens, RSA Security Inc. aus Redford, Massachusetts, entwickelt werden.
  • Zusätzlich kann die Erfindung auf ein Kommunikationssystem ausgedehnt werden, das irgendeine Nummer der ersten Protokoll-Dienste 112 hat, oder "Hops" sein, die der Client 108 mitteilen muss, bevor eine Kommunikationssitzung mit dem Host-Knoten 118 errichtet wird. Obwohl dies in Bezug auf einen ersten Protokoll-Dienst 112 beschrieben, kann ein Hop irgendeine Netzkomponente wie beispielsweise ein Proxy 115, Firewall, Router und Relais umfassen.
  • Als Beispiel und mit Bezug auf 5A ist ein Vier-Hop-Beispiel ein Kommunikationssystem 505, das einen ersten Protokoll-Dienst 112' mit einem Proxy 115', einen zweiten ersten Protokoll-Dienst 112'' mit einem Proxy 115'' und einen dritten ersten Protokoll-Dienst 112''' mit einem Proxy 115''' (allgemein 115) aufweist. Die ersten Protokoll-Dienste 112 mit den Proxies 115 kommunizieren über einen Proxy-Proxy-Nachrichtenkanal wie beispielsweise einen ersten Proxy-Proxy-Nachrichtenkanal 510' und einen zweiten Proxy-Proxy-Nachrichtenkanal 510'' (allgemein Proxy-Proxy-Nachrichtenkanal 510). Der Client 108 kommuniziert mit dem ersten Protokoll-Dienst 112', der mit dem zweiten ersten Protokoll-Dienst 112'' kommuniziert. Der zweite erste Protokoll-Dienst 112'' kommuniziert wiederum mit dem dritten ersten Protokoll-Dienst 112''' und dann der dritte erste Protokoll-Dienst 112''' über den Proxy-Server-Nachrichtenkanal 145 mit dem Host-Knoten 118, um die Kommunikationssitzung mit dem Host-Knoten 118 zu errichten. Obwohl die oben beschriebene Ausführungsform ein Ticket einschließt, das ein Client-Ticket und ein erstes Protokoll-Dienst-Ticket aufweist, schließt eine andere Ausführungsform darüber hinaus das Ticket ein, das zahlreiche Tickets umfasst.
  • Noch ausführlicher und auch mit Bezug auf 5B, empfängt der Web-Server 120 vom Client 108 eine Anfrage für eine Applikation, und der Web-Server 120 validiert die Anfrage mit der Ticket-Autorität 136 (Schritt 405). Die Ticket-Autorität 136 erzeugt dann im Schritt 410 ein N-Teil-Ticket (z. B. T1 bis TN). In einer Ausführungsform sendet die Ticket-Autorität 136 daraufhin einen Abschnitt Ti des N-Teil-Tickets (z. B. den ersten Teil des Tickets oder das erste Ticket T1) an den Web-Server 120 (Schritt 415). Der Web-Server 120 sendet dann das Ticket T1 an den Client 108 (Schritt 420). In einer Ausführungsform sendet die Ticket-Autorität 136 auch die Adresse des nächsten "Hops" (z. B. der erste Protokoll-Dienst 112') an den Web-Server 120, der dann die Adresse an den Client 108 sendet. Diese Adresse ist die Adresse des nächsten Hops (z. B. erster Protokoll-Dienst 112), die diesen Hop (z. B. Client 108) mitkommunizieren muss, damit der Client 108 schließlich am Host-Knoten 118 berechtigt wird.
  • Der Client 108 verwendet die Adresse, um dann den nächste "Hop" (z. B. den ersten Protokoll-Dienst 112') zu kontaktieren, und beginnt eine Kommunikationssitzung mit dem ersten ersten Protokoll-Dienst 112', indem über den ersten Client-Protokoll-Dienst-Nachrichtenkanal 135 eine Proxy-Verbindungsanfrage übertragen wird. Der erste Protokoll-Dienst 112' extrahiert dann (Schritt 530) das erste Ticket T1 aus der Proxy-Verbindungsanfrage und leitet dieses Ticket für das Validieren weiter an die Ticket-Autorität 136. Die Ticket-Autorität 136 validiert dann das erste Ticket T1 (Schritt 535).
  • Bei der richtigen Prüfung des ersten Tickets T1, sendet die Ticket-Autorität 136 das nächste Ticket T1 vom N-Teil-Ticket (z. B. T2) an den nächsten ersten Protokoll-Dienst 112 (z. B. erster Protokoll-Dienst 112') (Schritt 540). In einigen Ausführungsformen sendet die Ticket-Autorität 136 auch die Adresse des nächsten Hops (z. B. der zweite erste Protokoll-Dienst 112'') an diesen Hop (z. B. der erste Protokoll-Dienst 112'). Der erste Protokoll-Dienst 112' sendet dieses Ticket an den nächsten Hop (z. B. der zweite erste Protokoll-Dienst 112'') (Schritt 545). In einer Ausführungsform überprüft der zweite erste Protokoll-Dienst 112'' T2, indem er das Ticket an die Ticket-Autorität 136 sendet (Schritt 550). Die Ticket-Autorität 136 validiert zweite Ticket T2 (Schritt 555), und das Verfahren fährt, wie in den Schritten 560 bis 575 gezeigt, fort. Wurde der letzte Teil des N-Teil-Tickets validiert, erfolgen, wie in 4 gezeigt) die Schritte 450 bis 455, um die Applikation am Client 108 ablaufen zu lassen.
  • In einer Ausführungsform jeder erste Protokoll-Dienst 112 (d. h. jeder Hop) Ti (z. B. T2) mit einer Ticket-Autorität 136 validiert, die zum ersten Protokoll-Dienst 112 (d. h. Hop) gehört. In dieser Ausführungsform sendet, nachdem jeder erste Protokoll-Dienst 112 das Ticket Ti (z. B. T2) mit einer Ticket-Autorität 136 validiert, die Ticket-Autorität 136, an der das Validieren stattfindet, das nächste Ticket Ti + l (z. B. T3) und die Adresse des nächsten ersten Protokoll-Dienstes 112 (d. h. die nächste "Hop"-Bestimmung) an den ersten Protokoll-Dienst 112, der das Ticket Ti validiert hatte. Solchermaßen wird jeder erste Protokoll-Dienst 112 mit einer Ticket-Autorität 136 verknüpft, die mit den aktuellen und den nächsten Hop-Tickets aufgebaut wurde (d. h. Ti validierend und Ti + l für den nächsten Hop sendend). Folglich wirkt der nächste erste Protokoll-Dienst 112 als Client für jenen Hop. Dieses Verfahren wird wiederholt, bis der Host-Knoten 118 im Kommunikationssystem 505 erreicht wird. Solchermaßen wurde jeder Hop einzeln validiert, ohne jedem Hop das gesamte Ticket zu offenbaren.
  • In anderen Ausführungsformen kann die Ticket-Autorität 136 eher mehr als ein Ticket ausgeben, als ein Ticket auszugeben, das viele Teile hat. Zum Beispiel erzeugt die Ticket-Autorität 136 im Schritt 510 ein erstes Hop-Ticket und ein zweites Ticket, worin das erste Hop-Ticket keine Verbindung zum zweiten Hop-Ticket hat. Die Ticket-Autorität 136 sendet danach das erste Hop-Ticket an den Web-Server 120, und der Web-Server 120 sendet das erste Hop-Ticket an den Client 108. Der Client 108 sendet dieses erste Hop-Ticket zur Validierung durch die Ticket-Autorität 136 an den ersten Protokoll-Dienst 112 (z. B. erster Protokoll-Dienst 112'). Beim Validieren im Schritt 535 sendet die Ticket-Autorität 136 im Schritt 540 das zweite Hop-Ticket an den nächsten ersten Protokoll-Dienst 112 (z. B. zweiter erster Protokoll-Dienst 112''), während das erste Hop-Ticket unabhängig vom zweiten Hop-Ticket ist.
  • In einer weiteren Ausführungsform stellen eine oder mehrere Ticket-Autoritäten 136 den Proxies 115 entweder als Teil des ersten Protokoll-Dienstes 112 oder getrennt vom ersten Protokoll-Dienst 112 jede notwendige Information zur Verfügung, die gebraucht wird, um sich mit dem nächsten Hop zu verbinden, wie beispielsweise, ohne darauf eingeschränkt zu sein, Verschlüsselungsschlüssel, eine SSL-Verfahren-Aufbauinformation, und -Authentifikationsinformation, um sich mit einem SOCKS-Server zu verbinden (z. B. ein SOCKS5-Server, der von der NEC Corporation aus Tokyo, Japan, entwickelt wird).
  • In noch einer anderen Ausführungsform erzeugt eine Ticket-Autorität 136 nur ein einziges Ticket. Die Ticket-Autorität 136 sendet das einzige Ticket an den Web-Server 120. Der Web-Server 120 leitet das einzige Ticket an den Client 108 weiter. Der erste Protokoll-Dienst 112 empfängt danach das Ticket vom Client 108 und "verbraucht" beim Validieren das einzige Ticket. Als Ergebnis kann das Kommunikationssystem 100 ein einziges Ticket verwenden, um die Fähigkeit bereitzustellen, willkürliche Kommunikationsprotokolle über den Client-Proxy-Nachrichtenkanal 135 und den Client-Web-Server-Nachrichtenkanal 140 zu verwenden. Da der Host-Knoten 118 das einzige Ticket nicht empfängt oder prüft, ist das Ticket zusätzlich für den Host-Knoten 118 transparent, weshalb der Host-Knoten 118 die Verwendung des Tickets nicht "wahrnimmt".
  • Durch Ausnutzen der Sicherheit der sicheren Kommunikationen zwischen dem Client 108 und dem Web-Server 120 über den sicheren Client-Web-Server-Nachrichtenkanal 140 errichtet das Kommunikationssystem 505 eine sichere Kommunikationsverbindung über den nicht sicheren Client-Proxy-Nachrichtenkanal 135, um Desktop-Applikationen sicher am Client 108 fern-anzuzeigen.
  • In noch einer anderen Ausführungsform und mit Bezug auf 4, sendet die Ticket-Autorität 136 im Schritt 415 für die Übertragung an den Client eine gesperrte Version des ersten Protokoll-Dienst-Tickets mit dem Client-Ticket an den Web-Server 129. Der Client 108 sendet danach (Schritt 425) das erste Protokoll-Dienst-Ticket zusammen mit dem Client-Ticket als Teil der Proxy-Verbindungsanfrage an den ersten Protokoll-Dienst 112. Der erste Protokoll-Dienst 112 leitet dann beide Tickets an die Ticket-Autorität 136 weiter. Beim Empfangen eines gesperrten ersten Protokoll-Dienst-Tickets, gibt die Ticket-Autorität 136 das erste Protokoll-Dienst-Ticket frei, nachdem er das Client-Ticket validiert. Die Ticket-Autorität 136 sendet dann das freigegebene erste Protokoll-Dienst-Ticket für die Authentifizierung für den Host-Knoten 118 an den erste Protokoll-Dienst 112.
  • Alternativ empfängt der Web-Server 120 in einer anderen Ausführungsform ein gesperrtes erstes Protokoll-Dienst-Ticket und ein freigegebenes Ticket von der Ticket-Autorität und sendet nur das Client-Ticket an den Client 108. Der Client 108 sendet (Schritt 425) das Client-Ticket als Teil der Proxy-Verbindungsanfrage an den ersten Protokoll-Dienst 112. Der erste Protokoll-Dienst 112 leitet dann das Client-Ticket an die Ticket-Autorität 136 weiter. Die Ticket-Autorität 136 validiert das Client-Ticket und gibt nach der Validierung das erste Protokoll-Dienst-Ticket frei, das zuvor an den Web-Server 120 gesendet wurde. In noch einer anderen Ausführungsform sendet die Ticket-Autorität 136 ein freigegebenes erstes Protokoll-Dienst-Ticket bei der Validierung des Client-Tickets für die Authentifizierung am Host-Knoten 118 an den Web-Server 120.
  • Solchermaßen setzt die Ticket-Autorität 136 zu irgendeinem gegebenen Zeitpunkt nur ein Ticket bereit, das an den Client 108 oder den ersten Protokoll-Dienst 112 freigegeben wird und von der Ticket-Autorität 136 validiert werden kann. Die Ticket-Autorität 136 kann ein anderes Ticket bereitstellen, das nicht validiert werden kann (d. h. ein gesperrtes Ticket), bis das freigegebene Ticket validiert ist. Alternativ dazu kann die Ticket-Autorität 136 das erste Protokoll-Dienst-Ticket nicht an den ersten Protokoll-Dienst 112 senden, bis die Ticket-Autorität 136 das freigegebene Ticket validiert. Wie weiter unten detailliert erörtert, führt dies das Netz-Routen der Kommunikationen mittels Verwendung des Kommunikationssystems 505 durch, da der Client 108 den Web-Server 120 oder den ersten Protokoll-Dienst 112 nicht durchlaufen kann, ohne dass die Ticket-Autorität 136 das freigegebene Ticket validiert und das Ticket sendet, das gebraucht wird, um mit dem Host-Knoten 118 zu kommunizieren.
  • In einer anderen Ausführungsform sendet die Ticket-Autorität 136, anstatt das erste Protokoll-Dienst-Ticket, wie im Schritt 440, an den ersten Protokoll-Dienst 112 zu senden, das erste Protokoll-Dienst-Ticket direkt über den Web-Server-Autorität-Nachrichtenkanal 250 an den Web-Server 120 senden. Der Web-Server 120 sendet dann automatisch das erste Protokoll-Dienst-Ticket an den Host-Knoten. Mit anderen Worten "stößt" ("push") der Web-Server 120 das erste Protokoll-Dienst-Ticket an den Host-Knoten 118. Die Ticket-Autorität 136 kann das erste Protokoll-Dienst-Ticket auch ohne die Übertragung des ersten Protokoll-Dienst-Tickets an den ersten Protokoll-Dienst 112 oder Web-Server 120 an den Host-Knoten 118 stoßen.
  • In noch einer anderen Ausführungsform holt der Host-Knoten 118 das erste Protokoll-Dienst-Ticket über den Ticket-Inhalt-Server-Nachrichtenkanal 157 von der Ticket-Autorität 136 zurück. Mit anderen Worten "zieht" ("pull") der Host-Knoten 118 das erste Protokoll-Dienst-Ticket von der Ticket-Autorität 136. Die obigen Beispiele sind Darstellungen von Techniken, die verwendet werden, um Schritt 345 auszuschalten (während die Bestimmung der Übertragung im Schritt 440 modifiziert wird).
  • Überdies führt die Erfindung das Routen des Clients 108 durch den ersten Protokoll-Dienst 112 durch. Wie oben geschildert, muss der Client das erste Protokoll-Dienst-Ticket besitzen, um eine Kommunikationssitzung mit dem Host-Knoten 118 zu errichten. Genauer muss der Web-Server zum Errichten einer Verbindung mit dem Host-Knoten 118 als erstes die Anfrage des Clients 108 mit der Ticket-Autorität 136 validieren. Einmal validiert, erhält der Client 108 das erste Ticket und sendet dieses erste Ticket für die Validierung an die Ticket-Autorität 136. Bei Validierung sendet jedoch die Ticket-Autorität 136 das erste Protokoll-Dienst-Ticket lieber an den ersten Protokoll-Dienst 112 als an den Client 108. Die Kommunikationssitzung zwischen dem Client 108 und dem Host-Dienst 116 wird errichtet, wenn der Host-Dienst 116 das erste Protokoll-Dienst-Ticket empfängt. Solchermaßen muss der Client 108 mit dem ersten Protokoll-Dienst 112 kommunizieren, damit das erste Protokoll-Dienst-Ticket an den Host-Dienst 116 übertragen wird, wodurch das Routen des Clients 108 mittels des ersten Protokoll-Dienstes 112 durchgeführt wird. Solchermaßen kann die Erfindung das richtige Durchlaufen einer Sicherheitsvorrichtung (z. B. der erste Protokoll-Dienst 112) gewährleisten, bevor Zugriff auf den Host-Knoten 118 gewährt wird.
  • Zum Beispiel führt ein Host-Knoten 118 mehrere Applikationen aus, wie beispielsweise MICROSOFT WORD und MICROSOFT EXCEL, die beide von der Microsoft Corporation aus Redmond, Washington, entwickelt sind. In einer Ausführungsform verwendet der Client 108 NFUSE, von Citrix Systems, Inc. aus Fort Lauderdale, Florida, entwickelt, um eine Information von der Serverwirtschaft 169 zu erhalten, an der durch den Client 108 auf Applikationen zugegriffen werden kann. Wenn ein Client-Anwender auf MICROSOFT WORD zugreifen und es verwenden will, verlangt der Client 108 die Applikation vom Web-Server 120. Jedoch können nur Anwender, die eine Applikationsgebühr für MICROSOFT WORD bezahlen, berechtigt werden, um auf die Applikation zuzugreifen.
  • Um die Zahlung der Applikationsgebühr zu gewährleisten, schließt das Kommunikationssystem 505 den ersten Protokoll-Dienst 112 und die Ticket-Autorität 136 ein, um das Routen des Clients 108 mittels des ersten Protokoll-Dienstes 112 durchzuführen. Das Routen des Clients 108 mittels des ersten Protokoll-Dienstes 112 ist für den Applikationsprovider nützlich, wenn der erste Protokoll-Dienst 112 verwendet wird, um die Applikationsgebühr zu kassieren und den Anwender für den Zugriff auf die Applikation zu authentifizieren.
  • Die Ticket-Autorität 136 erzeugt danach ein zur Anfrage für die Applikation gehöriges Ticket. Ein freigegebenes erstes Ticket wird dann an den Client 108 übertragen. Da der Client 108 nicht die Adresse des Host-Knotens 118 hat, kann der Client 108 nicht auf die Applikation zugreifen. Weiterhin wurde der Client 108 nicht nicht vom ersten Protokoll-Dienst 112 berechtigt (d. h. wurde noch nicht bezahlt). Solchermaßen muss der Client 108 mit dem ersten Protokoll-Dienst 112 kommunizieren, um berechtigt zu werden. Der erste Protokoll-Dienst kann dann bei Bezahlung der Applikationsgebühr das freigegebene erste Ticket an die Ticket-Autorität 136 senden.
  • Die Ticket-Autorität validiert dann das Client-Ticket und sendet danach (oder gibt frei) ein erstes Protokoll-Dienst-Ticket an den Proxy 115. Der erste Protokoll-Dienst 112 sendet dann das erste Protokoll-Dienst-Ticket an den Host-Knoten 118 (z. B. vorausgesetzt, der Client-Anwender hat die Applikationsgebühr bezahlt), was dem Host-Knoten 118 erlaubt, die Appli kation an den Client 108 zu senden. Das Kommunikationssystem 505 kann auch eine Applikation Launching AND Embedding-(ALE)-Technologie, die von Citrix Systems, Inc., entwickelt wird, verwenden, um das Ablaufen-Lassen der Applikation von einer oder das Einbetten der Applikation in eine HTML-Seite zur Abgabe an den Client 108 zu erlauben.
  • Unter einem weiteren Aspekt betrifft die vorliegende Erfindung das Wieder-Verbinden eines Clients 108 mit einem Host-Dienst 116 und das Wieder-Berechtigen der Verbindungen oder "Hops" zwischen dem Client 108 und dem Host-Dienst 116. 6A zeigt eine andere darstellende Ausführungsform eines Systems 600, das in der Lage ist, den Client 108 mit einem Host-Dienst 116 wieder zu verbinden. Zusätzlich zu den Netzen 104 und 104', dem Client 108, dem ersten Protokoll-Dienst 112 und den Host-Diensten 116, die alle oben beschrieben werden, schließt das System 600 weiterhin einen Zwischenknoten 632 und eine Ticket-Autorität 136 ein. In einer Ausführungsform ist der Zwischenknoten 632 ein Sicherheits-Gateway wie beispielsweise Firewall und/oder ein Router, durch den infolge des Aufbaus des Netzes 104 Nachrichten zwischen dem Client 108 und dem ersten Protokoll-Dienst 112 dringen müssen. Zusätzlich kann der Zwischenknoten 632 den Proxy 115 des ersten Protokoll-Dienstes 112 entweder mit oder ohne den ersten Protokoll-Dienst 112 umfassen. Die Ticket-Autorität 136 kann, wie dargestellt, eine unabhängige Netzkomponente sein, die zu Kommunikationen in der Lage ist und genug Prozessorleistung und Speicherkapazität hat, um die hierin beschriebenen Betriebe durchzuführen.
  • Wie in der darstellenden Ausführungsform der 6A gezeigt, ist der Zwischenknoten 632 aufgebaut, um eine vom Client 108 begonnene Verbindung 135a anzunehmen und um eine zweite Verbindung 135b mit dem ersten Protokoll-Dienst 112 zu errichten. Gemeinsam bilden die Verbindung 135a und die zweite Verbindung 135b die oben beschriebene Verbindung 135, über die der Client 108 und der erste Protokoll-Dienst 112 mittels Verwendung des ersten Protokolls kommunizieren.
  • Der Zwischenknoten 632 ist, wie gezeigt, ebenfalls aufgebaut, um mit der Ticket-Autorität 136 zu kommunizieren. In einer Ausführungsform ist die Ticket-Autorität 136 aufgebaut, um eine Anfrage für ein erstes Wieder-Verbindungs-Ticket vom Zwischenknoten 632 zu empfangen und danach das erste Wieder-Verbindung-Ticket zu erzeugen. Das erste Wieder-Verbindung-Ticket kann z. B. eine große zufällige Nummer einschließen. In einer anderen Ausführungsform ist die Ticket-Autorität 136 aufgebaut, um eine Anfrage für ein erstes Wieder-Verbindung-Ticket für jedes der "Hops" zwischen dem Client und dem Host-Dienst 116 zu empfangen. Der Zwischenknoten 632 kann z. B. Wieder-Verbindung-Tickets für die Verbindung zwischen dem Client 108 und dem Zwischenknoten 632, zwischen dem Zwischenknoten 632 und dem ersten Protokoll-Dienst 112 und zwischen dem ersten Protokoll-Dienst 112 und dem Host-Dienst 116 anfordern. Diese Wieder-Verbindung-Tickets können nur für jeweils einen "Hop" gültig sein. Ein erstes Wieder-Verbindung-Ticket für die Verbindung des ersten Protokoll-Dienstes 112 zum Host-Dienst 116 ist z. B. nur für die Authentifizierung des ersten Protokoll-Dienstes 112 zum Host-Dienst 116 im Auftrag des Clients 108 gültig.
  • In einer anderen Ausführungsform ist die Ticket-Autorität 136 aufgebaut, um ein Handle zu erzeugen. Das Handle kann z. B. eine Zufallszahl sein, die zum ersten Wieder-Verbindung-Ticket gehört (z. B. dazu abgebildet). In einer Ausführungsform ist das Handle eine kleinere Zufallszahl als die Zufallszahl, die das erste Wieder-Verbindung-Ticket bildet. Das Handle kann z. B. eine 32-Bit-Zufallszahl sein. In einer weiteren Ausführungsform ist das zu einem Ticker oder einem Wieder-Verbindung-Ticket gehörende Handle eine Adresse vom oder ein Zeiger für den nächsten "Hop" in der Mehrfach-Hop-Verbindung zwischen dem Client 108 und dem Host-Dienst 116. In diesem Fall wird ein Ticket oder Wieder-Verbindung-Ticket für einen einzigen "Hop" mit einem Zeiger auf den nächsten "Hop" validiert. Der nächste "Hop" wird ein anderes Ticket oder Wieder-Verbindung-Ticket erhalten und validieren müssen, usw., bis der letzte "Hop" validiert und im Auftrag des Clients 108 mit dem Host-Dienst 116 verbunden wird.
  • Die Ticket-Autorität 136 sendet das erste Wieder-Verbindung-Ticket und das Handle an den Zwischenknoten 632, während er eine Kopie des ersten Wieder-Verbindung-Tickets und eine Kopie des Handles bewahrt. Die Kopie des ersten Wieder-Verbindung-Tickets kann später von der Ticket-Autorität 136 verwendet werden, um das erste Wieder-Verbindung-Ticket zu validieren, das ursprünglich an den Client 108 übertragen wurde, wenn es später, während des Verfahrens des Wieder-Verbindens des Clients 108 der Ticket-Autorität 136 gezeigt wird. In einer Ausführungsform hält die Ticket-Autorität 136 auch eine Adresse für den ersten Protokoll-Dienst 112, der, wie unten erklärt, zum ersten Wieder-Verbindung-Ticket gehört, und beim Validieren des ersten Wieder-Verbindung-Tickets an den Zwischenknoten 632 übertragen wird.
  • In einer Ausführungsform ist der Zwischenknoten 632 weiterhin aufgebaut, um das von der Ticket-Autorität 136 dahin gesandten Handle zu verwenden, damit die Kopie des an der Ticket-Autorität 136 aufbewahrten Wieder-Verbindung-Tickets gelöscht wird. In einer anderen Ausführungsform ist die Ticket-Autorität 136, wie unten beschrieben, weiterhin aufgebaut, um während des Verfahrens der Wieder-Verbindung des Clients 108 mit einem Host-Dienst 116 das erste Wieder-Verbindung-Ticket zu löschen und danach ein erstes Ersetzungs-Wieder-Verbindung-Ticket zu erzeugen. Zusätzlich ist das erste Wieder-Verbindung-Ticket in einer anderen Ausführungsform für das automatische Löschen nach einer vorbestimmten Zeitspanne aufgebaut. In der Ausführungsform der Wieder-Verbindung-Tickets für jeden der "Hops" zwischen dem Client und dem Host-Dienst 116 können ein, einige oder alle Wieder-Verbindung-Tickets für das automatische Löschen nach einer vorbestimmten Zeitspanne aufgebaut sein. In anderen Ausführungsformen ist die Ticket-Autorität 136 oder der Zwischenknoten 632 aufgebaut, um jedes der Mehrfach-Hop-Tickets zu löschen und Ersetzung-Tickets zu erzeugen.
  • In einer anderen Ausführungsform ist der erste Protokoll-Dienst 112 aufgebaut, um ein zweites Wieder-Verbindung-Ticket zu erzeugen, das, wie im Fall des ersten Wieder-Verbindung-Tickets, z. B. eine große Zufallszahl einschließen kann. In einer Ausführungsform erzeugt der erste Protokoll-Dienst 112 zweite Wieder-Verbindung-Tickets für jeden der "Hops" zwischen dem Client 108 und dem Host-Dienst 112. Der erste Protokoll-Dienst 112 kann auch aufgebaut sein, um das zweite Wieder-Verbindung-Ticket an den Client 108 zu senden, während eine Kopie des zweiten Wieder-Verbindung-Tickets und einer Sitzungsnummer bewahrt wird. Die Kopie des zweiten Wieder-Verbindung-Tickets kann später vom ersten Protokoll-Dienst 112 verwendet werden, um das ursprünglich an den Client 108 übertragene zweite Wieder-Verbindung-Ticket zu validieren, wenn es später während des Wieder-Verbindens des Clients 108 dem ersten Protokoll-Dienst 112 vorgelegt wird. In einer Ausführungsform sendet der erste Protokoll-Dienst 112 das zweite Wieder-Verbindung-Ticket über den Zwischenknoten 632 an den Client 108. In einer anderen Ausführungsform sendet der erste Protokoll-Dienst 112 das zweite Wieder-Verbindung-Ticket direkt an den Client 108. In einer weiteren Ausführungsform kann der erste Protokoll-Dienst 112 die zweiten Wieder-Verbindung-Tickets an die anderen ersten Protokoll-Dienste 112 oder Zwischenknoten 632 übertragen werden, die die Mehrfach-Hop-Verbindung zwischen dem Client 108 und dem Host-Dienst 116 umfassen kann.
  • Wie detaillierter unten beschrieben, kann der erste Protokoll-Dienst außerdem weiterhin aufgebaut sein, um während des Verfahrens des Wieder-Verbindens des Clients 108 mit einem Host-Dienst 116 das zweite Wieder-Verbindung-Ticket zu löschen und danach ein zweites Ersetzungs-Wieder-Verbindung-Ticket zu erzeugen. In einer anderen Ausführungsform ist zusätzlich das zweite Wieder-Verbindung-Ticket für das automatische Löschen nach einer vorbestimmten Zeitspanne aufgebaut. In weiteren Ausführungsformen ist ein erster Protokoll-Dienst 112 eines oder mehrerer erster Protokoll-Dienste 112 in einer Mehrfach-Hop-Verbindung aufgebaut, um die zweiten Wieder-Verbindung-Tickets für jedes der "Hops" zu köschen und danach zweite Ersetzungs-Wieder-Verbindung-Tickets für ein, einige oder alle "Hops" zu erzeugen.
  • In einer Ausführungsform dient der Zwischenknoten 632 als ein Zwischenstück für die ersten und zweiten Wieder-Verbindung-Tickets. Der Zwischenknoten 632 empfängt z. B. das von der Ticket-Autorität 136 erzeugte erste Wieder-Verbindung-Ticket und das vom ersten Protokoll-Dienst 112 erzeugte zweite Wieder- Verbindung-Ticket. Der Zwischenknoten 632 kann dann das erste Wieder-Verbindung-Ticket und das zweite Wieder-Verbindung-Ticket an den Client 108 senden. Überdies kann der Zwischenknoten 632 während des Verfahrens des Wieder-Verbindens des Clients 108 mit einem Host-Dienst 116 das erste Wieder-Verbindung-Ticket und das zweite Wieder-Verbindung-Ticket vom Client 108 annehmen und danach das erste Wieder-Verbindung-Ticket an die Ticket-Autorität 136 und, falls erforderlich, das zweite Wieder-Verbindung-Ticket an den ersten Protokoll-Dienst 112 senden.
  • In einer anderen Ausführungsform dient der Zwischenknoten 632 als ein Zwischenstück für die Wieder-Verbindung-Tickets für die Mehrfach-Sprünge zwischen dem Client 108 und dem Host-Dienst 116. Der Zwischenknoten 632 empfängt z. B. das erste Wieder-Verbindung-Ticket für die Verbindung des Clients 108 mit dem ersten Protokoll-Dienst 112 und das erste Wieder-Verbindung-Ticket für den ersten Protokoll-Dienst 112 mit dem Host-Dienst 116. In einer weiteren Ausführungsform empfängt der Zwischenknoten 632 ein erstes Wieder-Verbindung-Ticket für die Verbindung zwischen dem Zwischenknoten 632 und dem ersten Protokoll-Dienst 112. Der Zwischenknoten 632 kann dann das erste Wieder-Verbindung-Ticket für den Client an den Client 108 und das erste Wieder-Verbindung-Ticket für den ersten Protokoll-Dienst 112 an den ersten Protokoll-Dienst 112 senden. Während des Verfahrens der Wieder-Verbindung des Clients 108 mit einem Host-Dienst 116 kann der Zwischenknoten 632 außerdem das erste Wieder-Verbindung-Ticket vom Client 108 annehmen, um das Ticket zu validieren, damit die Verbindung des Clients mit dem Zwischenknoten 632 oder dem ersten Protokoll-Dienst 112 wiederhergestellt wird.
  • Auf 6B Bezug nehmend, schließt eine andere Ausführungsform eines Systems 602 für Netzkommunikationen, wie oben beschrieben, die Netze 104 und 104', den Client 108, den ersten Protokoll-Dienst 112, die Host-Dienste 116a–116n, den Zwischenknoten 632 und die Ticket-Autorität 136 ein und stellt weiterhin einen ersten Rechenknoten 640 und einen zweiten Rechenknoten 644 ein, die in einer Ausführungsform beide für die anfängliche Verbindung des Clients 108 mit einem Host-Dienst 116 verwendet werden. In der darstellenden Ausführungsform aus 6A schließt überdies der Client 108 weiterhin einen Web-Browser wie beispielsweise das INTERNET EXPLORER-Programm der Microsoft Corporation aus Redmond, WA, ein, um mit dem World Wide Web zu verbinden.
  • In einer Ausführungsform (nicht gezeigt) schließt das System 602 zwei oder mehr Zwischenknoten 632 und/oder zwei oder mehr erste Protokoll-Dienste 112 ein. Der Zwischenknoten 632, durch den Nachrichten zwischen dem Client 108 und dem ersten Protokoll-Dienst 112 dringen müssen, und/oder der erste Protokoll-Dienst 112 kann, wie unten erläutert, jeweils beispielsweise auf der Grundlage einer Lastausgleichsgleichung ausgewählt werden.
  • Jeder der ersten Rechenknoten 640 und der zweiten Rechenknoten 644 kann irgendeine Computervorrichtung sein, die zu einer Kommunikation in der Lage ist und genug Prozessorleistung und Speicherkapazität hat, um die hierin beschriebenen Betriebe durchzuführen. In einer Ausführungsform umfasst der erste Rechenknoten 640 einen Web-Server 120, der eine oder mehrere Webseiten umfasst. In einer anderen Ausführungsform stellt der zweite Rechenknoten 644 einen XML-Dienst bereit.
  • In einer Ausführungsform bilden der Client 108 und das Netz 104 ein externes Netz 652, das durch einen ersten Firewall 160 vom Rest des Systems 602 getrennt liegt, mit einer gestrichelten Linie gezeigt. Der Zwischenknoten 632 und der erste Rechenknoten 640 können sich in einer DMZ 130 befinden, die durch den ersten Firewall 160 und einen zweiten Firewall 161 vom Rest des Systems 602 getrennt werden, ebenfalls mit einer gestrichelten Linie gezeigt. Wie gezeigt, bilden dann das Netz 104', der erste Protokoll-Dienst 112, die Host-Dienste 116a–116n, die Ticket-Autorität 136 und der zweite Rechenknoten 644 ein internes Netz 668, das durch den zweiten Firewall 161 vom Rest des Systems 602 getrennt wird.
  • In einer anderen Ausführungsform und mit Bezug auf 6C, schließt das System 604 alternativ weiterhin einen dritten in der DMZ 130 positionierten Rechenknoten 646 zwischen dem Netz 104 und dem Zwischenknoten 632 ein. Der dritte Rechenknoten 646 kann irgendeine Computervorrichtung sein, die zu vernetzten Kommunikationen in der Lage ist und genu Prozessorleistung und Speicherkapazität hat, um die hierin beschriebenen Betriebe durchzuführen. Wie unten beschrieben, wird der dritte Rechenknoten 646 in einigen Ausführungsformen während des Verfahrens des anfänglichen Verbindens des Clients 108 mit einem Host-Dienst 116 und/oder während des Verfahrens des Wieder-Verbindens des Clients 108 mit einem Host-Dienst 116 verwendet. Genauer kann der dritte Rechenknoten 646, wie unten beschrieben, wenn das System 604 zwei oder mehr Zwischenknoten 632 einschließt, z. B. auf der Grundlage einer Lastausgleichsgleichung den Zwischenknoten 632 wählen, durch den Kommunikationen zwischen dem Client-Agent 128 des Clients 108 und dem ersten Protokoll-Dienst 112 gehen müssen.
  • Bezugnehmend auf 6D, kann der Zwischenknoten 632 überdies in einer alternativen Ausführungsform durch zwei oder mehr Stufen "a"–"n" an Zwischenknoten 632 ersetzt werden. Wie dargestellt, kann jede Stufe "a"–"n" zwei oder mehr Zwischenknoten 632A–632n einschließen. Wie unten beschrieben, kann der Client-Agent 128 des Clients 108 mittels irgendeiner Kombination aus Zwischenknoten 632 beispielsweise auf der Grundlage von Lastausgleichsgleichungen geroutet werden. Wie dargestellt, kann der Client-Agent 128 z. B. über die Verbindung 622 durch die Zwischenknoten 622 geroutet werden. Für eine zusätzliche Sicherheit können die "Hops" jeweils über die Verbindung 622 ein Ticket oder Wieder-Verbindung-Ticket für die Validierung und Berechtigung der Mehrfach-Hopverbindung zwischen dem Client 108 und dem Host-Dienst 116 benötigen. Andere Aufbauten der Systeme 600, 602 und 604 sind ebenfalls möglich, wie für die Fachleute auf dem Gebiet ohne weiteres ersichtlich wäre.
  • Wiederum auf 6B Bezug nehmend, kommuniziert der Web-Browser 162 in einer Ausführungsform über das Netz 104 mit dem ersten Rechenknoten 640, der seinerseits eine Schnittstelle mit dem zweiten Rechenknoten 644 und der Ticket-Autorität 136 bildet. Genauer ist der erste Rechenknoten 640 mit der Adresse des zweiten Rechenknotens 644 und der Ticket-Autorität 136 aufgebaut. In einer Ausführungsform ist der erste Rechenknoten 640, wie weiter unten erläutert, aufgebaut, um die Information zwischen dem Web-Browser 162 des Clients 108, dem zweiten Rechenknoten 644 und der Ticket-Autorität 136 weiterzuleiten und dadurch die direkte Kommunikation dazwischen zu verhindern. Durch das Verhindern dieser direkten Kommunikation fügt der erste Rechenknoten 640 eine zusätzliche Sicherheitsstufe zum System 602 hinzu. Der erste Rechenknoten 640 kann auch mit der Adresse des Zwischenknotens 632 oder alternativ mit der Adresse von zwei oder mehreren Zwischenknoten 632 konfiguriert sein.
  • Seinerseits ist der zweite Rechenknoten 644 aufgebaut, um zu bestimmen, welche an den Host-Diensten 116 ablaufenden Applikationsprogramme für einen Anwender des Clients 108 verfügbar sind. Mit anderen Worten ist der zweite Rechenknoten 644 aufgebaut, um zu bestimmen, welches der Applikationsprogramme der Anwender zuzugreifen berechtigt ist. In einer Ausführungsform ist, nachdem der Anwender, wie weiter unten beschrieben, sein gewünschtes Applikationsprogramm wählt, der zweite Rechenknoten 644 weiterhin aufgebaut, um zu bestimmen, welcher der Host-Dienste 116 verwendet werden wird, um zum Zwecke des Lastausgleichs die gewünschte Applikation des Anwenders auszuführen. Der zweite Rechenknoten 644 gibt die Adresse dieses Host-Dienstes 116 an den ersten Rechenknoten 640 zurück. Der zweite Rechenknoten 644 gibt ebenfalls die Adresse des ersten Protokoll-Dienstes 112, der auch aus mehreren ersten Protokoll-Diensten ausgewählt wird, mittels Verwendung einer Lastausgleichsgleichung an den ersten Rechenknoten 640 zurück. Der erste Rechenknoten 640 sendet wiederum die Adresse des gewählten ersten Protokoll-Dienstes 112 und des gewählten Host-Dienstes 116 an die Ticket-Autorität 136.
  • Ihrerseits erzeugt die Ticket-Autorität 136 Verbindung-Tickets. In einer Ausführungsform sendet die Ticket-Autorität 136 ein anfängliches Verbindung-Ticket für die Übertragung an den Client 108 an den ersten Rechenknoten 640. In einer anderen Ausführungsform sendet die Ticket-Autorität 136 die anfänglichen Verbindung-Tickets für ein oder mehrere der "Hops" zwischen dem Client 108 und dem Host-Dienst 116 an den ersten Rechenknoten 640.
  • Nimmt man jetzt auf 7 Bezug, wird eine Ausführungsform eines Verfahrens 600 für Netzkommunikationen dargestellt, indem die beispielhafte Ausführungsform der 6A–6D verwendet wird. Im Schritt 604 verbindet sich der Client 108 anfangs mit mehreren Host-Diensten 116, indem er z. B. das unten beschriebene Verfahren 700 benutzt. Nachdem der Client 108 mit mehreren Host-Diensten 116 verbunden ist, kommunizieren der Client 108 und die Host-Dienste 116 mittels des ersten Protokoll-Dienstes 112 und im Schritt 608 über mehrere innerhalb des ersten Protokolls eingeschlossene sekundäre Protokolle. In einer Ausführungsform verschlüsselt der erste Protokoll-Dienst 112 vor der Übertragung irgendwelcher ersten Protokollpakete Kommunikationen auf der Ebene des ersten Protokolls 204, wodurch die Kommunikationen gesichert werden. In einer anderen Ausführungsform komprimiert der erste Protokoll-Dienst 112 die Kommunikationen auf der Ebene des ersten Protokolls vor der Übertragung irgendwelcher ersten Protokollpakete, wodurch der Kommunikationswirkungsgrad verbessert wird.
  • Im Schritt 612 bestimmt der Client-Agent 128, ob die Verbindung 135 zwischen dem Client-Agent 128 und dem ersten Protokoll-Dienst 112 ausgefallen ist. Zum Beispiel können die Verbindung 135a zwischen dem Client-Agent 128 und dem Zwischenknoten 632, die Verbindung 135b zwischen dem Zwischenknoten 632 und dem ersten Protokoll-Dienst 135b oder beide Verbindungen, Verbindung 135a und Verbindung 135b, ausgefallen sein. In einer anderen Ausführungsform kann die Verbindung zwischen dem ersten Protokoll-Dienst 112 und dem Host-Dienst 116 ausgefallen sein. Wenn der Client-Agent 128 bestimmt, dass die Verbindung 135 nicht ausgefallen ist, rückt das Verfahren 600 auf den Schritt 620 vor. Wenn der Client-Agent 128 andererseits bestimmt, dass die Verbindung 135 ausgefallen ist, wird dem Client 108 im Schritt 616 eine zuverlässige Verbindung zu den Host-Diensten 116 zur Verfügung gestellt und er mit den Host-Diensten 116 wieder-verbunden.
  • Es wird im Schritt 620 bestimmt, ob der Client 108 seine Verbindung 135 mit dem ersten Protokoll-Dienst 112 und folglich seine Verbindungen 124a–124n mit den Host-Diensten 116 einwandfrei beenden möchte. Wenn nicht, setzt sich die Kommunikation zwischen dem Client 108 und dem ersten Protokoll-Dienst 112 über die mehreren innerhalb des ersten Protokolls eingeschlossenen sekundären Protokolle im Schritt 608 fort. Falls dem so ist, werden im Schritt 624 alle Verbindungen 135a, 135b und 124a–124n unterbrochen und alle Wieder-Verbindung-Tickets gelöscht. In einer Ausführungsform verwendet der Zwischenknoten 632 ein Handle, das er von der Ticket-Autorität 136 empfängt, um eine Kopie eines an der Ticket-Autorität 136 aufbewahrten ersten Wieder-Verbindung-Tickets zu löschen. In einer anderen Ausführungsform löscht der erste Protokoll-Dienst 112 eine am ersten Protokoll-Dienst 112 aufbewahrte Kopie eines zweiten Wieder-Verbindung-Tickets. In einer weiteren Ausführungsform wird eine Kopie des zweiten dazugehörigen und am ersten Protokoll-Dienst 112 aufbewahrten Wieder-Verbindung-Tickets durch den ersten Protokoll-Dienst 112 gelöscht. In noch einer anderen Ausführungsform wird ein erstes Wieder-Verbindung-Ticket und/oder ein zweites Wieder-Verbindung-Ticket im Anschluss an eine vorbestimmte Zeitspanne, die wie im Schritt 612 einem Ausfall in der Verbindung folgt und/oder wie im Schritt 620 einer einwandfreien Beendigung der Verbindng 135 folgt, automatisch gelöscht. In anderen Ausführungsformen löscht entweder der erste Protokoll-Dienst 112 oder die Ticket-Autorität 136 ein oder mehrere Wieder-Verbindung-Tickets für ein oder mehrere "Hops" zwischen dem Client 108 und dem Host-Dienst 116.
  • Nimmt man auf die 8A–8C Bezug, wird eine Ausführungsform eines Verfahrens 700 für das anfängliche Verbinden des Clients 108 mit den Host-Diensten 116 (z. B. im Schritt 604 der 7) dargestellt, indem die beispielhafte Ausführungsform der 6A–6D verwendet wird. Im Schritt 704 sendet der Client 108 mittels Verwendung des Browsers 162 eine Anfrage wie beispielsweise eine HTTP-Anfrage an den ersten Rechenknoten 640. Der erste Rechenknoten 640 gibt eine Webseite wie beispielsweise ein HTML-Formular zurück, die die Authentifikationsinformation verlangt (z. B. Anwendername und Password). Ein Anwender des Clients 108 gibt seine Zugangsdaten ein und sendet das ausgefüllte Formular an den ersten Rechenknoten 640.
  • Der erste Rechenknoten 640 informiert den Anwender des Clients 108 dann im Schritt 708 über für die Ausführung zur Verfügung stehende Applikationen. In einer Ausführungsform extrahiert der erste Rechenknoten 640 die Zugangsdaten des Anwenders von der Login-Seite und sendet sie zusammen mit einer Anfrage für den zweiten Rechenknoten 644, die dem Anwender zur Verfügung stehenden Applikationen aufzuzählen, an den zweiten Rechenknoten 644. Auf der Grundlage der Zugangsdaten des Anwenders gibt der zweite Rechenknoten 644 eine Liste der dem Anwender zur Verfügung stehenden spezifischen Applikationen an den ersten Rechenknoten 640 zurück, der dann die Liste in Form einer Webseite z. B. an den Anwender des Clients 108 weiterleitet.
  • Im Schritt 712 wählt der Anwender die gewünschte Applikation, und eine Anfrage für diese Applikation wird dem ersten Rechenknoten 640 zugesandt. In einer Ausführungsform klickt der Anwender z. B. auf eine gewünschte Applikation, die in der Webseite aufgelistet ist, die ihm vom ersten Rechenknoten 640 gezeigt wird, und eine HTTP-Anfrage für diese Applikation wird an den ersten Rechenknoten 640 weitergeleitet. Die Anfrage wird durch den ersten Rechenknoten 640 verarbeitet und an den zweiten Rechenknoten 644 weitergeleitet.
  • Im Schritt 716 bestimmt der zweite Rechenknoten 644 den Host-Dienst 116, an dem die gewünschte Applikation ausgeführt werden wird. Der zweite Rechenknoten 644 kann diese Bestimmung z. B. auf der Grundlage einer Lastausgleichsgleichung machen. In einer Ausführungsform bestimmt der zweite Rechenknoten 644 auch einen ersten Protokoll-Dienst 112 unter mehreren ersten Protokoll-Diensten 112, die verwendet werden werden, um über eine Verbindung 124 mit dem Host-Dienst 116 zu kommunizieren. Wiederum kann der zweite Rechenknoten 644 diese Bestimmung z. B. auf der Grundlage einer Lastausgleichsgleichung vornehmen. Der zweite Rechenknoten 644 gibt die Adresse des gewählten Host-Dienstes 116 und den gewählten ersten Protokoll-Dienst 112 an den ersten Rechenknoten 640 zurück.
  • Dem Client 108 wird dann im Schritt 720 ein anfängliches Verbindung-Ticket und eine Adresse für den Zwischenknoten 632 (das, wie oben beschrieben, entweder seine tatsächliche Adresse oder seine virtuelle Adresse ist) bereitgestellt. In einer Ausführungsform stellt der erste Rechenknoten 640 der Ticket-Autorität 136 zusammen mit einer Anfrage nach dem anfänglichen Verbindung-Ticket die Adresse für den gewählten Host-Dienst 116 und den gewählten ersten Protokoll-Dienst 112 bereit. Die Ticket-Autorität 136 bewahrt die Adresse des gewählten Host-Dienstes 116 und des gewählten ersten Protokoll-Dienstes 112, erzeugt das anfängliche Verbindung-Ticket und sendet das anfängliche Verbindung-Ticket an den ersten Rechenknoten 640, während sie eine Kopie für sich selbst behält. In einer Ausführungsform erzeugt die Ticket-Autorität 136 als Reaktion auf die Anfrage nach dem anfänglichen Verbindung-Ticket durch den ersten Rechenknoten 640 Verbindung-Tickets für jedes der "Hops" zwischen dem Client 108 und dem Host-Dienst 116. In einer anderen Ausführungsform fordert der erste Rechenknoten 640 anfängliche Verbindung-Tickets für jeden der "Hops" entweder in einer einzigen Anfrage oder in mehreren Anfragen. Die Ticket-Autorität 126 kann z. B., wie oben in Verbindung mit 5B erörtert, ein mehrteiliges Ticket erzeugen.
  • Der erste Rechenknoten 640, der in einer Ausführungsform mit der tatsächlichen Adresse des Zwischenknotens 632 aufgebaut ist, sendet dann die tatsächliche Adresse des Zwischenknotens 632 und das anfängliche Verbindung-Ticket an den Browser 162 des Clients 108. Der erste Rechenknoten 640 kann z. B. als erstes eine Datei, die sowohl die tatsächliche Adresse als auch den Zwischenknoten 632 und das anfängliche Verbindung-Ticket enthält, erzeugen und dann die Datei an den Browser 162 des Clients 108 übertragen. Wahlweise ist der erste Rechenknoten 640 in einer anderen Ausführungsform mit der tatsächlichen Adresse der beiden oder mehreren Zwischenknoten 632 aufgebaut. In einer solchen Ausführungsform bestimmt der erste Rechenknoten 640 zunächst den Zwischenknoten 632, durch den Nachrichten zwischen dem Client 108 und dem ersten Protokoll-Dienst 112 gehen werden müssen. Der erste Rechenknoten 640 sendet dann die tatsächliche Adresse dieses ausgewählten Zwischenknotens 132 und das anfängliche Verbindung-Ticket an den Browser 162 des Clients 108, indem er z. B. die oben beschriebene Datei verwendet. In einer Ausführungsform wählt der erste Rechenknoten 640 mittels Verwendung einer Lastausgleichsgleichung den Zwischenknoten 632. Der Client-Agent 128 des Clients 108 wird dann ablaufen gelassen und er verwendet die Adresse des Zwischenknotens 632, um im Schritt 724 eine erste Protokoll-Verbindung 135a zwischen dem Client-Agent 128 des Clients 108 und dem Zwischenknoten 632 zu errichten. In einer Ausführungsform kann der erste Rechenknoten 640 dem einen oder den mehreren ersten Protokoll-Diensten 112 und/oder Zwischenknoten 632 von der Ticket-Autorität 136 erhaltene anfängliche Verbindung-Tickets zur Verfügung stellen, um ihre jeweiligen Verbindungen zu validieren.
  • In einer anderen Ausführungsform ist der erste Rechenknoten 640 alternativ mit einer tatsächlichen Adresse des dritten Rechenknotens 646 aufgebaut, der als virtuelle Adresse eines Zwischenknotens 132 dient. In einer solchen Ausführungsform sendet der erste Rechenknoten 640 im Schritt 720 die tatsächliche Adresse des dritten Rechenknotens 646 und des anfänglichen Verbindung-Tickets an den Browser 162 des Clients 108 beispielsweise mittels Verwendung der oben beschriebenen Datei. Der Client-Agent 128 des Clients 108 wird dann ablaufen gelassen und er verwendet die tatsächliche Adresse des dritten Rechenknotens 646, um im Schritt 724 eine erste Protokoll-Verbindung zwischen dem Client-Agent 128 des Clients 108 und dem dritten Rechenknoten 646 zu errichten. Der dritte Rechenknoten 646 bestimmt daraufhin den Zwischenknoten 632, durch den Nachrichten zwischen dem Client 108 und dem ersten Protokoll-Dienst 112 gehen werden müssen. In einer Ausführungsform wählt der dritte Rechenknoten 646 mittels Verwendung einer Lastausgleichsgleichung den Zwischenknoten 632. Hat er einmal den Zwischenknoten 632 ausgewählt, errichtet der dritte Rechenknoten 646 eine erste Protokoll-Verbindung mit dem Zwischenknoten 632. Eine erste Protokoll-Verbindung 135a besteht daher durch den dritten Rechenknoten 646 zwischen dem Client-Agent 128 des Clients 108 und dem Zwischenknoten 632. Die tatsächliche Adresse des dritten Rechenknotens 646 wird daher an der tatsächlichen Adresse des Zwischenknotens 632 abgebildet. Dem Client-Agent 128 des Clients 108 dient daher die tatsächliche Adresse des dritten Rechenknotens 646 als virtuelle Adresse des Zwischenknotens 632.
  • In einer Ausführungsform, in der es, wie oben beschrieben, mehr als eine Ebene an Zwischenknoten 632 gibt, wählen der erste Rechenknoten 640 oder der dritte Rechenknoten 646 jeweils nur den Zwischenknoten 632, mit dem sich der Client-Agent 128 auf der Ebene "a" verbinden wird. In einer solchen Ausführungsform bestimmt auf jeder der Ebenen "a"–"n – 1" der Zwischenknoten 632, durch den der Client-Agent 128 geroutet wird, anschließend auf dieser Ebene auf der Grundlage einer Lastausgleichsgleichung z. B. den Zwischenknoten 632, mit dem er sich auf der nächsten Ebene verbinden wird. Alternativ dazu bestimmen in anderen Ausführungsformen der erste Rechenknoten 640 oder der dritte Rechenknoten 646 jeweils für mehr als eine oder alle Ebenen "a"–"n" die Zwischenknoten 632, mittels der der Client-Agent 128 geroutet werden wird.
  • Ist die erste Protokoll-Verbindung 135a zwischen dem Client-Agent 128 des Clients 108 und dem Zwischenknoten 632, z. B. dem Zwischenknoten 132 auf der Ebene "n" (hiernach wird im Verfahren 700 als Zwischenknoten 632 darauf Bezug genommen), errichtet worden, dann sendet der Client-Agent 128 das anfängliche Verbindung-Ticket an den Zwischenknoten 632.
  • Es wird dann im Schritt 728 bestimmt, ob das anfängliche Verbindung-Ticket gültig ist. In einer Ausführungsform sendet der Zwischenknoten 632 das anfängliche Verbindung-Ticket für die Validierung an die Ticket-Autorität 136. In einer Ausführungsform bestimmt die Ticket-Autorität 136 die Gültigkeit des anfänglichen Verbindung-Tickets, indem sie es mit der Kopie des anfänglichen Verbindung-Tickets vergleicht, das er im Schritt 720 aufbewahrt. Wenn die Ticket-Autorität 136 bestimmt, dass das anfängliche Verbindung-Ticket gültig ist, sendet die Ticket-Autorität 136 im Schritt 732 die Adresse des ersten Protokoll-Dienstes 112 und die Adresse des gewählten Host-Dienstes 116 an den Zwischenknoten 632. Die Ticket-Autorität 136 kann auch zusätzliche Verbindung-Tickets für den ersten Protokoll-Dienst 112 und Zwischenknoten 632 senden, mittels der sich der Client 108 mit dem Host-Dienst 116 verbinden wird. Der erste Protokoll-Dienst 112 kann auch das anfängliche Verbindung-Ticket und seine Kopie löschen. Wenn die Ticket-Autorität 136 anderenfalls bestimmt, dass das anfängliche Verbindung-Ticket ungültig ist, verweigerte der Client 108 im Schritt 730 die Verbindung mit dem ersten Protokoll-Dienst 112 und demnach die Verbindung mit dem Host-Dienst 116.
  • Im Anschluss an den Schritt 732 verwendet der Zwischenknoten 632 die Adresse des gewählten ersten Protokoll-Dienstes 112, um im Schritt 736 eine erste Protokoll-Verbindung 135b zwischen dem Zwischenknoten 632 und dem ersten Protokoll-Dienst 112 zu errichten. In einer Ausführungsform verwendet der Zwischenknoten 632 ein anfängliches Verbindung-Ticket, um die erste Protokoll-Verbindung 135b zwischen dem Zwischenknoten 632 und dem ersten Protokoll-Dienst 112 zu errichten. In einem Fall verwendet der Zwischenknoten 632 das vom Client 108 empfangene anfängliche Verbindung-Ticket, um die Verbindung 135b zu validieren. In einem anderen Fall verwendet der Zwischenknoten 632 ein anfängliches Verbindung-Ticket, das für die erste Protokoll-Verbindung 135b erzeugt wird und gültig ist. Es besteht daher jetzt eine erste Protokoll-Verbindung 135 zwischen dem Client-Agent 128 des Clients 108 und dem ersten Protokoll-Dienst 112 mittels des Zwischenknotens 632. Der Zwischenknoten 632 kann auch die Adresse des gewählten Host-Dienstes 116 an den ersten Protokoll-Dienst 112 leiten.
  • In einer Ausführungsform verwendet der erste Protokoll-Dienst 112 im Schritt 740 die Adresse des gewählten Host-Dienstes 116, um eine sekundäre Protokoll-Verbindung 124 zwischen dem ersten Protokoll-Dienst 112 und dem gewählten Host-Dienst 116 zu errichten. Zum Beispiel ist der gewählte Host-Dienst 116 tatsächlich der Host-Dienst 116a, und eine sekundäre Protokoll-Verbindung 124a zwischen dem ersten Protokoll-Dienst 112 und dem Host-Dienst 116a wird errichtet.
  • In einer Ausführungsform wählt der Anwender im Anschluss an den Schritt 740 im Schritt 744 eine zweite auszuführende Applikation, und der zweite Rechenknoten 644 bestimmt im Schritt 748 den Host-Dienst 116, an dem die zweite Applikation ausgeführt werden soll. Durch das Berechnen einer Lastausgleichsgleichung kann der zweite Rechenknoten 644 z. B. den Host-Dienst 116b wählen, der das zweite Applikationsprogramm ausführen soll. Der zweite Rechenknoten 644 sendet dann die Adresse des gewählten Host-Dienstes 116b an den ersten Protokoll-Dienst 112. In einer Ausführungsform befindet sich der zweite Rechenknoten 644 in einer direkten Kommunikation mit dem ersten Protokoll-Dienst 112 und sendet direkt die Adresse dahin. In einer anderen Ausführungsform wird die Adresse des gewählten Host-Dienstes 116b indirekt an den ersten Protokoll-Dienst 112 übertragen. Zum Beispiel kann die Adresse mittels irgendeiner Kombination aus dem ersten Rechenknoten 640, der Ticket-Autorität 136, dem Zwischenknoten 632 und dem ersten Protokoll-Dienst 112 an den ersten Protokoll-Dienst 112 gesandt werden. Hat der erste Protokoll-Dienst 112 die Adresse des gewählten Host-Dienstes 116b empfangen, errichtet er im Schritt 752 eine sekundäre Protokoll-Verbindung 125b zwischen dem ersten Protokoll-Dienst 112 und dem gewählten Host-Dienst 116b. Beim Errichten einer sekundären Protokoll-Verbindung 124b kann der erste Protokoll-Dienst 112 ein anfängliches Verbindung-Ticket validieren, um die Verbindung mit dem Host-Dienst 116 zu authentifizieren. Das anfängliche Verbindung-Ticket kann dasselbe sein wie das anfängliche Verbindung-Ticket, und zwar entweder für die Verbindung des Clients 108 mit dem Zwischenknoten 632 oder für die Verbindung des Zwischenknotens 632 mit dem ersten Protokoll-Dienst 112. In einer anderen Ausführungsform erzeugte die Ticket-Autorität 136 oder irgendein Zwischenknoten 632 ein Ticket, das nur für die sekundäre Protokoll-Verbindung 124b gültig ist. Der erste Protokoll-Dienst 112 und/oder Host-Dienst 116 verwendet dieses Ticket, um die sekundäre Protokoll-Verbindung 124b zu validieren.
  • Die sekundären Protokolle, die verwendet werden können, um über die Verbindungen 124a und 124b zu kommunizieren, schließen, ohne darauf eingeschränkt zu sein, HTTP, FTP, Oscar, Telnet, ICA und RDP ein. Außerdem schließt in einer Ausführungsform mindestens eines der sekundären Protokolle, wie oben beschrieben, mehrere virtuelle Kanäle ein, von denen jeder mehrere Protokollpakete einschließen kann, die die Funktion am entfernten Client 108 erlauben. In einer Ausführungsform ist z. B. ein Host-Dienst 116a ein Web-Server, der über die Verbindung 124a mittels Verwendung des HTTP-Protokolls mit dem ersten Protokoll-Dienst 112 kommuniziert, und ein weiterer Host-Dienst 116b ist ein Applikationsserver, der über die Verbindung 124b mittels Verwendung des ICA-Protokolls mit dem ersten Protokoll-Dienst 112 kommuniziert. Der Host-Dienst 116b erzeugt sowohl Protokollpakete, um Bildschirmbefehle an den Client 108 zu senden, damit der Client 108 eine graphische Anwender-Schnittstelle anzeigt, als auch Protokollpakete, um Druckerbefehle an den Client 108 zu senden, damit am Client 108 das Drucken eines Dokuments veranlasst wird.
  • Die Schritte 744, 748 und 752 können viele Male wiederholt werden. Somit kann irgendeine Anzahl an Applikationsprogrammen an irgendeiner Anzahl an Host-Diensten 116a–116n ausgeführt werden, deren Ausgaben über die Verbindungen 124a–124n mittels Verwendung irgendeiner Anzahl an sekundären Protokollen dem ersten Protokoll-Dienst 112 mitgeteilt werden können.
  • Auf den Schritt 756 zurückkehrend, kann der erste Protokoll-Dienst 112, wie oben beschrieben, mehrere sekundäre Protokolle innerhalb des ersten Protokolls einschließen. Somit wird der Client 108 mit mehreren Host-Diensten 116 verbunden und kommuniziert gleichzeitig damit.
  • In einer anderen Ausführungsform beendet ein Anwender des Clients 108 vor der Durchführung der Schritte 744, 748 und 752 zum Durchführen eines neuen Applikationsprogramms an einem Host-Dienst 116 wie beispielsweise dem Host-Dienst 116b die Ausführung eines anderen Applikationsprogramms wie beispielsweise eines Applikationsprogramms, das am Host-Dienst 116a ausführt. In einem solchen Fall unterbricht der erste Protokoll-Dienst 112 die Verbindung 124a zwischen dem ersten Protokoll-Dienst 112 und dem Host-Dienst 116a. Der erste Protokoll-Dienst 112 errichtet dann mittels der Implementierung der Schritte 744, 748 und 752 die Verbindung 124b zwischen dem ersten Protokoll-Dienst 112 und dem Host-Dienst 116b, ohne die Verbindung 135 zwischen dem Client 108 und dem ersten Protokoll-Dienst 112 zu unterbrechen.
  • In einer Ausführungsform wird im Schritt 760 ein erstes Wieder-Verbindung-Ticket erzeugt. Zum Beispiel verlangt der Zwischenknoten 632 ein erstes Wieder-Verbindung-Ticket von der Ticket-Autorität 136 oder verlangt ein erstes Wieder-Verbindung- Ticket für jedes der "Hops" zwischen dem Client 108 und dem Host-Dienst 116. Beim Empfangen der Anfrage erzeugt die Ticket-Autorität 136 das eine oder die mehreren ersten Wieder-Verbindung-Tickets. Ein Wieder-Verbindung-Ticket ist z. B. eine große Zufallszahl und kann auch ein Handle erzeugen, das z. B. eine kleinere Zufallszahl ist. Die Ticket-Autorität 136 kann dann im Schritt 764 die ersten Wieder-Verbindung-Tickets und Handles an den Zwischenknoten 632 senden, während eine Kopie der ersten Wieder-Verbindung-Tickets und eine Kopie der Handles aufbewahrt wird. Die Ticket-Autorität 136 hält weiterhin die Adresse des ersten Protokoll-Dienstes 112, die im Schritt 720 vom ersten Rechenknoten 640 dahingesandt wurde. Der Zwischenknoten 632 sendet dann im Schritt 768 das erste Wieder-Verbindung-Ticket des Clients an den Client 108.
  • Im Schritt 772 werden dann ein oder mehrere zweite Wieder-Verbindung-Tickets erzeugt. In einer Ausführungsform erzeugt der erste Protokoll-Dienst 112 das zweite Wieder-Verbindung-Ticket für den Client 108, das z. B. eine große Zufallszahl sein kann. In einer anderen Ausführungsform erzeugt der erste Protokoll-Dienst 112 zweite Wieder-Verbindung-Tickets für ein oder mehrere "Hops" zwischen dem Client 108 und dem Host-Dienst 116. Der erste Protokoll-Dienst 112 sendet dann im Schritt 776 das zweite Wieder-Verbindung-Ticket des Clients durch den Zwischenknoten 632 an den Client 108. Dadurch bewahrt der erste Protokoll-Dienst 112 eine Kopie des zweiten Wieder-Verbindung-Tickets und eine dazugehörige Sitzungsnummer, um die wiederherzustellende Sitzung im Anschluss an einer Unterbrechung der Verbindung 135 zu identifizieren. In einer Ausführungsform behält z. B. der erste Protokoll-Dienst 112 für eine besondere Sitzungsnummer eine Tabelle, die die sekundären Protokoll-Verbindungen 124a–124n auflistet, die zu dieser Sitzungsnummer gehören. Auf gleiche Weise kann der Protokoll-Dienst 112 die ersten und/oder zweiten Wieder-Verbindung-Tickets für die jeweiligen "Hops" behalten, die validiert wurden, um den Client 108 neuerlich mit dem Host-Dienst 116 zu verbinden.
  • Im Anschluss an die Wiederaufstellung der ersten Protokoll-Verbindung 135 und der Validierung des zweiten Wieder- Verbindung-Tickets am ersten Protokoll-Dienst 112 und/oder an jedem darauffolgenden ersten Protokoll-Dienst 112 und/oder Zwischenknoten 632 kann der erste Protokoll-Dienst 112 entsprechend die innerhalb der wiederhergestellten ersten Protokoll-Verbindung 135 eingeschlossenen sekundären Protokoll-Verbindungen 124 zur Kommunikation an den Client 108 identifizieren. Alternativ schießt das System 100 der vorliegenden Erfindung in einer anderen Ausführungsform und wiederum mit Bezug auf 1A nicht den/die Zwischenknoten 132, die Ticket-Autorität 136, noch den dritten Rechenknoten 646 ein. In einer solchen Ausführungsform stellen das System 100 und das Verfahren 700, anstelle der Erzeugung und Sendung sowohl des ersten als auch zweiten Wieder-Verbindung-Tickets, lieber nur ein einziges Wieder-Verbindung-Ticket für den Client 108 oder für einen oder mehrere der "Hops" zwischen dem Client 108 und dem Host-Dienst 116 bereit. In einer solchen Ausführungsform erzeugt der erste Protokoll-Dienst 112 z. B. das einzige Wieder-Verbindung-Ticket, das z. B. eine große Zufallszahl sein kann. Der erste Protokoll-Dienst 112 sendet dann das Wieder-Verbindung-Ticket des Clients über die Verbindung 135 direkt an den Client 108. Dadurch behält der erste Protokoll-Dienst 112 eine Kopie des einzigen Wieder-Verbindung-Tickets und eine dazugehörige Sitzungsnummer zur Identifizierung der Sitzung, die im Anschluss an eine Unterbrechung der Verbindung 135 wieder-verbunden werden soll. In einer anderen Ausführungsform bewahrt der erste Protokoll-Dienst 112 das Wieder-Verbindung-Ticket für seine Verbindung mit dem Host-Dienst 116 und eine dazugehörige Sitzungsnummer zum Wiedergewinnen des Wieder-Verbindung-Tickets.
  • Nimmt man jetzt auf 9 Bezug, wird eine Ausführungsform eines Verfahrens 800 dargestellt, um einem Client 108 eine zuverlässige Verbindung zu einem oder mehreren Host-Diensten 116 bereitzustellen und um den Client 108 mittels Verwendung der beispielhaften Ausführungsform der 6A–6D mit den Host-Diensten 116 (z. B. im Schritt 616 der 7) wieder zu verbinden. Genauer wird im Schritt 804 die sekundäre Protokoll-Verbindung 124 zwischen dem ersten Protokoll-Dienst 112 und jedem der einen oder mehreren Host-Dienste 116 bewahrt. Außerdem wird im Schritt 808 eine Warteschlange an Datenpaketen, die als letztes über die Verbindung 135, die als unterbrochen bestimmt wurde, zwischen dem Client-Agent 128 des Clients 108 und dem ersten Protokoll-Dienst 112 übertragen wurden, aufrechterhalten. In einer Ausführungsform werden die Datenpakete in eine Warteschlange gesetzt und sowohl vor dem als auch beim Ausfall der Verbindung 135 bewahrt. Die in Warteschlange gesetzten Datenpakete werden z. B. durch den Client-Agent 128 in einem Puffer aufbewahrt. Alternativ kann der erste Protokoll-Dienst 112 die in Warteschlange gesetzten Datenpakete in einem Puffer aufbewahren. In noch einer anderen Ausführungsform bewahren sowohl der Client-Agent 128 als auch der erste Protokoll-Dienst 112 die in Warteschlange gesetzten Datenpakete in einem Puffer.
  • Im Schritt 812 wird zwischen dem Client-Agent 128 des Clients 108 und dem ersten Protokoll-Dienst 112 eine neue erste Protokoll-Verbindung 135 errichtet und mit der aufrechterhaltenen sekundären Protokoll-Verbindung 124 zwischen dem ersten Protokoll-Dienst 112 und jedem der einen oder mehreren Host-Dienste 116 verbunden, wodurch der Client 108 neuerlich mit den Host-Diensten 116 verbunden wird. Nachdem der Client wiederverbunden ist, können die im Schritt 808 aufbewahrten, in Warteschlange gesetzten Datenpakete im Schritt 816 über die neu errichtete erste Protokoll-Verbindung 135 übertragen werden. Somit ist die Kommunikationssitzung zwischen den Host-Diensten 116 und dem Client 108 mittels des ersten Protokoll-Dienstes 112 anhaltend und verläuft ohne Datenverlust.
  • In einer Ausführungsform mit mehreren "Hops", die mehrere erste Protokoll-Dienste 112 durchlaufen, können im Schritt 808 ein Teil der oder alle Datenpakete an einem oder mehreren der ersten Protokoll-Dienste 112 aufbewahrt werden. Im Schritt 812 kann jeder "Hop" wiederhergestellt werden. Nachdem der Client 108, wie oben beschrieben, mit dem ersten der einen oder mehreren Protokoll-Dienste 112 wieder-verbunden und wiederangeschlossen ist, kann jede der übrigen Verbindungen neuerlich mit dem zuvor wieder-verbundenen "Hop" errichtet und verbunden werden, bis der letzte "Hop" zum Host-Dienst 116 wiederhergestellt ist. Sowohl nachdem der letzte "Hop" wiederhergestellt und wieder-verbunden wird, als auch wenn jeder "Hop" wiederhergestellt und wieder-verbunden wird, können die im Schritt 808 bewahrten in Warteschlange gesetzten Datenpakete im Schritt 816 übertragen werden.
  • Nimmt man jetzt auf die 10A–10B Bezug, wird eine Ausführungsform eines Verfahrens 900 dargestellt, um mittels Verwendung der beispielhaften Ausführungsform der 6A–6D den Client 108 mit dem einen oder den mehreren Host-Diensten 116 (z. B. im Schritt 812 der 9) wieder zu verbinden. Im Schritt 904 werden irgendwelche verbliebenen Verbindungen zwischen dem Client 108 und dem ersten Protokoll-Dienst 112 unterbrochen. Wenn z. B. die Verbindung 135a ausgefallen ist, jedoch die Verbindung 135b nicht, wird die Verbindung 135b unterbrochen. Alternativ wird die Verbindung 135a unterbrochen, wenn die Verbindung 135b ausgefallen ist, jedoch die Verbindung 135a nicht.
  • In einer Ausführungsform stellt der Client-Agent 128 des Clients 108 mittels Verwendung der dem Client 108 beispielsweise m Schritt 720 der 8 bereitgestellten tatsächlichen Adresse des Zwischenknotens 632 im Schritt 908 die erste Protokoll-Verbindung 135a zwischen dem Client-Agent 128 und dem Zwischenknoten 632 wieder her. Alternativ stellt der Client-Agent 128 des Clients 108 mittels Verwendung der dem Client beispielsweise im Schritt 720 der 8 bereitgestellten tatsächlichen Adresse des dritten Rechenknotens 646 eine erste Protokoll-Verbindung zwischen dem Client-Agent 128 und dem dritten Rechenknoten 646 wieder her. Der dritte Rechenknoten 646 bestimmt dann den Zwischenknoten 632, durch den Nachrichten zwischen dem Client 108 und dem ersten Protokoll-Dienst 112 gehen werden müssen. In einer Ausführungsform wählt der dritte Rechenknoten 646 mittels Verwendung einer Lastausgleichsgleichung den Zwischenknoten 632. Der beim Wieder-Verbinden des Clients mit einem oder mehreren Host-Diensten 116 vom dritten Rechenknoten 646 gewählte Zwischenknoten 632 kann sich von demjenigen unterscheiden, der beispielsweise im Schritt 720 der 8 gewählt wurde, um anfangs den Client 108 mit dem einen oder mehreren Host-Diensten 116 zu verbinden. In einer Ausführungsform wird ein anfängliches Verbindung-Ticket für den ausgewählten Zwischenknoten 632 erzeugt, wenn der Client 108 mit einem Host-Dienst 116 wieder-verbunden wird.
  • Ist der Zwischenknoten 632 einmal gewählt, stellt der dritte Rechenknoten 646 eine erste Protokoll-Verbindung 135a mit dem Zwischenknoten 632 wieder her. Eine erste Protokoll-Verbindung 135a wird daher mittels des dritten Rechenknotens 646 zwischen dem Client-Agent 128 des Clients 108 und dem Zwischenknoten 632 wiederhergestellt. In einer Ausführungsform wird, wenn die erste Protokoll-Verbindung 135a mit dem Zwischenknoten 632 wiederhergestellt wird, die erste Protokoll-Verbindung 135s validiert, indem mit der Ticket-Autorität 136 ein erstes oder zweites Wieder-Verbindung-Ticket für diesen "Hop" validiert wird.
  • In einer Ausführungsform, in der es mehr als eine Ebene an Zwischenknoten 632 gibt, bestimmt der Zwischenknoten 632, mittels dem der Client-Agent 128 auf jeder Ebene "a"–"n – 1" geroutet wird, danach beispielsweise auf der Grundlage einer Lastausgleichsgleichung den Zwischenknoten 632, mit dem er sich auf der nächsten Ebene verbinden wird. Alternativ bestimmt der dritte Rechenknoten 646 in einer anderen Ausführungsform für mehr als eine oder für alle Ebenen "a"–"n" die Zwischenknoten 632, durch die der Client-Agent 128 geroutet werden wird. In anderen Ausführungsformen erzeugt entweder der Zwischenknoten 632 oder einer der Rechenknoten (z. B. der dritte Rechenknoten 646) ein erstes oder zweites Wieder-Verbindung-Ticket für eine oder mehrere Verbindungen oder "Hops", durch die der Client-Agent 128 geroutet wird.
  • Ist die erste Protokoll-Verbindung 135a zwischen dem Client-Agent 128 des Clients 108 und dem Zwischenknoten 632, z. B. dem Zwischenknoten 132 auf der Ebene "n" (hiernach wird im Verfahren 900 als Zwischenknoten 632 darauf Bezug genommen), einmal wiederhergestellt worden, dann sendet der Client-Agent 128 im Schritt 912 das erste Wieder-Verbindung-Ticket und das zweite Wieder-Verbindung-Ticket für den Client 108 an den Zwischenknoten 632.
  • Es wird dann im Schritt 916 bestimmt, ob das erste Wieder- Verbindung-Ticket gültig ist. In einer Ausführungsform wird die Gültigkeit des ersten Wieder-Verbindung-Tickets mittels Verwendung der Ticket-Autorität 136 bestimmt. Zum Beispiel sendet der Zwischenknoten 632 das erste Wieder-Verbindung-Ticket an die Ticket-Autorität 136. In einer Ausführungsform bestimmt die Ticket-Autorität 136 die Gültigkeit des ersten Wieder-Verbindung-Tickets, indem sie es mit einer zuvor aufbewahrten Kopie des ersten Wieder-Verbindung-Tickets vergleicht. Wenn die Ticket-Autorität 136 bestimmt, dass das erste Wieder-Verbindung-Ticket gültig ist, sendet die Ticket-Autorität 136 im Schritt 920 die Adresse des ersten Protokoll-Dienstes 112 an den Zwischenknoten 632. Wenn die Ticket-Autorität 136 anderenfalls bestimmt, dass das erste Wieder-Verbindung-Ticket ungültig ist, lehnt der Client 108 im Schritt 924 die Wiederverbindung mit dem ersten Protokoll-Dienst 112 und demnach die Wiederverbindung mit den Host-Diensten 116 ab.
  • Im Schritt 928 wird das erste Wieder-Verbindung-Ticket z. B. durch die Ticket-Autorität 136 gelöscht und z. B. durch die Ticket-Autorität 136 ein erstes Ersetzungs-Wieder-Verbindung-Ticket erzeugt. Außerdem kann beispielsweise durch die Ticket-Autorität 136 ein Ersetzungs-Handle erzeugt werden. In einigen dieser Ausführungsformen sendet die Ticket-Autorität 136 das erste Ersetzungs-Wieder-Verbindung-Ticket und das Ersetzungs-Handle an den Zwischenknoten 632. Überdies behält die Ticket-Autorität 136 in einigen dieser Ausführungsformen eine Kopie des ersten Ersetzungs-Wieder-Verbindung-Tickets. In einigen Ausführungsformen wartet die Ticket-Autorität 136 auf den Client 108, um zu bestätigen, das erste Ersetzungs-Wieder-Verbindung-Ticket erhalten zu haben, bevor es fortfährt, das erste Wieder-Verbindung-Ticket zu löschen.
  • Nachdem das erste Wieder-Verbindung-Ticket validiert ist, stellt der Zwischenknoten 632 mittels Verwendung der Adresse des ersten Protokoll-Dienstes 112 im Schritt 932 die erste Protokoll-Verbindung 135b zwischen dem Zwischenknoten 632 und dem ersten Protokoll-Dienst 112 wieder her. Ist die erste Protokoll-Verbindung 135b zwischen dem Zwischenknoten 632 und dem ersten Protokoll-Dienst 112 wiederhergestellt worden, wird dann im Schritt 936 bestimmt, ob das zweite Wieder-Verbindung-Ticket gültig ist. In einer Ausführungsform wird die Gültigkeit des zweiten Wieder-Verbindung-Tickets mittels Verwendung des ersten Protokoll-Dienstes 112 bestimmt. Zum Beispiel sendet der Zwischenknoten 632 das zweite Wieder-Verbindung-Ticket an den ersten Protokoll-Dienst 112. In einer Ausführungsform bestimmt der erste Protokoll-Dienst 112 die Gültigkeit des zweiten Wieder-Verbindung-Tickets, indem er es mit einer zuvor bewahrten Kopie des zweiten Wieder-Verbindung-Tickets vergleicht. In einer anderen Ausführungsform des Schritts 936 setzt der erste Protokoll-Dienst 112 ein erstes Wieder-Verbindung-Ticket für die Verbindung zwischen dem ersten Protokoll-Dienst 112 und dem Host-Dienst 116 oder in einer anderen Ausführungsform zwischen dem ersten Protokoll-Dienst 112 und einem anderen ersten Protokoll-Dienst 112 bzw. Zwischenknoten 632 gültig. Auf ähnliche Weise kann jeder "Hop" hiernach zwischen dem ersten Protokoll-Dienst 112 und dem Host-Dienst 116 mit einem oder mehreren Tickets, entweder anfänglichen oder Wieder-Verbindungs-Tickets, validiert werden, um den anhaltenden Gebrauch des "Hops" im Namen des Clients 108 zu validieren.
  • Wenn der erste Protokoll-Dienst 112 bestimmt, dass das zweite Wieder-Verbindung-Ticket gültig ist, wird die wiederhergestellte erste Protokoll-Verbindung 135b zwischen dem ersten Zwischenknoten 132 und dem ersten Protokoll-Dienst 112 im Schritt 940 mit der aufrechterhaltenen sekundären Protokoll-Verbindung 124 zwischen dem ersten Protokoll-Dienst 112 und jedem der einen oder mehreren Host-Dienste 116 verbunden. Wenn der erste Protokoll-Dienst 112 anderenfalls bestimmt, dass das zweite Wieder-Verbindung-Ticket ungültig ist, wird die wiederhergestellte erste Protokoll-Verbindung 135b nicht mit der einen oder den mehreren aufrechterhaltenen sekundären Protokoll-Verbindungen 124 verbunden, und dem Client 108 wird im Schritt 944 die Wieder-Verbindung mit dem einen oder den mehreren Host-Diensten 116 verweigert. Im Falle einer Mehrfach-Hop-Verbindung zwischen dem ersten Protokoll-Dienst 112 und dem Host-Dienst 116 kann jeder "Hop" für die Wieder-Verbindung validiert werden und im Schritt 940 mit dem vorherigen "Hop" verbunden werden, bis der letzte "Hop" zum Host-Dienst 116 validiert wird oder bis einem der "Hops" die Wieder-Verbindung verweigert wird.
  • Im Schritt 948 wird das zweite Wieder-Verbindung-Ticket z. B. durch den ersten Protokoll-Dienst 112 gelöscht und ein zweites Ersetzungs-Wieder-Verbindung-Ticket z. B. durch den ersten Protokoll-Dienst 112 erzeugt, um an den Client 108 gesandt zu werden. In einer solchen Ausführungsform bewahrt der erste Protokoll-Dienst 112 eine Kopie des zweiten Ersetzungs-Wieder-Verbindung-Tickets. In einigen Ausführungsformen wartet der erste Protokoll-Dienst 112 darauf 108, dass der Client bestätigt, das zweite Ersetzungs-Wieder-Verbindung-Ticket empfangen zu haben, bevor es damit fortfährt, das zweite Wieder-Verbindung-Ticket zu löschen. Im Falle des Validierens von einem oder mehreren "Hops" für die Wieder-Verbindung eines Clients 108 können im Schritt 948 ein oder mehrere Ersetzungs-Wieder-Verbindung-Tickets erzeugt und/oder ein Kopie durch die Ticket-Autorität 136, die Zwischenknoten 632, irgendeinen der Rechenknoten oder einen oder mehreren der ersten Protokoll-Dienste 112 gesichert werden.
  • Im Schritt 952 werden das erste Ersetzungs-Wiederverbindungsticket und das zweite Ersetzungs-Wiederverbindung-Ticket an den Client gesandt. Die Ticket-Autorität 136 kann z. B. das erste Wieder-Verbindung-Ticket mittels des Zwischenknotens 632 an den Client 108 übertragen. Überdies sendet der erste Protokoll-Dienst 112 in einer Ausführungsform das zweite Ersetzungs-Wieder-Verbindung-Ticket an den Client 108. In anderen Ausführungsformen können die Ersetzungs-Wieder-Verbindung-Tickets für ein oder mehrere "Hops" an einen oder mehrere Zwischenknoten 632, irgendeinen Rechenknoten oder einen oder mehrere erste Protokoll-Dienste 112 gesendet werden.
  • Alternativ können, wie oben erörtert, das System 100 und die Verfahren der Erfindung in anderen Ausführungsformen nur ein einziges Wieder-Verbindung-Ticket für den Client 108 und/oder eine einzige Wieder-Verbindung für den jeweiligen "Hop" zwischen dem Client 108 und einem Host-Dienst 116 bereitstellen. Lieber als sowohl das erste als auch zweite Wieder-Verbindung-Ticket zu verwenden, verwendet somit das darstellende Verfahren 900 nur das zuvor erwähnte einzige Wieder-Verbindung-Ticket. In einer solchen Ausführungsform wird dem Client-Agent 128 des Clients 108 die Adresse des ersten Protokoll-Dienstes 112 zur Verfügung gestellt. Um die Host-Dienste 116 neuerlich zu verbinden, sendet der Client-Agent 128 das einzige Wieder-Verbindung-Ticket direkt an den ersten Protokoll-Dienst 112. Der erste Protokoll-Dienst 112 bestimmt dann, ob das einzige Wieder-Verbindung-Ticket gültig ist. In einer Ausführungsform bestimmt der erste Protokoll-Dienst 112 die Gültigkeit des einzigen Wieder-Verbindung-Tickets, indem er es mit einer zuvor aufbewahrten Kopie des einzigen Wieder-Verbindung-Tickets vergleicht. Wenn der erste Protokoll-Dienst 112 bestimmt, dass das einzige Wieder-Verbindung-Ticket gültig ist, wird die wiederhergestellte erste Protokoll-Verbindung 135 zwischen dem Client 108 und dem ersten Protokoll-Dienst 112 mit der aufrechterhaltenen sekundären Protokoll-Verbindung 124 zwischen dem ersten Protokoll-Dienst 112 und jedem der einen oder mehreren Host-Dienste 116 verbunden. Wenn der erste Protokoll-Dienst 112 anderenfalls bestimmt, dass das einzige Wieder-Verbindung-Ticket ungültig ist, wird die wiederhergestellte erste Protokoll-Verbindung 135 nicht mit der einen oder den mehreren aufrechterhaltenen sekundären Protokoll-Verbindungen 124 verbunden, und dem Client 108 wird die Wieder-Verbindung mit einem oder mehreren Host-Diensten 116 verweigert.
  • Nachdem das einzige Wieder-Verbindung-Ticket validiert ist, wird das einzige Wieder-Verbindung-Ticket z. B. durch den ersten Protokoll-Dienst 112 gelöscht, und beispielsweise durch den ersten Protokoll-Dienst 112 wird ein einziges Ersetzungs-Wieder-Verbindung-Ticket für die Übertragung an den Client 108 erzeugt. Beim Senden des einzigen Ersetzungs-Wieder-Verbindung-Tickets an den Client 108 bewahrt der erste Protokoll-Dienst 112 eine Kopie des einzigen Ersetzungs-Wieder-Verbindung-Tickets auf. In einigen Ausführungsformen wartet der erste Protokoll-Dienst 112 auf die Bestätigung des Clients 108, das einzige Ersetzungs-Wieder-Verbindung-Ticket empfangen zu haben, bevor er fortfährt, das einzige Wieder-Verbindung-Ticket zu löschen.
  • In noch einer anderen Ausführungsform ist das einzige Wieder-Verbindung-Ticket wie das erste und das zweite Wieder- Verbindung-Ticket für das automatische Löschen nach einer vorbestimmten Zeitspanne im Anschluss an einen Ausfall in der Verbindung 135, wie im Schritt 612, und/oder im Anschluss an eine einwandfreie Beendigung der Verbindung 135, wie im Schritt 620, aufgebaut.
  • Viele Änderungen und Modifikationen können von den Fachleuten auf dem Gebiet vorgenommen werden, ohne sich vom Geist und Schutzumfang der Erfindung zu lösen. Daher muss es ausdrücklich klar sein, dass die dargestellten Ausführungsformen nur als Beispielzwecke gezeigt wurden und nicht genommen werden sollten, als schränkten sie die Erfindung ein, die durch die folgenden Ansprüche definiert wird. Diese Ansprüche sollen gelesen werden, als schlössen sie alles ein, was wörtlich geschildert wurde, und als schlössen sie auch jene äquivalenten Elemente ein, die nur unwesentlich anders sind, selbst wenn sie in Bezug auf dasjenige, das in den obigen Darstellungen gezeigt und beschrieben wurde, nicht identisch sind.

Claims (35)

  1. Ein Verfahren, um einen Client (108) wieder mit einem Host-Dienst (116a–116n) zu verbinden, wobei das Verfahren gekennzeichnet ist durch: das Bereitstellen einer Kommunikationssitzung zwischen einem Client (108) und einem Host-Dienst (116a–116n) über eine erste Verbindung zwischen dem Client (108) und einem ersten Protokoll-Dienst (112) und eine zweite Verbindung zwischen dem ersten Protokoll-Dienst (112) und dem Host-Dienst (116a–116n); das Erfassen einer Unterbrechung in einer der ersten Verbindung oder der zweiten Verbindung, und das Aufrechterhalten der anderen der ersten oder der zweiten Verbindung; das Erhalten eines ersten Tickets und eines zweiten Tickets am ersten Protokoll-Dienst (112); das Validieren des ersten Tickets, um die unterbrochene Verbindung wiederherzustellen; das Validieren des zweiten Tickets, um mit der Verwendung der aufrechterhaltenen Verbindung fortzufahren; und das Verbinden der wiederhergestellten Verbindung mit der aufrechterhaltenen Verbindung.
  2. Das Verfahren nach Anspruch 1, das weiterhin das Aufrechterhalten der Kommunikationssitzung während der Unterbrechung in der unterbrochenen Verbindung umfasst.
  3. Das Verfahren nach Anspruch 1, das weiterhin das Erzeugen eines des ersten Tickets oder des zweiten Tickets durch zumindest einen bzw. eine des ersten Protokoll-Dienstes (112) oder einer ersten Ticket-Autorität (136) umfasst.
  4. Das Verfahren nach Anspruch 1, das weiterhin das Validieren von zumindest einem des ersten Tickets oder des zweiten Tickets durch die Ticket-Autorität (136) umfasst.
  5. Das Verfahren nach Anspruch 1, das weiterhin die Authentifizierung des Clients (108) an einen Web-Server (120) umfasst.
  6. Das Verfahren nach Anspruch 1, das weiterhin das Übertragen des ersten Tickets an den Client (108) durch einen Web-Server (120) umfasst.
  7. Das Verfahren nach Anspruch 1, das weiterhin das Senden des ersten Tickets an den ersten Protokoll-Dienst (112) durch den Client (108) umfasst.
  8. Das Verfahren nach Anspruch 1, das beim Errichten der Kommunikationssitzung weiterhin die Authentifizierung des Clients (108) durch den Host-Dienst (116a–116n) umfasst.
  9. Das Verfahren nach Anspruch 1, worin der erste Protokoll-Dienst (112) einen Proxy-Server umfasst.
  10. Das Verfahren nach Anspruch 1, worin der erste Protokoll-Dienst (112) ein Sicherheits-Gateway umfasst.
  11. Das Verfahren nach Anspruch 1, worin der Client (108) und der erste Protokoll-Dienst (112) mittels Verwendung eines ersten Protokolls (204), das ein zweites Protokoll (200a–200n) einkapselt, kommunizieren, und worin der erste Protokoll-Dienst (112) und der Host-Dienst (116a–116n) mittels Verwendung des zweiten Protokolls (200a–200n) kommunizieren.
  12. Das Verfahren nach Anspruch 1, worin das erste Ticket für die erste Verbindung ist und das zweite Ticket für die zweite Verbindung gültig ist.
  13. Das Verfahren nach Anspruch 1, worin das zweite Ticket deaktiviert wird, bis das erste Ticket validiert wird.
  14. Das Verfahren nach Anspruch 1, worin die wiederhergestellte Verbindung mit der aufrechterhaltenen Verbindung verbun den wird, nachdem das erste Ticket und das zweite Ticket validiert werden.
  15. Das Verfahren nach Anspruch 1, worin eine der ersten Verbindung und der zweiten Verbindung eine Vielzahl von Verbindungen umfasst, die über einen eines Zwischenknotens oder einen oder mehreren ersten Protokoll-(204)-Diensten verbunden sind.
  16. Das Verfahren nach Anspruch 15, worin ein drittes Ticket für zumindest eine der Vielzahl von Verbindungen erzeugt wird.
  17. Das Verfahren nach Anspruch 16, worin das dritte Ticket für die zumindest eine der Vielzahl von Verbindungen gültig ist.
  18. Ein System, um einen Client (108) wieder mit einem Host-Dienst (116a–116n) zu verbinden, wobei das System gekennzeichnet ist durch: einen Client (108) mit Mitteln zum Errichten einer Kommunikationssitzung mit einem Host-Dienst (116a–116n) über eine erste Verbindung; einen ersten Protokoll-Dienst (112) mit Mitteln zum Errichten der ersten Verbindung mit dem Client (108) und einer zweiten Verbindung mit dem Host-Dienst (116a–116n); den ersten Protokoll-Dienst (112) mit Mitteln zum Aufrechterhalten einer Verbindung, die zumindest eine der ersten Verbindung oder der zweiten Verbindung umfasst; den ersten Protokoll-Dienst (112) mit Mitteln zum Validieren eines ersten Tickets zum Wiederherstellen einer unterbrochenen Verbindung in einer der ersten Verbindung und der zweiten Verbindung und mit Mitteln zum Validieren eines zweiten Tickets für die Verwendung der anderen aus der ersten Verbindung oder der zweiten Verbindung; und den ersten Protokoll-Dienst (112) mit Mitteln zum Verbinden der wiederhergestellten Verbindung mit der aufrechterhaltenen Verbindung.
  19. Das System nach Anspruch 18, das weiterhin eine Ticket-Autorität (136) mit Mitteln zum Erzeugen von zumindest einem des ersten Tickets oder des zweiten Tickets umfasst.
  20. Das System nach Anspruch 18, worin der erste Protokoll-Dienst (112) Mittel zum Aufrechterhalten der Kommunikationssitzung während einer Unterbrechung in der unterbrochenen Verbindung hat.
  21. Das System nach Anspruch 18, worin der erste Protokoll-Dienst (112) Mittel zum Erzeugen von zumindest einem des ersten Tickets oder des zweiten Tickets hat.
  22. Das System nach Anspruch 18, worin die Ticket-Autorität (136) Mittel zum Validieren von zumindest einem des ersten Tickets oder des zweiten Tickets hat.
  23. Das System nach Anspruch 18, das weiterhin einen Web-Server (120) umfasst, wobei der Web-Server (120) Mittel zum Authentifizieren des Clients (108) hat.
  24. Das System nach Anspruch 23, worin der Web-Server (120) Mittel zum Senden des ersten Tickets an den Client (108) hat.
  25. Das System nach Anspruch 18, worin der Client (108) Mittel zum Übertragen des ersten Tickets an den ersten Protokoll-Dienst (112) hat.
  26. Das System nach Anspruch 18, worin der Host-Dienst (116a–116n) Mittel hat, um den Client (108) bei der Errichtung der Kommunikationssitzung zu authentifizieren.
  27. Das System nach Anspruch 18, worin der erste Protokoll-Dienst (112) einen Proxy-Server umfasst.
  28. Das System nach Anspruch 18, worin der erste Protokoll-Dienst (112) ein Sicherheits-Gateway umfasst.
  29. Das System nach Anspruch 18, worin der Client (108) und der erste Protokoll-Dienst (112) Mittel zum Kommunizieren mittels eines ersten Protokolls (204) haben, das ein zweites Protokoll (200a–200n) einkapselt, und worin der erste Protokoll-Dienst (112) und der Host-Dienst (116a–116n) Mittel zum Kommunizieren mittels Verwendung des zweiten Protokolls (200a–200n) haben.
  30. Das System nach Anspruch 18, worin das erste Ticket für die erste Verbindung und das zweite Ticket für die zweite Verbindung gültig sind.
  31. Das System nach Anspruch 18, worin das zweite Ticket deaktiviert wird, bis das erste Ticket validiert wird.
  32. Das System nach Anspruch 18, worin der erste Protokoll-Dienst (112) die wiederhergestellte Verbindung mit der aufrechterhaltenen Verbindung verbindet, nachdem das erste Ticket und das zweite Ticket validiert werden.
  33. Das System nach Anspruch 18, worin eine der ersten Verbindung und der zweiten Verbindung eine Vielzahl von Verbindungen umfasst, die über einen eines Zwischenknotens oder einen oder mehreren Protokoll-(204)-Diensten verbunden sind.
  34. Das System nach Anspruch 33, worin ein drittes Ticket für zumindest eine der Vielzahl von Verbindungen erzeugt wird.
  35. Das System nach Anspruch 34, worin das dritte Ticket für zumindest eine der Vielzahl von Verbindungen gültig ist.
DE602004010703T 2003-10-10 2004-10-08 Eine persistente und zuverlässige sitzung, die neztwerkkomponenten unter verwendung eines verkapselungsprotokolls sicher durchläuft Expired - Lifetime DE602004010703T2 (de)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US711719 2000-11-13
US10/683,881 US7562146B2 (en) 2003-10-10 2003-10-10 Encapsulating protocol for session persistence and reliability
US683881 2003-10-10
US10/711,719 US7984157B2 (en) 2002-02-26 2004-09-30 Persistent and reliable session securely traversing network components using an encapsulating protocol
PCT/US2004/033334 WO2005036858A1 (en) 2003-10-10 2004-10-08 A persistent and reliable session securely traversing network components using an encapsulating protocol

Publications (2)

Publication Number Publication Date
DE602004010703D1 DE602004010703D1 (de) 2008-01-24
DE602004010703T2 true DE602004010703T2 (de) 2008-11-27

Family

ID=34437418

Family Applications (1)

Application Number Title Priority Date Filing Date
DE602004010703T Expired - Lifetime DE602004010703T2 (de) 2003-10-10 2004-10-08 Eine persistente und zuverlässige sitzung, die neztwerkkomponenten unter verwendung eines verkapselungsprotokolls sicher durchläuft

Country Status (10)

Country Link
US (1) US7984157B2 (de)
EP (1) EP1678918B1 (de)
JP (1) JP2007515852A (de)
KR (1) KR20060126952A (de)
AT (1) ATE381196T1 (de)
AU (1) AU2004306772A1 (de)
CA (1) CA2541151C (de)
DE (1) DE602004010703T2 (de)
ES (1) ES2298835T3 (de)
WO (1) WO2005036858A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102009051383A1 (de) * 2009-10-30 2011-05-12 Siemens Aktiengesellschaft Verfahren und Vorrichtung zum sicheren Übertragen von Daten

Families Citing this family (112)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6928469B1 (en) 1998-12-29 2005-08-09 Citrix Systems, Inc. Apparatus and method for determining a program neighborhood for a client node in a client-server network using markup language techniques
US7117239B1 (en) 2000-07-28 2006-10-03 Axeda Corporation Reporting the state of an apparatus to a remote computer
US8108543B2 (en) 2000-09-22 2012-01-31 Axeda Corporation Retrieving data from a server
US7185014B1 (en) 2000-09-22 2007-02-27 Axeda Corporation Retrieving data from a server
US20050198379A1 (en) 2001-06-13 2005-09-08 Citrix Systems, Inc. Automatically reconnecting a client across reliable and persistent communication sessions
US7254601B2 (en) 2001-12-20 2007-08-07 Questra Corporation Method and apparatus for managing intelligent assets in a distributed environment
US8135843B2 (en) * 2002-03-22 2012-03-13 Citrix Systems, Inc. Methods and systems for providing access to an application
US7178149B2 (en) 2002-04-17 2007-02-13 Axeda Corporation XML scripting of soap commands
JP3782981B2 (ja) * 2002-04-26 2006-06-07 インターナショナル・ビジネス・マシーンズ・コーポレーション セッション中継システム、クライアント端末、セッション中継方法、リモートアクセス方法、セッション中継プログラム及びクライアントプログラム
US7966418B2 (en) 2003-02-21 2011-06-21 Axeda Corporation Establishing a virtual tunnel between two computer programs
US7978716B2 (en) 2003-11-24 2011-07-12 Citrix Systems, Inc. Systems and methods for providing a VPN solution
US7715340B2 (en) * 2004-03-04 2010-05-11 At&T Corp. Method and apparatus for enabling IP mobility with high speed access and network intelligence in communication networks
US7757074B2 (en) 2004-06-30 2010-07-13 Citrix Application Networking, Llc System and method for establishing a virtual private network
US8739274B2 (en) 2004-06-30 2014-05-27 Citrix Systems, Inc. Method and device for performing integrated caching in a data communication network
US8495305B2 (en) 2004-06-30 2013-07-23 Citrix Systems, Inc. Method and device for performing caching of dynamically generated objects in a data communication network
US7808906B2 (en) 2004-07-23 2010-10-05 Citrix Systems, Inc. Systems and methods for communicating a lossy protocol via a lossless protocol using false acknowledgements
CN101199187A (zh) 2004-07-23 2008-06-11 茨特里克斯系统公司 用于网络节点之间通信最优化的系统和方法
WO2006020823A1 (en) 2004-08-13 2006-02-23 Citrix Systems, Inc. A method for maintaining transaction integrity across multiple remote access servers
EP1811397A4 (de) * 2004-10-12 2011-08-17 Fujitsu Ltd Programm, verfahren und einrichtung zur operationsverwaltung
US7810089B2 (en) 2004-12-30 2010-10-05 Citrix Systems, Inc. Systems and methods for automatic installation and execution of a client-side acceleration program
US8954595B2 (en) 2004-12-30 2015-02-10 Citrix Systems, Inc. Systems and methods for providing client-side accelerated access to remote applications via TCP buffering
US8700695B2 (en) 2004-12-30 2014-04-15 Citrix Systems, Inc. Systems and methods for providing client-side accelerated access to remote applications via TCP pooling
US8706877B2 (en) 2004-12-30 2014-04-22 Citrix Systems, Inc. Systems and methods for providing client-side dynamic redirection to bypass an intermediary
US8549149B2 (en) 2004-12-30 2013-10-01 Citrix Systems, Inc. Systems and methods for providing client-side accelerated access to remote applications via TCP multiplexing
US8255456B2 (en) 2005-12-30 2012-08-28 Citrix Systems, Inc. System and method for performing flash caching of dynamically generated objects in a data communication network
WO2006081032A2 (en) 2005-01-24 2006-08-03 Citrix Systems, Inc. Systems and methods for performing caching of dynamically generated objects in a network
US20080222604A1 (en) * 2005-03-07 2008-09-11 Network Engines, Inc. Methods and apparatus for life-cycle management
US20090089871A1 (en) * 2005-03-07 2009-04-02 Network Engines, Inc. Methods and apparatus for digital data processor instantiation
US8316129B2 (en) 2005-05-25 2012-11-20 Microsoft Corporation Data communication coordination with sequence numbers
US8943304B2 (en) 2006-08-03 2015-01-27 Citrix Systems, Inc. Systems and methods for using an HTTP-aware client agent
US9621666B2 (en) 2005-05-26 2017-04-11 Citrix Systems, Inc. Systems and methods for enhanced delta compression
US9407608B2 (en) 2005-05-26 2016-08-02 Citrix Systems, Inc. Systems and methods for enhanced client side policy
US9692725B2 (en) 2005-05-26 2017-06-27 Citrix Systems, Inc. Systems and methods for using an HTTP-aware client agent
US7921184B2 (en) 2005-12-30 2011-04-05 Citrix Systems, Inc. System and method for performing flash crowd caching of dynamically generated objects in a data communication network
US8301839B2 (en) 2005-12-30 2012-10-30 Citrix Systems, Inc. System and method for performing granular invalidation of cached dynamically generated objects in a data communication network
US7478182B2 (en) * 2006-01-31 2009-01-13 Schweig Marc E Keyboard, mouse, and video (KVM) session capture system that stores and can playback portions of live KVM session via forensic capture module
US8151323B2 (en) 2006-04-12 2012-04-03 Citrix Systems, Inc. Systems and methods for providing levels of access and action control via an SSL VPN appliance
US9270771B2 (en) * 2006-04-28 2016-02-23 Samsung Electronics Co., Ltd. System and method for performing a delegation operation
US20070288645A1 (en) * 2006-06-08 2007-12-13 International Business Machines Corporation Method and System for Persistent and Reliable Data Transmission
US8561155B2 (en) * 2006-08-03 2013-10-15 Citrix Systems, Inc. Systems and methods for using a client agent to manage HTTP authentication cookies
US7953889B2 (en) * 2006-08-03 2011-05-31 Citrix Systems, Inc. Systems and methods for routing VPN traffic around network disruption
US8869262B2 (en) 2006-08-03 2014-10-21 Citrix Systems, Inc. Systems and methods for application based interception of SSL/VPN traffic
US8392977B2 (en) * 2006-08-03 2013-03-05 Citrix Systems, Inc. Systems and methods for using a client agent to manage HTTP authentication cookies
US8244883B2 (en) 2006-08-03 2012-08-14 Citrix Systems, Inc. Systems and methods of for providing multi-mode transport layer compression
US8677007B2 (en) 2006-08-03 2014-03-18 Citrix Systems, Inc. Systems and methods for bypassing an appliance
US8495181B2 (en) 2006-08-03 2013-07-23 Citrix Systems, Inc Systems and methods for application based interception SSI/VPN traffic
US7953861B2 (en) * 2006-08-10 2011-05-31 International Business Machines Corporation Managing session state for web applications
US8370479B2 (en) 2006-10-03 2013-02-05 Axeda Acquisition Corporation System and method for dynamically grouping devices based on present device conditions
US8065397B2 (en) 2006-12-26 2011-11-22 Axeda Acquisition Corporation Managing configurations of distributed devices
US9438662B2 (en) * 2007-04-30 2016-09-06 Microsoft Technology Licensing, Llc Enabling secure remote assistance using a terminal services gateway
US9160783B2 (en) * 2007-05-09 2015-10-13 Intouch Technologies, Inc. Robot system that operates through a network firewall
US8312154B1 (en) * 2007-06-18 2012-11-13 Amazon Technologies, Inc. Providing enhanced access to remote services
US9455969B1 (en) 2007-06-18 2016-09-27 Amazon Technologies, Inc. Providing enhanced access to remote services
US7673056B1 (en) * 2007-06-27 2010-03-02 American Megatrends, Inc. Redirection gateway
US20090097470A1 (en) * 2007-10-12 2009-04-16 Collier David S Methods and systems for communicating data
EP2241081B1 (de) 2008-01-26 2018-05-02 Citrix Systems, Inc. Systeme und verfahren für richtliniengesteuertes feinkorn-cookie-proxying
US9800550B2 (en) * 2008-01-31 2017-10-24 International Business Machines Corporation Method and system for pervasive access to secure file transfer servers
JP2009194688A (ja) * 2008-02-15 2009-08-27 Seiko Epson Corp 画像転送装置、画像表示装置、画像表示システム、画像データの転送方法、画像表示方法、およびコンピュータプログラム
JP4773470B2 (ja) * 2008-02-18 2011-09-14 株式会社リコー 文書検索・印刷システム、デジタル複合機、文書検索・印刷方法およびプログラム
US7971099B2 (en) * 2008-04-02 2011-06-28 International Business Machines Corporation Method for enabling faster recovery of client applications in the event of server failure
US7941549B2 (en) * 2008-09-16 2011-05-10 Microsoft Corporation Protocol exchange and policy enforcement for a terminal server session
US8527774B2 (en) * 2009-05-28 2013-09-03 Kaazing Corporation System and methods for providing stateless security management for web applications using non-HTTP communications protocols
DE102009022977A1 (de) * 2009-05-28 2010-12-02 Deutsche Telekom Ag Service Interface
US20110047610A1 (en) * 2009-08-19 2011-02-24 Keypair Technologies, Inc. Modular Framework for Virtualization of Identity and Authentication Processing for Multi-Factor Authentication
US9054913B1 (en) 2009-11-30 2015-06-09 Dell Software Inc. Network protocol proxy
JP2011155629A (ja) * 2009-12-29 2011-08-11 Seiko Epson Corp 振動片、振動子、発振器、電子機器、および周波数調整方法
WO2011096307A1 (ja) 2010-02-03 2011-08-11 日本電気株式会社 プロキシ装置とその動作方法
US9645992B2 (en) 2010-08-21 2017-05-09 Oracle International Corporation Methods and apparatuses for interaction with web applications and web application data
US20120066767A1 (en) * 2010-09-13 2012-03-15 Nokia Corporation Method and apparatus for providing communication with a service using a recipient identifier
US8806040B2 (en) * 2010-12-06 2014-08-12 Red Hat, Inc. Accessing external network via proxy server
US8631277B2 (en) 2010-12-10 2014-01-14 Microsoft Corporation Providing transparent failover in a file system
EP2659650B1 (de) 2010-12-29 2022-06-22 Citrix Systems Inc. Systeme und verfahren zur mehrstufigen markierung von verschlüsselten objekten für zusätzliche sicherheit und effiziente bestimmung verschlüsselter objekte
JP2012227704A (ja) * 2011-04-19 2012-11-15 Fujitsu Ltd 伝送装置、伝送制御方法及び伝送制御プログラム
US10277630B2 (en) * 2011-06-03 2019-04-30 The Boeing Company MobileNet
US9331955B2 (en) 2011-06-29 2016-05-03 Microsoft Technology Licensing, Llc Transporting operations of arbitrary size over remote direct memory access
US8856582B2 (en) 2011-06-30 2014-10-07 Microsoft Corporation Transparent failover
US8788579B2 (en) 2011-09-09 2014-07-22 Microsoft Corporation Clustered client failover
US20130067095A1 (en) 2011-09-09 2013-03-14 Microsoft Corporation Smb2 scaleout
KR101303120B1 (ko) 2011-09-28 2013-09-09 삼성에스디에스 주식회사 상호 인증 기반의 가상사설망 서비스 장치 및 방법
US8793389B2 (en) * 2011-12-20 2014-07-29 Qualcomm Incorporated Exchanging a compressed version of previously communicated session information in a communications system
US9191394B2 (en) * 2012-02-08 2015-11-17 Microsoft Technology Licensing, Llc Protecting user credentials from a computing device
US9722972B2 (en) * 2012-02-26 2017-08-01 Oracle International Corporation Methods and apparatuses for secure communication
US9537899B2 (en) 2012-02-29 2017-01-03 Microsoft Technology Licensing, Llc Dynamic selection of security protocol
FR3000336A1 (fr) * 2012-12-20 2014-06-27 France Telecom Mecanisme de gestion d'une session de communication
JP6482526B2 (ja) 2013-03-15 2019-03-13 オラクル・インターナショナル・コーポレイション コンピュータアプリケーションのオブジェクトコードを変更することによるコンピュータアプリケーションのためのセキュリティサービス管理
US9344422B2 (en) 2013-03-15 2016-05-17 Oracle International Corporation Method to modify android application life cycle to control its execution in a containerized workspace environment
US9129112B2 (en) 2013-03-15 2015-09-08 Oracle International Corporation Methods, systems and machine-readable media for providing security services
WO2015084878A1 (en) * 2013-12-02 2015-06-11 Akamai Technologies, Inc. Virtual private network (vpn)-as-a-service with delivery optimizations while maintaining end-to-end data security
WO2015109172A1 (en) * 2014-01-17 2015-07-23 Pitroda Satyan G System and method for electronic vault to manage digital contents
US9961131B2 (en) 2014-04-25 2018-05-01 Microsoft Technology Licensing, Llc Enhanced reliability for client-based web services
KR101458368B1 (ko) * 2014-04-28 2014-11-19 알서포트 주식회사 모바일단말의 중계서버 능동 접속을 이용한 통신로 개설방법
JP6464256B2 (ja) 2014-09-24 2019-02-06 オラクル・インターナショナル・コーポレイション Ａｎｄｒｏｉｄアプリケーションのライフサイクルを変更することによって、コンテナ化ワークスペース環境内でアプリケーションの実行を管理する方法
US10122767B2 (en) 2015-05-29 2018-11-06 Nagravision S.A. Systems and methods for conducting secure VOIP multi-party calls
US9900769B2 (en) 2015-05-29 2018-02-20 Nagravision S.A. Methods and systems for establishing an encrypted-audio session
US9891882B2 (en) 2015-06-01 2018-02-13 Nagravision S.A. Methods and systems for conveying encrypted data to a communication device
US10356059B2 (en) 2015-06-04 2019-07-16 Nagravision S.A. Methods and systems for communication-session arrangement on behalf of cryptographic endpoints
US10582022B2 (en) * 2016-05-20 2020-03-03 Citrix Systems, Inc. Adaptive session reliability over multiple transports
EP3300331B1 (de) * 2016-07-14 2019-11-20 Huawei Technologies Co., Ltd. Antwortverfahren, vorrichtung und system in der virtuellen netzwerkdatenverarbeitungsauthentifizierung und proxy-server
CN107770138B (zh) * 2016-08-22 2020-12-25 阿里巴巴集团控股有限公司 指定ip地址的方法及代理服务器、客户端
US11070539B2 (en) * 2018-04-10 2021-07-20 ArecaBay, Inc. Network security dynamic access control and policy enforcement
US11303627B2 (en) 2018-05-31 2022-04-12 Oracle International Corporation Single Sign-On enabled OAuth token
US11025672B2 (en) * 2018-10-25 2021-06-01 Palantir Technologies Inc. Approaches for securing middleware data access
US11829277B2 (en) * 2019-03-21 2023-11-28 Dish Network Technologies India Private Limited Systems and methods for remote debugging
CN112165480B (zh) * 2020-09-22 2022-11-11 北京字跳网络技术有限公司 信息获取方法、装置和电子设备
US12003639B2 (en) * 2020-10-15 2024-06-04 Netflix, Inc. Techniques for sharing secure communication sessions within a computer network
US11783062B2 (en) 2021-02-16 2023-10-10 Microsoft Technology Licensing, Llc Risk-based access to computing environment secrets
US12052274B2 (en) 2021-09-23 2024-07-30 Armis Security Ltd. Techniques for enriching device profiles and mitigating cybersecurity threats using enriched device profiles
US12572846B2 (en) 2022-03-22 2026-03-10 Armis Security Ltd. System and method for device attribute identification based on host configuration protocols
US12470593B2 (en) * 2022-07-11 2025-11-11 Armis Security Ltd. Malicious lateral movement detection using remote system protocols
CN116015770B (zh) * 2022-12-09 2025-12-02 北京百度网讯科技有限公司 面向服务器的通信方法、通信系统、通信装置及电子设备
JP2024124182A (ja) * 2023-03-02 2024-09-12 キヤノン株式会社 通信装置、通信装置の制御方法及びプログラム
US12047459B1 (en) * 2023-05-05 2024-07-23 Dell Products L.P. Tunneling a first protocol communication message through a second protocol communication channel

Family Cites Families (236)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US2005A (en) * 1841-03-16 Improvement in the manner of constructing molds for casting butt-hinges
US4438511A (en) * 1980-11-10 1984-03-20 Telebit Corporation Packetized ensemble modem
US4649510A (en) * 1982-04-30 1987-03-10 Schmidt Walter E Methods and apparatus for the protection and control of computer programs
GB2168831B (en) 1984-11-13 1988-04-27 Dowty Information Services Lim Password-protected data link
US4768190A (en) 1986-04-30 1988-08-30 Og Corporation Packet switching network
US4736369A (en) * 1986-06-13 1988-04-05 International Business Machines Corp. Adaptive session-level pacing
US4750171A (en) 1986-07-11 1988-06-07 Tadiran Electronics Industries Ltd. Data switching system and method
US4941089A (en) 1986-12-12 1990-07-10 Datapoint Corporation Input/output network for computer system
US5390297A (en) * 1987-11-10 1995-02-14 Auto-Trol Technology Corporation System for controlling the number of concurrent copies of a program in a network based on the number of available licenses
US5021949A (en) 1988-02-29 1991-06-04 International Business Machines Corporation Method and apparatus for linking an SNA host to a remote SNA host over a packet switched communications network
US4893307A (en) * 1988-02-29 1990-01-09 International Business Machines Corporation Method and apparatus for linking SNA terminals to an SNA host over a packet switched communications network
US4837800A (en) 1988-03-18 1989-06-06 Motorola, Inc. Cellular data telephone system and cellular data telephone therefor
JP2643978B2 (ja) * 1988-04-23 1997-08-25 株式会社ケンウッド パケットデータ生成装置
US4924378A (en) * 1988-06-13 1990-05-08 Prime Computer, Inc. License mangagement system and license storage key
US4953159A (en) 1989-01-03 1990-08-28 American Telephone And Telegraph Company Audiographics conferencing arrangement
US5349678A (en) 1991-08-21 1994-09-20 Norand Corporation Versatile RF data capture system
ATE151183T1 (de) 1989-02-24 1997-04-15 Digital Equipment Corp Makler für die auswahl von rechnernetzwerkservern
US4912756A (en) * 1989-04-07 1990-03-27 Unilink Corporation Method and apparatus for error-free digital data transmission during cellular telephone handoff, etc.
US5220501A (en) 1989-12-08 1993-06-15 Online Resources, Ltd. Method and system for remote delivery of retail banking services
CA2048306A1 (en) 1990-10-02 1992-04-03 Steven P. Miller Distributed configuration profile for computing system
US5181200A (en) 1990-10-29 1993-01-19 International Business Machines Corporation Handoff method and apparatus for mobile wireless workstation
US5159592A (en) 1990-10-29 1992-10-27 International Business Machines Corporation Network address management for a wired network supporting wireless communication to a plurality of mobile users
US5212806A (en) * 1990-10-29 1993-05-18 International Business Machines Corporation Distributed control methods for management of migrating data stations in a wireless communications network
CA2040234C (en) * 1991-04-11 2000-01-04 Steven Messenger Wireless coupling of devices to wired network
US5204897A (en) * 1991-06-28 1993-04-20 Digital Equipment Corporation Management interface for license management system
US5504814A (en) * 1991-07-10 1996-04-02 Hughes Aircraft Company Efficient security kernel for the 80960 extended architecture
US5224098A (en) 1991-07-17 1993-06-29 International Business Machines Corporation Compensation for mismatched transport protocols in a data communications network
US5481721A (en) * 1991-07-17 1996-01-02 Next Computer, Inc. Method for providing automatic and dynamic translation of object oriented programming language-based message passing into operation system message passing using proxy objects
US5241542A (en) 1991-08-23 1993-08-31 International Business Machines Corporation Battery efficient operation of scheduled access protocol
DE4131133B4 (de) 1991-09-19 2005-09-08 Robert Bosch Gmbh Verfahren und Vorrichtung zum Austausch von Daten in Datenverarbeitungsanlagen
US5210753A (en) * 1991-10-31 1993-05-11 International Business Machines Corporation Robust scheduling mechanm for efficient band-width usage in muliticell wireless local networks
US5610595A (en) * 1991-12-09 1997-03-11 Intermec Corporation Packet radio communication system protocol
US5359721A (en) 1991-12-18 1994-10-25 Sun Microsystems, Inc. Non-supervisor mode cross address space dynamic linking
WO1993020511A1 (en) 1992-03-31 1993-10-14 Aggregate Computing, Inc. An integrated remote execution system for a heterogenous computer network environment
US5412717A (en) * 1992-05-15 1995-05-02 Fischer; Addison M. Computer system security method and apparatus having program authorization information data structures
US6026452A (en) * 1997-02-26 2000-02-15 Pitts; William Michael Network distributed site cache RAM claimed as up/down stream request/reply channel for storing anticipated data and meta data
US5265159A (en) 1992-06-23 1993-11-23 Hughes Aircraft Company Secure file erasure
US5442633A (en) 1992-07-08 1995-08-15 International Business Machines Corporation Shortcut network layer routing for mobile hosts
US5307490A (en) * 1992-08-28 1994-04-26 Tandem Computers, Inc. Method and system for implementing remote procedure calls in a distributed computer system
US5325361A (en) 1992-12-01 1994-06-28 Legent Corporation System and method for multiplexing data transmissions
US5550976A (en) 1992-12-08 1996-08-27 Sun Hydraulics Corporation Decentralized distributed asynchronous object oriented system and method for electronic data management, storage, and communication
US5426637A (en) 1992-12-14 1995-06-20 International Business Machines Corporation Methods and apparatus for interconnecting local area networks with wide area backbone networks
US5509070A (en) * 1992-12-15 1996-04-16 Softlock Services Inc. Method for encouraging purchase of executable and non-executable software
US5410543A (en) * 1993-01-04 1995-04-25 Apple Computer, Inc. Method for connecting a mobile computer to a computer network by using an address server
US6006090A (en) 1993-04-28 1999-12-21 Proxim, Inc. Providing roaming capability for mobile computers in a standard network
US5796727A (en) 1993-04-30 1998-08-18 International Business Machines Corporation Wide-area wireless lan access
US5446915A (en) 1993-05-25 1995-08-29 Intel Corporation Parallel processing system virtual connection method and apparatus with protection and flow control
EP0631455A1 (de) 1993-06-25 1994-12-28 Siemens Aktiengesellschaft Verfahren zum Aufrechterhalten von virtuellen Verbindungen bei einem zumindest teilweisen Ausfall von Verbindungswegen
US6249818B1 (en) 1993-06-30 2001-06-19 Compaq Computer Corporation Network transport driver interfacing
US5794207A (en) 1996-09-04 1998-08-11 Walker Asset Management Limited Partnership Method and apparatus for a cryptographically assisted commercial network system designed to facilitate buyer-driven conditional purchase offers
US5564070A (en) 1993-07-30 1996-10-08 Xerox Corporation Method and system for maintaining processing continuity to mobile computers in a wireless network
US5359593A (en) 1993-08-26 1994-10-25 International Business Machines Corporation Dynamic bandwidth estimation and adaptation for packet communications networks
US5544246A (en) 1993-09-17 1996-08-06 At&T Corp. Smartcard adapted for a plurality of service providers and for remote installation of same
US5446736A (en) 1993-10-07 1995-08-29 Ast Research, Inc. Method and apparatus for connecting a node to a wireless network using a standard protocol
US5455953A (en) 1993-11-03 1995-10-03 Wang Laboratories, Inc. Authorization system for obtaining in single step both identification and access rights of client to server directly from encrypted authorization ticket
US5515508A (en) * 1993-12-17 1996-05-07 Taligent, Inc. Client server system and method of operation including a dynamically configurable protocol stack
US5499343A (en) * 1993-12-17 1996-03-12 Taligent, Inc. Object-oriented networking system with dynamically configurable communication links
US5548723A (en) 1993-12-17 1996-08-20 Taligent, Inc. Object-oriented network protocol configuration system utilizing a dynamically configurable protocol stack
US5564016A (en) 1993-12-17 1996-10-08 International Business Machines Corporation Method for controlling access to a computer resource based on a timing policy
US5491800A (en) * 1993-12-20 1996-02-13 Taligent, Inc. Object-oriented remote procedure call networking system
US5495411A (en) 1993-12-22 1996-02-27 Ananda; Mohan Secure software rental system using continuous asynchronous password verification
US5491750A (en) * 1993-12-30 1996-02-13 International Business Machines Corporation Method and apparatus for three-party entity authentication and key distribution using message authentication codes
US5412654A (en) * 1994-01-10 1995-05-02 International Business Machines Corporation Highly dynamic destination-sequenced destination vector routing for mobile computers
US5559800A (en) 1994-01-19 1996-09-24 Research In Motion Limited Remote control of gateway functions in a wireless data communication network
US5627821A (en) * 1994-03-15 1997-05-06 Hitachi, Ltd. Defect notification method in a multipoint ATM network
US5524238A (en) 1994-03-23 1996-06-04 Breakout I/O Corporation User specific intelligent interface which intercepts and either replaces or passes commands to a data identity and the field accessed
US5553139A (en) 1994-04-04 1996-09-03 Novell, Inc. Method and apparatus for electronic license distribution
CA2143874C (en) * 1994-04-25 2000-06-20 Thomas Edward Cooper Method and apparatus for enabling trial period use of software products: method and apparatus for utilizing a decryption stub
US5757907A (en) 1994-04-25 1998-05-26 International Business Machines Corporation Method and apparatus for enabling trial period use of software products: method and apparatus for generating a machine-dependent identification
JP2826468B2 (ja) 1994-04-27 1998-11-18 日本電気 株式会社 回線切替え装置
US5574774A (en) 1994-05-04 1996-11-12 Ericsson Inc. Method and apparatus of maintaining an open communications channel between a cellular terminal and an associated cellular radio network
US5586257A (en) 1994-05-05 1996-12-17 Perlman; Stephen G. Network architecture to support multiple site real-time video games
US5594490A (en) * 1994-05-23 1997-01-14 Cable Services Technologies, Inc. System for distributing video/audio files from central location to a plurality of cable headends
US5416842A (en) * 1994-06-10 1995-05-16 Sun Microsystems, Inc. Method and apparatus for key-management scheme for use with internet protocols at site firewalls
US5771459A (en) 1994-06-21 1998-06-23 U.S. Philips Corporation Communication system for use with stationary and second entities, via a wireless intermediate network with gateway devices, a gateway device for use with such system, and a mobile entity provided with such gateway device
US5550981A (en) 1994-06-21 1996-08-27 At&T Global Information Solutions Company Dynamic binding of network identities to locally-meaningful identities in computer networks
US5481535A (en) * 1994-06-29 1996-01-02 General Electric Company Datagram message communication service employing a hybrid network
US5557732A (en) 1994-08-11 1996-09-17 International Business Machines Corporation Method and apparatus for protecting software executing on a demonstration computer
US5604490A (en) * 1994-09-09 1997-02-18 International Business Machines Corporation Method and system for providing a user access to multiple secured subsystems
US5490139A (en) * 1994-09-28 1996-02-06 International Business Machines Corporation Mobility enabling access point architecture for wireless attachment to source routing networks
US5652789A (en) 1994-09-30 1997-07-29 Wildfire Communications, Inc. Network based knowledgeable assistant
US5602916A (en) * 1994-10-05 1997-02-11 Motorola, Inc. Method and apparatus for preventing unauthorized monitoring of wireless data transmissions
US5659544A (en) 1994-10-17 1997-08-19 Lucent Technologies Inc. Method and system for distributed control in wireless cellular and personal communication systems
US5633868A (en) * 1994-10-17 1997-05-27 Lucent Technologies Inc. Virtual circuit management in cellular telecommunications
US5623601A (en) * 1994-11-18 1997-04-22 Milkway Networks Corporation Apparatus and method for providing a secure gateway for communication and data exchanges between networks
US5566225A (en) 1994-11-21 1996-10-15 Lucent Technologies Inc. Wireless data communications system for detecting a disabled condition and simulating a functioning mode in response to detection
US5752185A (en) * 1994-11-21 1998-05-12 Lucent Technologies Inc. Disconnection management system for wireless voice communications
US5668999A (en) 1994-12-20 1997-09-16 Sun Microsystems, Inc. System and method for pre-verification of stack usage in bytecode program loops
JP3251797B2 (ja) * 1995-01-11 2002-01-28 富士通株式会社 ワイヤレスｌａｎシステム
US5682478A (en) 1995-01-19 1997-10-28 Microsoft Corporation Method and apparatus for supporting multiple, simultaneous services over multiple, simultaneous connections between a client and network server
JPH08235114A (ja) 1995-02-28 1996-09-13 Hitachi Ltd サーバアクセス方法と課金情報管理方法
US5664007A (en) 1995-03-06 1997-09-02 Samadi; Behrokh Method and apparatus for providing continuation of a communication call across multiple networks
US5572528A (en) 1995-03-20 1996-11-05 Novell, Inc. Mobile networking method and apparatus
EP0734144A3 (de) 1995-03-20 1999-08-18 Siemens Aktiengesellschaft Verfahren und Anordnung zum Ermitteln der Benutzergebühr in einer Teilnehmereinrichtung
US5666501A (en) 1995-03-30 1997-09-09 International Business Machines Corporation Method and apparatus for installing software
US5689708A (en) 1995-03-31 1997-11-18 Showcase Corporation Client/server computer systems having control of client-based application programs, and application-program control means therefor
US5627892A (en) * 1995-04-19 1997-05-06 General Instrument Corporation Of Delaware Data security scheme for point-to-point communication sessions
US6418324B1 (en) * 1995-06-01 2002-07-09 Padcom, Incorporated Apparatus and method for transparent wireless communication between a remote device and host system
US5717737A (en) * 1995-06-01 1998-02-10 Padcom, Inc. Apparatus and method for transparent wireless communication between a remote device and a host system
US5592549A (en) * 1995-06-15 1997-01-07 Infosafe Systems, Inc. Method and apparatus for retrieving selected information from a secure information source
US5657390A (en) 1995-08-25 1997-08-12 Netscape Communications Corporation Secure socket layer application program apparatus and method
US5657452A (en) 1995-09-08 1997-08-12 U.S. Robotics Corp. Transparent support of protocol and data compression features for data communication
US5682534A (en) 1995-09-12 1997-10-28 International Business Machines Corporation Transparent local RPC optimization
US5623600A (en) * 1995-09-26 1997-04-22 Trend Micro, Incorporated Virus detection and removal apparatus for computer networks
US5758186A (en) * 1995-10-06 1998-05-26 Sun Microsystems, Inc. Method and apparatus for generically handling diverse protocol method calls in a client/server computer system
US5729734A (en) * 1995-11-03 1998-03-17 Apple Computer, Inc. File privilege administration apparatus and methods
WO1997019415A2 (en) * 1995-11-07 1997-05-29 Cadis, Inc. Search engine for remote object oriented database management system
US6112085A (en) 1995-11-30 2000-08-29 Amsc Subsidiary Corporation Virtual network configuration and management system for satellite communication system
US5732074A (en) * 1996-01-16 1998-03-24 Cellport Labs, Inc. Mobile portable wireless communication system
US5721818A (en) * 1996-01-25 1998-02-24 Apple Computer, Inc. Method and system for enabling a file server to service multiple networks of the same network protocol family by invoking multiple instances of a network session protocol
US5889816A (en) * 1996-02-02 1999-03-30 Lucent Technologies, Inc. Wireless adapter architecture for mobile computing
US5856974A (en) * 1996-02-13 1999-01-05 Novell, Inc. Internetwork address mapping gateway
US5754774A (en) * 1996-02-15 1998-05-19 International Business Machine Corp. Client/server communication system
US5673322A (en) 1996-03-22 1997-09-30 Bell Communications Research, Inc. System and method for providing protocol translation and filtering to access the world wide web from wireless or low-bandwidth networks
US5784643A (en) 1996-03-28 1998-07-21 International Business Machines Corporation System incorporating program for intercepting and interpreting or altering commands for generating I/O activity for enabling real-time user feedback by sending substitute characters to modem
GB2313524A (en) * 1996-05-24 1997-11-26 Ibm Providing communications links in a computer network
US5742757A (en) * 1996-05-30 1998-04-21 Mitsubishi Semiconductor America, Inc. Automatic software license manager
EP0851628A1 (de) 1996-12-23 1998-07-01 ICO Services Ltd. Schlüsselverteilung für mobiles Funknetz
US5740361A (en) * 1996-06-03 1998-04-14 Compuserve Incorporated System for remote pass-phrase authentication
US6058250A (en) * 1996-06-19 2000-05-02 At&T Corp Bifurcated transaction system in which nonsensitive information is exchanged using a public network connection and sensitive information is exchanged after automatically configuring a private network connection
US6088451A (en) 1996-06-28 2000-07-11 Mci Communications Corporation Security system and method for network element access
US5909431A (en) 1996-06-28 1999-06-01 At&T Corp. Packet mode multimedia conferencing services over an ISDN wide area network
US5748897A (en) * 1996-07-02 1998-05-05 Sun Microsystems, Inc. Apparatus and method for operating an aggregation of server computers using a dual-role proxy server computer
US5812671A (en) 1996-07-17 1998-09-22 Xante Corporation Cryptographic communication system
US5848064A (en) 1996-08-07 1998-12-08 Telxon Corporation Wireless software upgrades with version control
US5944791A (en) 1996-10-04 1999-08-31 Contigo Software Llc Collaborative web browser
JP3492865B2 (ja) * 1996-10-16 2004-02-03 株式会社東芝 移動計算機装置及びパケット暗号化認証方法
JPH10178421A (ja) * 1996-10-18 1998-06-30 Toshiba Corp パケット処理装置、移動計算機装置、パケット転送方法及びパケット処理方法
US6101543A (en) 1996-10-25 2000-08-08 Digital Equipment Corporation Pseudo network adapter for frame capture, encapsulation and encryption
JP3651721B2 (ja) 1996-11-01 2005-05-25 株式会社東芝 移動計算機装置、パケット処理装置及び通信制御方法
US5974151A (en) 1996-11-01 1999-10-26 Slavin; Keith R. Public key cryptographic system having differential security levels
US6131116A (en) 1996-12-13 2000-10-10 Visto Corporation System and method for globally accessing computer services
US5987611A (en) 1996-12-31 1999-11-16 Zone Labs, Inc. System and methodology for managing internet access on a per application basis for client computers connected to the internet
US6055575A (en) * 1997-01-28 2000-04-25 Ascend Communications, Inc. Virtual private network system and method
US5923756A (en) 1997-02-12 1999-07-13 Gte Laboratories Incorporated Method for providing secure remote command execution over an insecure computer network
AU6654798A (en) * 1997-02-26 1998-09-18 Siebel Systems, Inc. Method of determining visibility to a remote database client of a plurality of database transactions using a networked proxy server
US6161123A (en) 1997-05-06 2000-12-12 Intermec Ip Corporation Providing reliable communication over an unreliable transport layer in a hand-held device using a persistent session
US6166729A (en) 1997-05-07 2000-12-26 Broadcloud Communications, Inc. Remote digital image viewing system and method
US20020115407A1 (en) 1997-05-07 2002-08-22 Broadcloud Communications, Inc. Wireless ASP systems and methods
US6201962B1 (en) * 1997-05-14 2001-03-13 Telxon Corporation Seamless roaming among multiple networks including seamless transitioning between multiple devices
US6154461A (en) 1997-05-14 2000-11-28 Telxon Corporation Seamless roaming among multiple networks
US6091951A (en) 1997-05-14 2000-07-18 Telxon Corporation Seamless roaming among multiple networks
US5968176A (en) 1997-05-29 1999-10-19 3Com Corporation Multilayer firewall system
US5935212A (en) 1997-08-07 1999-08-10 I-Planet, Inc. Connection-oriented session emulation
US6681017B1 (en) * 1997-09-03 2004-01-20 Lucent Technologies Inc. Simplified secure shared key establishment and data delivery protocols for electronic commerce
US6023724A (en) * 1997-09-26 2000-02-08 3Com Corporation Apparatus and methods for use therein for an ISDN LAN modem that displays fault information to local hosts through interception of host DNS request messages
US9197599B1 (en) 1997-09-26 2015-11-24 Verizon Patent And Licensing Inc. Integrated business system for web based telecommunications management
US6256739B1 (en) 1997-10-30 2001-07-03 Juno Online Services, Inc. Method and apparatus to determine user identity and limit access to a communications network
US6725376B1 (en) * 1997-11-13 2004-04-20 Ncr Corporation Method of using an electronic ticket and distributed server computer architecture for the same
EP1717696A1 (de) * 1997-11-14 2006-11-02 Microsoft Corporation Serverbetriebssystem zur Unterstützung mehrfacher Client-Server-Sitzungen und dynamische Wiederverbindung von Benutzern mit früheren Sitzungen
US6085247A (en) 1998-06-08 2000-07-04 Microsoft Corporation Server operating system for supporting multiple client-server sessions and dynamic reconnection of users to previous sessions using different computers
US6230004B1 (en) * 1997-12-01 2001-05-08 Telefonaktiebolaget Lm Ericsson Remote procedure calls using short message service
US6170075B1 (en) * 1997-12-18 2001-01-02 3Com Corporation Data and real-time media communication over a lossy network
US5870412A (en) * 1997-12-12 1999-02-09 3Com Corporation Forward error correction system for packet based real time media
US6145109A (en) 1997-12-12 2000-11-07 3Com Corporation Forward error correction system for packet based real time media
ATE218778T1 (de) 1997-12-12 2002-06-15 3Com Corp Ein vorwärtsfehlerkorrektionssystem für packetbasierte echtzeitmedien
FR2773935A1 (fr) 1998-01-19 1999-07-23 Canon Kk Procedes de communication entre systemes informatiques et dispositifs les mettant en oeuvre
US6226750B1 (en) * 1998-01-20 2001-05-01 Proact Technologies Corp. Secure session tracking method and system for client-server environment
US6147986A (en) 1998-03-06 2000-11-14 Lucent Technologies Inc. Address updating of wireless mobile terminal hosts affiliated with a wired network
US6415329B1 (en) 1998-03-06 2002-07-02 Massachusetts Institute Of Technology Method and apparatus for improving efficiency of TCP/IP protocol over high delay-bandwidth network
US6199113B1 (en) * 1998-04-15 2001-03-06 Sun Microsystems, Inc. Apparatus and method for providing trusted network security
US7401114B1 (en) * 1998-04-20 2008-07-15 Sun Microsystems, Inc. Method and apparatus for making a computational service highly available
US6289461B1 (en) 1998-06-09 2001-09-11 Placeware, Inc. Bi-directional process-to-process byte stream protocol
US6243753B1 (en) 1998-06-12 2001-06-05 Microsoft Corporation Method, system, and computer program product for creating a raw data channel form an integrating component to a series of kernel mode filters
EP1066735B1 (de) 1998-06-19 2011-08-17 Juniper Networks, Inc. Verbindungsnetzwerk zum betrieb in einem kommunikationsknoten
US6564320B1 (en) 1998-06-30 2003-05-13 Verisign, Inc. Local hosting of digital certificate services
US6360265B1 (en) * 1998-07-08 2002-03-19 Lucent Technologies Inc. Arrangement of delivering internet protocol datagrams for multimedia services to the same server
CN1221110C (zh) * 1998-07-17 2005-09-28 松下电器产业株式会社 通信系统及其网关、无线信息终端和无线通信方法
US6269402B1 (en) 1998-07-20 2001-07-31 Motorola, Inc. Method for providing seamless communication across bearers in a wireless communication system
US7277424B1 (en) 1998-07-21 2007-10-02 Dowling Eric M Method and apparatus for co-socket telephony
US6714536B1 (en) * 1998-07-21 2004-03-30 Eric M. Dowling Method and apparatus for cosocket telephony
JP3216607B2 (ja) * 1998-07-29 2001-10-09 日本電気株式会社 デジタル著作物流通システム及び方法、デジタル著作物再生装置及び方法、並びに記録媒体
US6233619B1 (en) * 1998-07-31 2001-05-15 Unisys Corporation Virtual transport layer interface and messaging subsystem for high-speed communications between heterogeneous computer systems
US6094423A (en) 1998-08-03 2000-07-25 Motorola, Inc. Wireless protocol method and apparatus supporting transaction requests with variable length responses
US6226618B1 (en) * 1998-08-13 2001-05-01 International Business Machines Corporation Electronic content delivery system
US6308281B1 (en) 1998-09-02 2001-10-23 International Business Machines Corporation Virtual client to gateway connection over multiple physical connections
US6574239B1 (en) 1998-10-07 2003-06-03 Eric Morgan Dowling Virtual connection of a remote unit to a server
US6484206B2 (en) * 1998-10-07 2002-11-19 Nortel Networks Limited Efficient recovery of multiple connections in a communication network
US6546425B1 (en) * 1998-10-09 2003-04-08 Netmotion Wireless, Inc. Method and apparatus for providing mobile and other intermittent connectivity in a computing environment
US7136645B2 (en) 1998-10-09 2006-11-14 Netmotion Wireless, Inc. Method and apparatus for providing mobile and other intermittent connectivity in a computing environment
JP2000125029A (ja) 1998-10-12 2000-04-28 Matsushita Electric Ind Co Ltd 網制御装置
AU1599800A (en) 1998-10-28 2000-05-15 L-3 Communications Corporation Apparatus and methods for cryptographic synchronization in packet based communications
ATE316730T1 (de) * 1998-11-02 2006-02-15 Airbiquity Inc Geo-räumliche adressierung zum internet-protokoll
US6449651B1 (en) 1998-11-19 2002-09-10 Toshiba America Information Systems, Inc. System and method for providing temporary remote access to a computer
JP2000242589A (ja) 1999-02-25 2000-09-08 Mitsubishi Electric Corp データ転送制御コンピュータシステム
US6421768B1 (en) 1999-05-04 2002-07-16 First Data Corporation Method and system for authentication and single sign on using cryptographically assured cookies in a distributed computer environment
SG118221A1 (en) 1999-05-21 2006-01-27 Ibm Method and apparatus for initializing secure communications among and for exclusively pairing wireless devices
US6289450B1 (en) * 1999-05-28 2001-09-11 Authentica, Inc. Information security architecture for encrypting documents for remote access while maintaining access control
US6609198B1 (en) 1999-08-05 2003-08-19 Sun Microsystems, Inc. Log-on service providing credential level change without loss of session continuity
US6691232B1 (en) * 1999-08-05 2004-02-10 Sun Microsystems, Inc. Security architecture with environment sensitive credential sufficiency evaluation
US6535481B1 (en) * 1999-08-20 2003-03-18 Nortel Networks Limited Network data routing protection cycles for automatic protection switching
US6826696B1 (en) 1999-10-12 2004-11-30 Webmd, Inc. System and method for enabling single sign-on for networked applications
US7917628B2 (en) 1999-12-02 2011-03-29 Western Digital Technologies, Inc. Managed peer-to-peer applications, systems and methods for distributed data access and storage
US7587467B2 (en) 1999-12-02 2009-09-08 Western Digital Technologies, Inc. Managed peer-to-peer applications, systems and methods for distributed data access and storage
US20020010866A1 (en) * 1999-12-16 2002-01-24 Mccullough David J. Method and apparatus for improving peer-to-peer bandwidth between remote networks by combining multiple connections which use arbitrary data paths
US6721899B1 (en) * 2000-01-12 2004-04-13 Lucent Technologies Inc. Fault-tolerant non-flooding routing
US6496520B1 (en) 2000-01-21 2002-12-17 Broadcloud Communications, Inc. Wireless network system and method
JP3630065B2 (ja) 2000-03-03 2005-03-16 株式会社村田製作所 セラミックグリーンシートの製造方法及びセラミックグリーンシート製造装置
US7065547B2 (en) 2000-03-09 2006-06-20 Persels Conrad G Integrated on-line system with enchanced data transfer protocol
US6845387B1 (en) * 2000-04-07 2005-01-18 Advanced Digital Information Corporation Creating virtual private connections between end points across a SAN
IL135555A0 (en) 2000-04-09 2001-05-20 Vidius Inc Preventing unauthorized access to data sent via computer networks
US6671729B1 (en) 2000-04-13 2003-12-30 Lockheed Martin Corporation Autonomously established secure and persistent internet connection and autonomously reestablished without user intervention that connection if it lost
US6732314B1 (en) * 2000-05-26 2004-05-04 3Com Corporation Method and apparatus for L2TP forward error correction
JP4099930B2 (ja) * 2000-06-02 2008-06-11 株式会社日立製作所 ルータ装置及びｖｐｎ識別情報の設定方法
US6708218B1 (en) * 2000-06-05 2004-03-16 International Business Machines Corporation IpSec performance enhancement using a hardware-based parallel process
US20020069356A1 (en) * 2000-06-12 2002-06-06 Kwang Tae Kim Integrated security gateway apparatus
US7010300B1 (en) * 2000-06-15 2006-03-07 Sprint Spectrum L.P. Method and system for intersystem wireless communications session hand-off
US9038170B2 (en) 2000-07-10 2015-05-19 Oracle International Corporation Logging access system events
WO2002009458A2 (en) * 2000-07-24 2002-01-31 Bluesocket, Inc. Method and system for enabling seamless roaming in a wireless network
US7139844B2 (en) * 2000-08-04 2006-11-21 Goldman Sachs & Co. Method and system for processing financial data objects carried on broadcast data streams and delivering information to subscribing clients
US6874086B1 (en) * 2000-08-10 2005-03-29 Oridus, Inc. Method and apparatus implemented in a firewall for communicating information between programs employing different protocols
US6996631B1 (en) * 2000-08-17 2006-02-07 International Business Machines Corporation System having a single IP address associated with communication protocol stacks in a cluster of processing systems
CA2421609A1 (en) 2000-09-12 2002-03-21 Netmotion Wireless, Inc. Method and apparatus for providing mobile and other intermittent connectivity in a computing environment
US6697377B1 (en) * 2000-10-21 2004-02-24 Innomedia Pte Ltd. Method for communicating audio data in a packet switched network
US6947400B2 (en) * 2001-01-31 2005-09-20 Ipr Licensing, Inc. Achieving PPP mobility via the mobile IP infrastructure
US7089311B2 (en) * 2001-01-31 2006-08-08 International Business Machines Corporation Methods, systems and computer program products for resuming SNA application-client communications after loss of an IP network connection
JP3963690B2 (ja) * 2001-03-27 2007-08-22 富士通株式会社 パケット中継処理装置
US7136364B2 (en) 2001-03-29 2006-11-14 Intel Corporation Maintaining a reliable link
US7017049B2 (en) * 2001-04-12 2006-03-21 International Business Machines Corporation Method and system providing secure socket layer session sharing between network based servers and a client
US20030041175A2 (en) 2001-05-03 2003-02-27 Singhal Sandeep K Method and System for Adapting Short-Range Wireless Access Points for Participation in a Coordinated Networked Environment
US6925481B2 (en) 2001-05-03 2005-08-02 Symantec Corp. Technique for enabling remote data access and manipulation from a pervasive device
US7224979B2 (en) 2001-05-03 2007-05-29 Symantec Corporation Location-aware service proxies in a short-range wireless environment
US6947444B2 (en) * 2001-06-06 2005-09-20 Ipr Licensing, Inc. Method and apparatus for improving utilization efficiency of wireless links for web-based applications
US7100200B2 (en) 2001-06-13 2006-08-29 Citrix Systems, Inc. Method and apparatus for transmitting authentication credentials of a user across communication sessions
US7698381B2 (en) * 2001-06-20 2010-04-13 Microsoft Corporation Methods and systems for controlling the scope of delegation of authentication credentials
US7117267B2 (en) * 2001-06-28 2006-10-03 Sun Microsystems, Inc. System and method for providing tunnel connections between entities in a messaging system
US6832260B2 (en) 2001-07-26 2004-12-14 International Business Machines Corporation Methods, systems and computer program products for kernel based transaction processing
AUPR797501A0 (en) * 2001-09-28 2001-10-25 BlastMedia Pty Limited A method of displaying content
US6993652B2 (en) * 2001-10-05 2006-01-31 General Instrument Corporation Method and system for providing client privacy when requesting content from a public server
US20030078985A1 (en) * 2001-10-23 2003-04-24 David Holbrook Proactive message buffering across intermittent network connections
US20030078983A1 (en) * 2001-10-23 2003-04-24 Sullivan Terence Sean Message prioritization and buffering in a limited network
US7028183B2 (en) 2001-11-13 2006-04-11 Symantec Corporation Enabling secure communication in a clustered or distributed architecture
KR100436435B1 (ko) 2001-12-26 2004-06-16 한국전자통신연구원 유무선 통합망에서 간접 승인을 이용한 패킷 전송 장치 및그 방법
US7661129B2 (en) 2002-02-26 2010-02-09 Citrix Systems, Inc. Secure traversal of network components
US7080404B2 (en) 2002-04-01 2006-07-18 Microsoft Corporation Automatic re-authentication
US7746799B2 (en) 2003-06-20 2010-06-29 Juniper Networks, Inc. Controlling data link layer elements with network layer elements

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102009051383A1 (de) * 2009-10-30 2011-05-12 Siemens Aktiengesellschaft Verfahren und Vorrichtung zum sicheren Übertragen von Daten
US9398049B2 (en) 2009-10-30 2016-07-19 Siemens Aktiengesellschaft Method and device for securely transmitting data

Also Published As

Publication number Publication date
EP1678918A1 (de) 2006-07-12
WO2005036858A1 (en) 2005-04-21
ES2298835T3 (es) 2008-05-16
ATE381196T1 (de) 2007-12-15
EP1678918B1 (de) 2007-12-12
US20050198380A1 (en) 2005-09-08
CA2541151A1 (en) 2005-04-21
AU2004306772A1 (en) 2005-04-21
US7984157B2 (en) 2011-07-19
DE602004010703D1 (de) 2008-01-24
JP2007515852A (ja) 2007-06-14
CA2541151C (en) 2013-06-11
KR20060126952A (ko) 2006-12-11

Similar Documents

Publication Publication Date Title
DE602004010703T2 (de) Eine persistente und zuverlässige sitzung, die neztwerkkomponenten unter verwendung eines verkapselungsprotokolls sicher durchläuft
DE19740547B4 (de) Vorrichtung und Verfahren zum Sicherstellen sicherer Kommunikation zwischen einer anfordernden Entität und einer bedienenden Entität
DE60114097T2 (de) Verfahren und System zur Verbesserung der Netzleistungsfähigkeit unter Verwendung eines leistungssteigernden Proxies
EP1678885B1 (de) Verkapselungsprotokoll für sitzungsfortdauer und sitzungszuverlässigkeit
DE60110974T2 (de) Abfangverfahren und -vorrichtung zur Kompensation nachteiliger Eigenschaften eines Kommunikationsprotokolls
DE60026838T2 (de) Dynamische verbindung zu mehreren quellen-servern in einem transcodierungs-proxy
DE60200451T2 (de) Herstellung einer gesicherten Verbindung mit einem privaten Unternehmensnetz über ein öffentliches Netz
DE69924573T2 (de) Verfahren und Anordnung zur Herstellung sicherer Verbindungen über Einwegskanäle
US7502726B2 (en) Systems and methods for maintaining a session between a client and host service
DE69923954T2 (de) Kommunikationssystem und verfahren
DE60130042T2 (de) Verteilte server-funktionalität für ein emuliertes lan
EP1128615A2 (de) Verfahren und Kommunikationseinrichtung zur Verschlüsselung von E-Mail
EP1083722A2 (de) Verfahren, System und Gateway, die einen End-zu-End gesicherten Zugriff auf WAP-Dienste erlauben
EP1721235B1 (de) Kommunikationssystem und verfahren zur bereitstellung eines mobilen kommunikationsdienstes
EP2245834A1 (de) Sichere datenkommunikation
EP1776821B1 (de) System und verfahren zum sicheren anmelden in einem kommuniktionssystem mit netzwerkverbindungs- und verbindungssteuerungs-rechnern
EP1496665B1 (de) Verfahren zur Festlegung von Sicherheitseinstellungen in einem Automatisierungsnetz
WO2004043014A2 (de) Verfahren zum übertragen von daten
DE102020129226B4 (de) Datenverarbeitungsvorrichtung und mobiles Kommunikationsgerät zum Aufbauen einer sicheren Kommunikationsverbindung über einen Zugangspunkt
DE10218811B4 (de) Verfahren und Vorrichtung zum Übertragen von Datenpaketen in einem funkgestützten Kommunikationssystem bei Verwendung eines PEP
HK1096211B (en) Encapsulating protocol for session persistence and reliability
DE19622629A1 (de) Verfahren zur kryptographischen Sicherung einer Übertragung mindestens eines Datenpakets von einer ersten Computereinheit zu einer zweiten Computereinheit unter Verwendung des Remote Procedure Call Verfahrens
HK1096213B (en) A persistent and reliable session securely traversing network components using an encapsulating protocol

Legal Events

Date Code Title Description
8381 Inventor (new situation)

Inventor name: PEDERSEN, BRADLEY JAY, PARKLAND, FL 33067, US

Inventor name: STONE, DAVID SEAN, LAUDERDALE BY-THE-SEA, FL 3, US

Inventor name: TREDER, TERRY, HIGHLAND BEACH, FL 33487, US

Inventor name: PANASYUK, ANATOLIY, BELLEVUE, WA 98005, US

Inventor name: KRAMER, ANDRE, CAMBOURNE, CAMBRIDGE, GB

8364 No opposition during term of opposition