DE60204528T2

DE60204528T2 - Auflösen von virtuellen Netzwerknamen

Info

Publication number: DE60204528T2
Application number: DE60204528T
Authority: DE
Inventors: Steven E. Lucco; Erik B. Christensen; Andrew J. Layman; David E. Levin; Bradford H. Lovering; Henrik Frystyk Nielson; John P. Shewchuk
Original assignee: Microsoft Corp
Current assignee: Microsoft Corp
Priority date: 2001-10-16
Filing date: 2002-10-15
Publication date: 2005-11-03
Anticipated expiration: 2022-10-16
Also published as: EP1303109A3; EP1303109A2; US7194553B2; JP2003163678A; ATE297629T1; US20030074472A1; DE60204528D1; EP1303109B1; US20060212599A1; US7653747B2; JP4159337B2

Description

Die Erfindung betrifft im Allgemeinen Computernetzwerke. Konkret ermöglicht es die Erfindung, dass Mitteilungen unter Verwendung eines Namensauflösungsprozesses zu einer oder mehreren virtuellen Kommunikations-Endstellen geleitet werden.
Viele Jahre lang stellte das Internet ein großes Netzwerk verknüpfter Computer dar, die Mitteilungen mit Hilfe des hinlänglich bekannten Internetprotokolls (IP) weiterleiten. Spezielle Vorrichtungen, die als „Router" bekannt sind, legen fest, wohin jedes Datenpaket gesendet wird, so dass ein bestimmtes Datenpaket bzw. „Datagramm" am beabsichtigten Ziel ankommt, obwohl der spezielle Weg möglicherweise dem Ersteller der Mitteilung nicht bekannt ist. Jedem Computer bzw. Router ist mindestens eine IP-Adresse zugeordnet, bei der es sich gegenwärtig um eine 32-Bit-Zahl handelt, die in einer so genannten „Punkt"-Notation dargestellt ist, z. B. 12.152.34.61. Jedes Paket enthält im Allgemeinen eine Quellen-IP-Adresse, eine Ziel-IP-Adresse und andere Felder in einem Header, die gemeinsam festlegen, wohin und wie das Paket innerhalb des Netzwerks geroutet wird. Die Router in dem Netzwerk haben Kenntnis von den anderen Routern, mit denen sie verbunden sind, wodurch die Pakete schließlich zu einer Endstelle geroutet werden, die von der Ziel-IP-Adresse dargestellt ist.
Auf Computern, die eine oder mehr zugewiesene IP-Adressen haben, können Internetseiten und andere Ressourcen gespeichert werden. Da es jedoch schwierig ist, sich IP-Adressen zu merken, wird oft ein hierarchischer Name auf Textbasis zur Anwendung gebracht, der als Uniform Resource Locator (URL) bekannt ist und eine Internetseite oder eine andere Ressource eindeutig identifiziert (z. B. www.foo.com). Wenn ein Computernutzer eine derartige URL in einem Internet-Browser eingibt, sendet der Browser die URL an einen Domain-Mail-Server (DNS), der die URL in eine IP-Adresse übersetzt, die einen Computer repräsentiert, auf dem die Internetseite gefunden werden kann. Anschließend sendet der Internet-Browser einen Abrufbefehl an jenen Computer. Dieser Prozess ist als DNS-Namensauflösung bekannt.
Anhand von 1 wird angenommen, dass ein Internet-Browser 104, der an einem Client-Computer 101 arbeitet, einem Nutzer die Eingabe einer willkürlichen URL ermöglicht, z. B. http://foo.microsoft.com/foo/bar/bing.htm. Die erste Komponente („http:") ist ein Identifier, der angibt, welches Internetprotokoll verwendet werden soll, um mit der Maschine zu kommunizieren, die das Dokument hält oder den Dienst anbietet. Die zwei te Komponente, „//foo.microsoft.com" wird als „Host-Name" bezeichnet und zum identifizieren eines speziellen Computers oder einer Gruppe von Computern verwendet, die an das Internet angeschlossen sind. Die dritte Komponente „/foo/bar/bing.htm" ist ein lokaler Identifier der Maschine, um das gewünschte Dokument oder den Dienst an der Maschine zu finden.
Wein 1 abgebildet, läuft der konventionelle Internet-Auflösungsprozess für die obige URL wie folgt ab.
Zuerst gibt der Internet-Browser 104 eine DNS-Anfrage 107 an den Internet-Domain-Name-Service aus, dargestellt durch den DNS-Server 102. Der DNS-Server 102 enthält eine Tabelle 105, die für eine entsprechende IP-Adresse jede URL abbildet. Als Reaktion auf die Anfrage bzw. Anforderung 107 löst der DNS-Server 102 „foo.microsoft.com" in eine IP-Adresse auf, z. B. 1.2.3.4 in Schritt 108, die danach wieder an den Client-Computer 101 zurückgegeben wird. Wenngleich während der Auflösung dieses Teils der URL möglicherweise mehrere Server kontaktiert werden, kann nur die gesamte Auflösung von „foo.microsoft.com" auf 1.2.3.4 im Cache temporär gespeichert werden. Um einen dazugehörigen Namen, z. B. „foo2.microsoft.com" aufzulösen, muss der Auflösungsprozess von vorn begonnen werden.
Als Zweites kontaktiert der Internet-Browser 104 den Server 103 (z. B. die Maschine, die an die IP-Adresse 1.2.3.4 gebunden ist mittels HTTP (Hyper Text Transport Protocol) und fordert die Ressource http://foo.microsoft.com/foo/bar/bing.htm an, wie durch die Anforderung 109 in 1 angegeben. Die Angabe der vollständigen URL ist notwendig, da eine bestimmte Maschine von verschiedenen Host-Names angesprochen werden kann, z. B. http://microsoft.com und http://foo.microsoft.com können zu 1.2.3.4 aufgelöst werden. Anschließend antwortet die Maschine 103 in Schritt 110 mit der Ressource 106, die als Internetseite auf dem Browser 104 angezeigt wird.
Dieser Auflösungsmechanismus bringt verschiedene Administrationsprobleme mit sich, da unterschiedliche Maschinen, die unterschiedliche Dienste anbieten, verschiedene Host-Names bereitstellen müssen. Es sei beispielsweise angenommen, dass www.foo.com zum Anbieten eines Internetdienstes verwendet wird, während mail.foo.com zum Anbieten eines Mail-Dienstes verwendet wird. Der Verwaltungsaufwand entsteht durch die Notwendigkeit, all diese Namen zu erzeugen und zu verwalten, und durch die Unfähigkeit konventioneller Systeme, die Auflösung bei Maschinen anzuwenden, die Domain-Komponenten gemeinsam nutzen. Darüber hinaus ist das DNS-Auflösungsschema dahingehend unflexibel, dass bei Verlagerung eines Host-Computers eine Datei auf dem DNS-Server geändert werden muss, damit sie den neuen physischen Ort des Computers wiedergibt.
US-A-6,026,441 betrifft ein Verfahren zum Herstellen einer Internetverbindung mit einem Client, der eine dynamisch zugewiesene IP-Adresse hat. In diesem Zusammenhang beschreibt das Dokument D1 eine Verbindung, die im Internet zwischen einem Ursprungs-Client-Terminal und einem Ziel-Client-Terminal hergestellt wird, wobei Letzterer eine IP-Adresse hat, die dynamisch von einem Internet Access Service Provider (IASP) zugewiesen worden ist und die dem Ursprung-Client-Terminal unbekannt ist. Konkret verwendet ein erster Nutzer am Client-Terminal, der über das Internet eine Verbindung mit einem Client-Terminal eines Zielnutzers herstellen möchte, die Email-Adresse des Zielnutzers (z. B. mary@def.com), um den Domain-Name des IASP von jenem Nutzer (def.com) zu bestimmen. Mit Hilfe des festgelegen Domain-Names des IASP von dem Zielnutzer wird ein DNS gesucht, um die IP-Adresse von jenem IASP zu erhalten. Daraufhin sendet der Client-Terminal des initiierenden Nutzers eine Anfrage an die IP-Adresse des IASP, um die IP-Adresse zu erhalten, die jener IASP derzeit dem Zielnutzer (mary) zugewiesen hat. Wenn jener Nutzer eingeloggt ist, ist ein Eintrag in einer Datenbank im IASP des Zielnutzers vorhanden, der jenen Nutzer (mary) mit der IP-Adresse in Verbindung bringt, die dem Client-Terminal des Nutzers von dem IASP für die aktuelle Sitzung zugewiesen ist.
MOURAD, A. et al. „SCALABLE WEB SERVER ARCHITECTURES", TAGUNGSBERICHT DES IEEE INTERNATIONAL SYMPOSIUM ON COMPUTERS AND COMMUNICATIONS, 1. Juli 1997, Seiten 12–16 (D2) bezieht sich auf eine skalierbare Web-Server-Architektur, die Internetseiten in die Lage versetzt, mit einem immer größer werdenden Verkehrsaufkommen umzugehen. In diesem Zusammenhang wird eine hierarchische Server-Architektur auf Umleitungsbasis („redirection-based") beschrieben. In der beschriebenen Architektur kommen zwei Ebenen von Servern zur Anwendung: Umleitungs-Server und normale HTTP-Server. Die Daten werden entsprechend dem Inhalt partitioniert und auf verschiedenen HTTP-Servern gespeichert. Die Umleitungs-Server werden dazu verwendet, die Anforderung des Nutzers auf die entsprechenden HTTP-Server mit Hilfe des Umleitungsmechanismus zu verteilen, der von dem HTTP-Protokoll unterstützt wird. Wie in dem Dokument D2 beschrieben, verwendet ein Client eine Basis-URL, um den Umleitungs-Server, der die Basis-URL abbildet, mit der Ziel-URL des Dokuments zu verbinden, und sendet sie anschließend in einer Umleitungsmitteilung an den Client zurück. Daraufhin nutzt der Client die neue URL in der Umleitungs-Mitteilung, um sich wegen der Daten mit dem HTTP-Server in Verbindung zu setzen.
Eine Aufgabe der vorliegenden Erfindung besteht darin, ein verbessertes System und Verfahren zu schaffen, die es ermöglichen, Dienste und Ressourcen viel besser gesteuert und viel flexibler zu benennen und zu adressieren, und die Mechanismen bereitzustellen, die die Effizienz des Auflösungsprozesses erhöhen.
Diese Aufgabe wird durch den Gegenstand der unabhängigen Patentansprüche gelöst. Bevorzugte Ausführungsformen sind Gegenstand der abhängigen Ansprüche.
Die Erfindung macht es möglich, dass mit Hilfe eines Namensauflösungsprozesses Mitteilungen zu virtuellen Netzwerk-Endstellen geleitet werden. Ein Mitteilungsdienst, der zusammen mit einem Namensauflösungs-Proxy implementiert sein kann, leitet eine Mitteilung mit Hilfe eines virtuellen Netzwerknamens zu einem Name-Router. Der Name-Router löst einen Teil des virtuellen Netzwerknamens auf und sendet die Mitteilung zu einer Zielstelle weiter, die dem aufgelösten Teil des virtuellen Netzwerknamens entspricht. Falls es sich um einen anderen Name-Router handelt, löst die Ziel-Endstelle einen nächsten Teil des virtuellen Netzwerknamens auf und der Prozess läuft so lange ab, bis die Endstelle des Zielortes erreicht ist. Ausführungsformen der Erfindung enthalten eines oder mehrere der folgenden Merkmale:

(1) die Fähigkeit, eine Mitteilung über eine Reihe von Name-Routern zu einem bestimmten virtuellen Netzwerknamen (VNN) zu senden;
(2) einen rekursiven Nachschlage-Algorithmus, der das Cachen der Zwischenergebnisse bei der Auflösung eines VNN unterstützt;
(3) das Cachen der Zwischen- und Endergebnisse einer solchen Auflösung;
(4) die Fähigkeit, eine bestimmte Mitteilung zu mehreren Endstellen oder zu einer aus einer Gruppe von potenziellen Endstellen zu routen (d. h. die Fähigkeit, eine Gruppe von Endstellen mit eines einzigen VNN zu identifizieren und festzustellen, ab eine bestimmte Mitteilung zu einer, mehreren oder zu allen Endstellen gesendet werden sollte),
(5) die Fähigkeit, Regeln für die Auflösung eines bestimmten VNN festzulegen und anzuwenden;
(6) die Fähigkeit, Regeln für die Sichtbarkeit eines bestimmten VNN festzulegen und anwenden;
(7) die Fähigkeit, Anmerkungen über administrative Maßnamen in Namespace zu erzeugen und zu verbreiten;
(8) die Fähigkeit, temporäre VNNs zu erzeugen und zuzuweisen;
(9) die Fähigkeit, auf der Grundlage eines Schlüssels einen VNN zu erzeugen; und
(10) die Fähigkeit, einen Mechanismus für das standardmäßige Routing einer Mitteilung bereitzustellen.

Weitere Vorteile und Merkmale werden anhand der nachfolgenden Beschreibung, der Figuren und Patentansprüche deutlich.
1 zeigt ein herkömmliches DNS-Namensauflösungsschema.
2 zeigt ein System entsprechend mehrerer erfindungsgemäßer Aspekte.
3 zeigt ein System mit einem Client-Teilsystem und einem virtuellen Namensauflösungs-Teilsystem nach einer Variante der Erfindung.
4 zeigt, wie ein Netzwerk-Name, z. B. eine URL, aufgelöst werden kann, indem er zusätzlich zu einem konventionellen Domain-Name-Server (DNS) eine Vielzahl virtueller Name-Router durchläuft.
5 zeigt genauer, wie Funktionen und Daten zwischen einem oder mehreren Clients 501 und einem oder mehreren Routern 503, 504 und 505 partitioniert werden können.
6 zeigt Schritte, die von einem Proxy- oder einem Mitteilungsdienst ausgeführt werden können, um Mitteilungen zu einer virtuellen Endstelle zu routen.
7 zeigt Schritte, die von einem oder mehreren Name-Routern ausgeführt werden können, um einen virtuellen Netzwerknamen aufzulösen und eine Mitteilung zu einer Kommunikations-Endstelle zu leiten, die dem virtuellen Netzwerknamen entspricht.
Eine Ausführungsform der Erfindung erweitert das konventionelle URL-Namensgebungsschema, indem eine Komponente der URL auf eine physische Maschinen-Adresse abgebildet werden kann. Dies bedeutet beispielsweise, dass man einen Internetdienst als http://www.foo.com/web und einen Mail-Service als http://www.foo.com/mail angeben könnte, und jede dieser URLs eine andere Maschine abbilden, da die „web"- und „mail"-Komponente nun unabhängig voneinander aufgelöst werden können und nicht beide von ihnen unbedingt zu derselben physischen Maschine zeigen müssen, wie dies bei der konventionellen DNS-Namensauflösung der Fall ist.
Darüber hinaus kann die Auflösung kontextgebunden sein, d. h. der Auflösungsprozess kann die Identität des Clients, der die Adresse auflöst, berücksichtigen oder aber den Netzwerkort des Clients berücksichtigen und eine Auflösung zu dem Dienst hin vornehmen, der dem Client am nächsten ist, oder ausgehend von weiteren Informationen eine andere Regel zur Anwendung bringen.
Ein anderer Aspekt der Erfindung verbessert die konventionelle Internet-Namensgebung weiter, indem es einem Client ermöglicht wird, über ein Konstrukt, das als „Name-Router" bezeichnet wird, eine Mitteilung an einen speziellen VNN zu senden. Dadurch wird es möglich, dass Clients nicht mehr die VNN-Auflösung und Bearbeitung von Mittei lungen vornehmen müssen. Der Begriff „virtueller Netzwerkname" bzw. VNN wird zur Angabe eines Namens verwendet, der eine Kommunikations-Endstelle in einem Netzwerk identifiziert, wobei der Name möglicherweise keine statische Verbindung zu einer physischen Maschinen-Adresse hat (d. h. die physische Maschinenadresse kann sich ändern oder verschieden sein, wenngleich derselbe VNN verwendet wird).
Bestimmte Ausführungsformen des Systems weisen einen oder mehrere Namensauflösungs/Routing-Server auf, die nachstehend genauer beschrieben werden. Virtuelle Name-Router können eine Namensauflösungsfunktion (d. h. die Umwandlung eines Namens oder von Teilen eines Namens in eine Adresse), eine Routing-Funktion (z. B. die Fähigkeit, eine Mitteilung an eine Adresse weiterzuleiten) und andere Funktionen haben, die nachstehend beschrieben sind. Natürlich können diese Funktionen auch auf verschiedene Computer aufgeteilt sein, so dass die Name-Server-Funktion auf einer Maschine zu finden ist, während sich die Routing-Funktion auf einer anderen Maschine befindet (z. B. könnte sich die Namensauflösungsfunktion auf einer Maschine befinden, während die Routing-Funktion auf der Client-Maschine angelegt ist). Natürlich sind auch andere Implementierungen möglich, wobei der Ort und der Aufbau einer bestimmten Funktion von Konstruktionsaspekten diktiert werden. Der Begriff „virtueller Name-Server" ist so zu verstehen, dass er wenigstens eine Namensauflösungsfunktion enthält; der Begriff „virtueller Name-Router bedeutet, dass wenigstens eine Mitteilungs-Routing-Funktion vorhanden ist, und der Begriff „virtuelle Namensauflösung/Router" soll beide Funktionen enthalten. Ansonsten werden im vorliegenden Text die einzelnen Funktionen, die einem Element zugeschrieben werden, aus dem Kontext deutlich, in dem das Element verwendet wird.
Bei Gebrauch dieses System kommen Komponenten, wie beispielsweise ein Client, der die Zustellung der Mitteilung anfordert, und der vorhandene Domain-Name-Service (DNS) zum Einsatz, wenngleich die erfindungsgemäßen Prinzipien auch ohne DNS zur Anwendung kommen können. Der allgemeine Begriff „Name-Server" soll sich auf jeden Server beziehen, der eine Auflösungsfunktion ausführen kann, einschließlich, jedoch nicht eingegrenzt auf den konventionellen Domain-Name-Service (DNS).
Aspekte der Erfindung können in vier Kategorien unterteilt werden, wobei jede von ihnen nachstehend einzeln erörtert wird:

1. Mitteilungs-Routing und Routing-Beschleunigung
2. Anwendungsmöglichkeiten einer Regel für das Mitteilungs-Routing und die Beschleunigung
3. Meldungen über administrative Maßnahmen im Namespace
4. Automatische Namenserzeugung und -übertragung (delegation)

MITTEILUNGS-ROUTING UND ROUTING-BESCHLEUNIGUNG
Ein erstes Merkmal der vorliegenden Erfindung umfasst die Fähigkeit, über eine Gruppe von Name-Routern eine Nachricht zu einer bestimmten Kommunikations-Endstelle zu senden, die von einem VNN, z. B. eine URL, identifiziert ist. Als Teil dieses Merkmals kann einer Kommunikations-Endstelle unabhängig davon, welches Netzwerkprotokoll zum Kommunizieren mit jener Endstelle verwendet wird, ein VNN zugewiesen werden. Ein zweites Merkmal umfasst die Fähigkeit, URL-Komponenten über den Domain-Namen hinaus zu speziellen Name-Routern aufzulösen.
Ein drittes Merkmal enthält die Fähigkeit, Zwischenergebnisse, die zu cachen sind, zurückzuführen und somit die Namensauflösung und den Routing-Prozess zu beschleunigen.
Ein viertes Merkmal bietet die Fähigkeit, eine bestimmte Nachricht zu mehreren Endstellen oder zu einer aus einer Gruppe potenzieller Endstellen zu leiten, (d. h. die Fähigkeit, eine Gruppe von Endstellen mit einem einzigen VNN zu identifizieren und festzustellen, ob eine bestimmte Nachricht zu einer, mehreren oder allen Endstellen gesendet werden sollte).
2 zeigt ein System, das mehrere erfindungsgemäße Prinzipien nach einer ersten Ausführungsform anwendet. Die Namensauflösung und das Routing ermöglicht es einem Client, eine Nachricht über eine Reihe von Name-Routern zu einer oder mehreren Kommunikations-Endstellen zu senden. Wie in 2 abgebildet, sendet ein Client 201 eine Mitteilung, die zu einer Kommunikations-Endstelle 203 weitergeleitet werden soll, über einen oder mehrere Name-Router 202. Zum Übertragen der Mitteilung zu dem Ziel kann jede beliebige Anzahl von Name-Routern verwendet werden, doch für die vorliegende Erörterung wird lediglich auf einen Name-Router Bezug genommen. Jeder Name-Router sollte sich von konventionellen DNS-Servern, z. B. dem DNS-Server 210, unterscheiden. Solche konventionellen Server lösen lediglich einen feststehenden Teil einer URL entsprechend einem nicht erweiterbaren Schema auf, wie in 1 abgebildet.
Der Name-Router 202, der eine auf einem Computer befindliche Software-Funktion umfassen kann, verwaltet eine Tabelle 204 mit virtuellen Namen, die einen Eintrag 205 enthält, der den virtuellen Namen für die Kommunikations-Endstelle C auf eine spezifische physische Adresse abbildet, die zum direkten Zugriff auf die Endstelle C verwendet wird (z. B. bildet er einen willkürlichen Namen auf eine IP-Adresse ab). Der Client 201 sendet die für die Endstelle 203 mit dem Namen C vorgesehene Mitteilung zum Name-Router 202, der den Abbildungseintrag 205 dazu verwendet, die Mitteilung zu der physischen Adresse für die Endstelle C weiterzuleiten. Obwohl der Name-Router 202 als separater physischer Computer abgebildet ist, könnte sich der Name-Router natürlich auch auf demselben Computer wie der Client 201 befinden.
Bei einer Variante kann der Client 201 auch eine Beschleunigungsinformation vom Name-Router 202 anfordern. Hat der Client 201 dies getan und der Client 201 die entsprechenden Genehmigungen zum Erlangen dieser Informationen erhalten, sendet der Name-Router 202 eine Mitteilung 209 an den Client 201 zurück, die angibt, dass der virtuelle Name für die Endstelle C auf die spezielle physische Adresse für die Endstelle C abgebildet ist. Nachdem der Client 201 diese Information empfangen und im Cache gespeichert hat, wie mit 206 angegeben, kann er diese physische Adresse für C dazu nutzen, direkt mit der Endstelle C in Kontakt zu treten, wodurch der Prozess der Mitteilungszustellung beschleunigt wird. Genauso wie herkömmlich können im Cache gespeicherte Einträge nach einer bestimmten Zeit automatisch gelöscht werden, um veraltete Einträge zu entfernen.
Bei bestimmten Ausführungsformen könnten Kommunikations-Endstellen mit Hilfe einer erweiterten URL-Syntax angegeben werden, wobei jeder aus einer Vielzahl von Name-Servern/Routern für das Abbilden eines Teils der gesamten URL verantwortlich ist. Im Gegensatz zu der konventionellen DNS-Technologie, bei der ein DNS-Server stets einen feststehenden und bekannten Teil einer bestimmten URL auf eine einzige physische Adresse abbildet, wird die URL als Satz einzelner Namenskomponenten betrachtet, von der jede in einem System von einem separaten Name-Router aufgelöst wird. Eine URL mit der Form http://aaa.com/bbb/ccc/ddd.htm kann beispielsweise mit verschiedenen Name-Routern aufgelöst werden: Die aaa-Komponente würde von dem konventionellen DNS-Server aufgelöst werden, der einen Name-Router für die bbb-Komponente auflösen würde. Diese Mitteilung würde zu dem Name-Router für bbb gesendet werden, der anschließend die nächste Komponente ccc auflösen würde usw., bis die Endstelle ermittelt ist. Als Alternative dazu können Kommunikations-Endstellen von einem willkürlichen Namen identifiziert werden (z. B. „Bob" oder „Bob im Unternehmen X", und zum Auflösen solcher willkürlichen Namen kann ein Standard-Name-Router verwendet werden.
In 3 ist ein System zum Ausführen der obigen Prinzipien entsprechend einer erfindungsgemäßen Ausführungsform dargestellt. Ein erstes Teilsystem 301 enthält eine oder mehrere Client-Maschinen 309 und eine oder mehrere virtuelle Namensauflösungs-Proxy-Maschinen 308. Natürlich kann ein oder können alle Namensauflösungs-Proxy/s physisch auf einer oder mehreren Client-Maschinen vorgesehen sein. Ein virtuelles Na mensauflösungs-System 302 enthält einen konventionellen Domain-Name-Service 307, der nach einer Ausführungsform dazu dient, die erste Ebene jedes Namens aufzulösen. Eine oder mehrere virtuelle Name-Router 303 bis 306 dienen dazu, einen oder mehrere Teile eines virtuellen Namens aufzulösen, weshalb sie in der Darstellung für diesen Zweck miteinander verbunden sind. Die Verbindungen können konventionelle Netzwerkverbindungen aufweisen, z. B. lokale Netzwerke, das Internet usw. Es ist davon auszugehen, dass ein bestimmter Name unter Verwendung eines ersten Satzes von Name-Routern aufgelöst werden kann, während ein zweiter Name mit einem anderen Satz von Name-Routern aufgelöst werden kann, usw.
Es wird angenommen, dass ein Client 309 eine Mitteilung zu einem Endstellennamen eines virtuellen Namens senden muss (z. B. an eine erweiterte URL, wie oben beschrieben, oder an einen willkürlichen Namen, z. B. „Bob" oder „Firmendatenbank"). Der Client 309 sendet die Mitteilung über die virtuelle Namensauflösungs-Proxy-Maschine 308 zu der Endstelle des virtuellen Namens. In einer Ausführungsform sendet der Proxy 308 eine Mitteilung an den konventionellen Domain-Name-Service 307, um eine physische Maschinen-Adresse zu erhalten, die einer ersten Ebene der Namensauflösung entspricht. Bei einer anderen Ausführungsform, z. B. eine, bei der ein willkürlicher Endstellenname verwendet wird, der nicht im modifizierten URL-Format vorliegt, kann dieser Schritt weggelassen werden, und die Namensauflösung kann direkt fortgesetzt werden, z. B. mit einem standardmäßigen Namensauflösungsdienst 309, der eine Abbildung zu einer physischen Maschine herstellt, die eine erste Ebene von Namensabbildungen enthält (z. B. einer der virtuellen Name-Router aus dem Teilsystem 302).
Nachdem der virtuelle Name-Router festgelegt ist, zu dem die Auflösung der ersten Ebene gesendet werden sollte, überträgt der virtuelle Namensauflösungs-Proxy 308 eine Mitteilung zu dem angegebenen virtuellen Name-Router, die die Auflösung des Namens anfordert. Der Name-Router empfängt die Anforderung, löst einen Teil oder den gesamten Namen mit Hilfe einer internen Abbildungstabelle auf und sendet den aufgelösten Namen oder Namensteil zurück. Der Prozess wird solange wiederholt, bis der gesamte Name aufgelöst und die Endstelle festgelegt ist.
4 zeigt genauer, wie eine Mitteilung entsprechend den obigen Prinzipien zu einer virtuellen Endstelle gesendet werden kann. Es wird angenommen, dass ein Client eine Mitteilung zu der Kommunikations-Endstelle mit dem Namen http://foo.com/a/b/c, angegeben bei Element 450, zu senden hat. Nachfolgend werden Schritte beschrieben, die zum Auflösen dieses Namens entsprechend einer erfindungsgemäßen Ausführungsform ausgeführt werden können. Um diese Auflösung vollständig zu veranschaulichen, wird davon ausgegangen, dass jede Komponente dieser URL mit Hilfe eines anderen Name-Routers weitergeleitet wird, wenngleich dies nicht unbedingt der Fall sein muss.
Wie bei Schritt 401 angegeben, sendet zuerst der Client die Mitteilung zu dem Namensauflösungs-Proxy 420, einschließlich des virtuellen Namens, der aufgelöst werden muss, in diesem Fall http://foo.com/a/b/c. Der Proxy 420 sendet zuerst eine Anfrage 402 an den konventionellen Domain-Name-Server 440, um die IP-Adresse für die erste Komponente foo.com zu lokalisieren, die in Schritt 403 zurückgesendet wird. Wie bei dem konventionellen DNS-Schema wird diese IP-Adresse (z. B. 1.2.3.5) von dem Client im Cache gespeichert, so dass der Client schneller URLs auflösen kann, beginnend mit http://foo.com. Allerdings ist die von dem DNS-Server zurückgesendete IP-Adresse eigentlich die IP-Adresse für den virtuellen Name-Server (Element 460), der für die Namensauflösung, beginnend bei foo.com, verantwortlich ist, und nicht ein Ziel.
Als Nächstes sendet der Proxy 420 in Schritt 404 die Mitteilung, die adressiert ist an http://foo.com/a/b/c, an den Name-Router 1.2.3.5 (Element 460) und fordert Beschleunigungsinformationen an.
Ruft man sich die Annahme in Erinnerung, dass jede Komponente des virtuellen Namens aufgelöst und von einem anderen Name-Router geroutet werden kann, so sucht als Drittes der Name-Router an der Adresse 1.2.3.5 (Element 460) die/eine Komponente in seiner Routing-Tabelle und sieht, dass er die Mitteilung zu dem Name-Router bei 1.2.3.6 (Element 461) routen muss. Der Name-Router 460 leitet die Mitteilung an den Name-Router 1.2.3.6 weiter und sendet die Client-Beschleunigungsinformation, dass foo.com/a zu 1.2.3.6 aufgelöst werden soll, an Element 460 zurück (Schritt 407), welches diese Information in Schritt 405 an den Client zurückgibt. Der Client speichert diese Zwischenauflösung zur künftigen Nutzung im Cache-Speicher.
Der Name-Router bei 1.2.3.6 (Element 461) schlägt die /b-Komponente nach und sieht, dass er die Mitteilung zum Name-Router 462 an der IP-Adresse 1.2.3.7 routen muss. Der Name-Router 461 leitet die Mitteilung zum Name-Router 462 bei 1.2.3.7 weiter und sendet die Beschleunigungsinformation, dass foo.com/a// zu 1.2.3.7 aufgelöst werden sollte, zurück. Darüber hinaus wird wie bereits zuvor die Information über die teilweise Namensauflösung auf dem umgekehrten Weg zum Client zurückgesendet, und jeder Name-Router auf dem Weg kann die Teilauflösungsergebnisse im Cache-Speicher hinterlegen.
Der Name-Router 462 an der Adresse 1.2.3.7 sucht die /c-Komponente und erhält die physische Adresse für die Endstelle 450 (z. B. 1.3.5.7). Der Name-Router 462 leitet die Mitteilung weiter zur Kommunikations-Endstelle und gibt die Client-Beschleunigungs information, dass foo.com/a/b/c zu 1.3.5.7 aufgelöst werden sollte, zurück. Demzufolge können sowohl der Client als auch eine oder mehrere Zwischenknoten die Teilauflösungsergebnisse zur künftigen Nutzung im Cache-Speicher hinterlegen. Es sei noch einmal darauf verwiesen, dass in Abhängigkeit von den Inhalten der Auflösungstabelle und von anwendbaren Regeln (bezüglich näherer Einzelheiten zu Regeln siehe unten) dieses letzte Routing oder eigentlich jedes beliebige Zwischen-Routing dazu hätte führen können, dass die Mitteilung zu mehr als einer Endstelle gesendet wird.
Wenngleich bei dem oben beschriebenen Beispiel für einen virtuellen Netzwerknamen ein „http:"-Schema verwendet wird, was die Verwendung des HTTP-Netzwerkprotokolls anzeigt, so hätte jede der zwischengeschalteten Kommunikations-Endstellen ein anderes Protokoll verwenden können, um die Mitteilung weiterzuleiten. Z. B. hätte die physische Adresse für die /b-Komponente Folgende sein können: soap://1.3.5.7, was die Verwendung des SOAP-Netzwerkprotokolls zur letztendlichen Zustellung der Mitteilung angibt. Diese Fähigkeit, inmitten des Stroms die Protokolle zu wechseln und auf jede Kommunikations-Endstelle zuzugreifen, die über ein beliebiges Netzwerkprotokoll erreichbar ist, stellt auf dem Fachgebiet einen großen Fortschritt dar. In diesem Zusammenhang kann jeder Name-Router einen oder mehrere Protokoll-Konvertierer enthalten, so dass die mit einem Protokoll (z. B. HTTP) empfangenen Mitteilungen während des Routings-Prozesses in ein anderes Protokoll konvertiert werden können, ohne dass dabei überhaupt der Ursprungs-Client aktiv wird.
Die Routing-Information und der Entscheidungsprozess können in der Hardware oder Software implementiert sein, wodurch das Routing von Mitteilungen zu VNNs mit Leitungsgeschwindigkeit (wire speed) ermöglicht wird.
5 zeigt genauer, wie Funktionen und Daten zwischen einem oder mehreren Clients 501 und einem oder mehreren Name-Routern 503, 504 und 505 partitioniert werden können. Der Client-Computer 501 enthält ein Anwendungsprogramm 507 bzw. einen anderen Prozess, der eine Mitteilung zu einer virtuellen Endstelle senden muss. Die Anwendung 507 verwendet einen Namensauflösungs- und Mitteilungsdienst 508 (z. B. mit einer Anwendungs-Programmierschnittstelle bzw. API), um die Mitteilung zu der virtuellen Endstelle zu senden. Wie oben erläutert, kann der virtuelle Name einen willkürlich aufgebauten Namen, z. B. „Bob", oder einen mittels URL erweiterten Namen, z. B. http://bob.com/a/b/c, umfassen. Bei der Ausführungsform aus 5 enthält der Namensauflösungs- und Mitteilungsdienst 508 die Funktion eines Proxys 420 in 4. Ein Namensauflösungs-Cache 506 enthält teilweise aufgelöste Präfixe von jedem aus einer Vielzahl von virtuellen Namen, zu denen Mitteilungen geroutet worden sind.
Bei einer Ausführungsform enthält jeder Name-Router, z. B. der Name-Router 503, eine Tabelle virtueller Namen 509 (die in einer Datenbank gespeichert werden kann, z. B. in einer dazugehörigen Datenbank), einen Cache 510, der die aufgelösten Namens-Präfixe speichert, eine Abbildungsregelfunktion 511 (wird nachstehend erörtert), einen oder mehrere Protokoll-Konvertierer 512, eine Änderungs-Kennzeichnungsfunktion 513 und eine Namenserzeugungsfunktion 514. die virtuelle Namenstabelle 509 und der Cache 510 arbeiten so wie oben erörtert. Die Abbildungsregel 511 sendet optional eine Richtlinie auf jeden Namensauflösungs-Prozess an, wie nachstehend genauer beschrieben wird. Der Protokoll-Konvertierer 512 konvertiert gegebenenfalls Protokolle beim Weiterleiten von Mitteilungen. Die Änderungskennzeichnungsfunktion 513 überträgt Hinweise auf Änderungen von Abbildungen in der Tabelle virtueller Namen zwischen Name-Routern, wie nachstehend genauer erläutert wird. Diese Funktion kann eine API, eine Benutzeroberfläche und/oder eine Mitteilungs-Schnittstelle umfassen, die Fernänderungen an den Abbildungen ermöglicht. Wie im Weiteren noch genauer erläutert wird, können Änderungen an Abbildungen vorgenommen werden, um Verarbeitungsfunktionen zu verlagern und andere Operationen auszuführen.
Im Allgemeinen empfängt jeder Name-Router eine Mitteilung, die an eine virtuelle Endstelle gerichtet ist, löst einen Teil oder den gesamten Namen auf, leitet die Mitteilung weiter zum nächsten Name-Router, der dem teilweise aufgelösten Namen entspricht, und sendet (optional) Beschleunigungsinformationen an den Ursprungs-Client zurück. Willkürlich lange und komplexe Namen mit URL-Erweiterung können an Stelle eines zwangsweisen Namensauflösungsschemas auf einer einzigen Ebene, das konventionell in dem DNS implementiert ist, stückweise von einer Vielzahl von Name-Routern aufgelöst werden.
ANWENDUNGSMÖGLICHKEITEN VON REGELN FÜR DAS MITTEILUNGS-ROUTING UND DIE -BESCHLEUNIGUNG
Eine zweite Gruppe von Merkmalen umfasst die Fähigkeit, in jedem Schritt des Routing-Prozesses eine Regel anzuwenden. Eine Regel kann ein beliebiges Routing-Verhalten festlegen, das eine bestimmte Kenntnis des Client einschließt, der eine Mitteilung zu dem VNN sendet, oder eine bestimmte Kenntnis der Inhalte der Mitteilung selbst. Zu diesen Regel-Bedingungen können unter anderem Auflösungen gehören, die auf Folgendem basieren:

1. Identität des Clients (z. B. ein Name oder eine spezielle IP-Adresse);
2. DNS-Domain des Clients (z. B. „.com", „.org" oder „foo.com");
3. Bandbreite zum Client;
4. Trust-Domain des Clients (z. B. eine Mitteilung, die von einer Maschine innerhalb eines Datenzentrums stammt, die an eine andere Maschine in dem Datenzentrum gebunden ist);
5. Zugriffsebene des Clients (könnte z. B. in der Mitteilung codiert sein und davon abhängen, ob der Client ein zahlender Kunde ist, wodurch das Routing zu einem schnellen Server erfolgen könnte);
6. Mitteilungs-Header, z. B. das beabsichtigte Ziel oder eine angeforderte Aktion;
7. Inhalt der Mitteilung, z. B. Signaturen oder Nutzsignale der Mitteilung.

Mitteilungen können aber ebenfalls mit jeder beliebigen Kombination von Bedingungen geroutet werden.
Abhängig von dem Domain, von dem die Mitteilung gesendet worden ist, kann das Routing zu verschiedenen Kommunikations-Endstellen erfolgen. Z. B. kann ein Client, der eine Mitteilung an http://foo.com/a/b/c von einem Computer innerhalb des Domains blip.com sendet, eine Auflösung wie oben (wobei die Endstelle mit einer physischen Adresse 1.3.5.7 angegeben ist) bekommen, wohingegen bei einem Client, der dieselbe Adresse von dem DNS-Domain baz.uk auflöst, das Routing wie folgt ablaufen kann:
foo.com→1.2.3.5
/a→4.3.2.1
/b→4.3.2.3
/c→7.5.3.1,
wobei die Adressen 4.3.2.1, 4.3.2.3 und 7.5.3.1 in gewisser Weise näher an dem DNS-Domain baz.uk sind als die Adressen 1.2.3.6 und 1.2.3.7 und 1.3.5.7. Dieses Merkmal ermöglicht es beispielsweise, dass sich gespiegelte Server an unterschiedlichen geografischen Orten befinden können und dass Clients, die Dienste von einer bestimmten Endstelle anfordern, je nach der Ursprungs-Adresse des Clients (z. B. IP-Adresse oder Domain) zu unterschiedlichen physischen Maschinen geroutet werden.
Es sei angemerkt, dass es bei diesen Regeln auch vorkommen kann, dass eine Auflösung einer bestimmten Komponente überhaupt verweigert wird, wodurch es (beispielsweise) Administratoren ermöglicht wird, VNNs bereitzustellen, die nur von einer Stelle innerhalb einer bestimmten Organisation erreicht werden können. Beschleunigungsdaten können wahlweise auf der Basis eines der obigen Kriterien oder auf der Grundlage anderer Kriterien zurückgegeben werden. Wenn die Regel auf diese Art und Weise angewendet wird, lässt sich die Anfälligkeit bestimmter Ressourcen für verschiedene Formen des Hackings stark verringern, da sich eine unbekannte Anzahl von Name-Routern zwischen dem Domain-Name und der geschützten Ressource befinden kann. Die Beispiele für die Anwendung der Regel wie oben zeigen, dass ein Hacker nicht einmal erraten kann, wo sich die Ressource befindet, da der einzige unbedingt erforderliche öffentliche Teil des Routings die Auflösung des Domain-Names zu dem virtuellen Name-Server ist, der zu jenem Domain-Name gehört.
6 zeigt ein Verfahren mit Schritten, die von einem Proxy ausgeführt werden können, z. B. von einem virtuellen Namensauflösungs-Proxy 308 aus 3. In Schritt 601 empfängt der Proxy eine Mitteilung und eine virtuelle Netzwerk-Adresse. In Schritt 602 wird festgestellt, ob es sich bei der Adresse um eine erweiterte URL-Adresse handelt, wobei in diesem Fall Schritt 603 ausgeführt und eine konventionelle DNS-Anfrage durchgeführt wird, um eine IP-Adresse für den Name-Router auf erster Ebene zu erhalten. Falls nicht, wird in Schritt 604 ein Standard-Name-Router verwendet (eine Standard-IP-Adresse oder eine Standardtabelle, die einen Standard-Name-Router auf eine bekannte IP-Adresse abbildet).
In Schritt 605 wird die Mittelung zu der Adresse des Name-Routers gesendet, die entweder in Schritt 604 oder Schritt 603 erhalten wurde. In Schritt 606 wird das Ergebnis jeglicher Namensauflösung, die von nachgelagerten Name-Routern bereitgestellt wird, im Cache gespeichert. Wenngleich dies nicht explizit in 6 dargestellt ist, kann dieser Cache konsultiert werden, um den gesamten virtuellen Netzwerknamen oder einen Teil von ihm aufzulösen, anstelle die Mitteilung zum Name-Router zu senden (so genannte „Beschleunigungsdaten"), wie durch den Cache 506 in 5 abgebildet.
7 zeigt ein Verfahren mit Schritten, die von einem Name-Router ausgeführt werden können, z. B. von den Name-Routern 503, 504, und 505 aus 5. In Schritt 701 wird die Mitteilung zusammen mit dem Netzwerknamen, zu dem sie übertragen werden soll, im Name-Router empfangen. In Schritt 702 wird die lokale Tabelle für virtuelle Namen konsultiert, um einen Teil des Namens (und optional auch Protokoll) zu suchen, wie oben anhand von 4 beschrieben wurde. In Schritt 703 werden mit Hilfe der oben spezifizierten Prinzipien Regeln angewendet, um gegebenenfalls Routing-Entscheidungen zu modifizieren. Dazu kann beispielsweise das Routing der Mitteilung zu einer anderen Stelle ausgehend von der Identität des Clients gehören. In Schritt 704 werden, falls nötig, Protokoll-Konvertierungen vorgenommen. Schließlich wird in Schritt 705 die Mitteilung zu dem Name-Router gesendet, der der teilweise aufgelösten Adresse entspricht, und es werden Beschleunigungsdaten, falls vorhanden, zu dem Client zurückgegeben.
MELDUNGEN ÜBER ADMINISTRATIVE MAßNAHMEN IM NAMESPACE
Bei einer Ausführungsform enthält das System weiterhin die Fähigkeit, Meldungen über Änderungen an VNNs zu erzeugen und weiterzugeben. Jede administrative Funktion an einem Name-Router (Hinzufügen einer neuen Namenskomponente, Löschen einer alten Namenskomponente, Veränderung einer vorhandenen Namenskomponente) kann eine Meldung generieren, die an andere Name-Router weitergegeben werden kann.
Man stelle sich beispielsweise vor, dass ein Online-Magazin seinen gesamten Inhalt sechs Monate nach Veröffentlichung kostenlos zur Verfügung stellt, jedoch eine Gebühr für Inhalte verfangt, die weniger als sechs Monate alt sind. Dieses Online-Magazin kann das vorliegende erfindungsgemäße Prinzip ausnutzen, indem es den gesamten aktuellen Inhalt unter www.onlinemagazine.com/subcription hält und den gesamten kostenfreien Inhalt unter www.onlinemagazine.com/free. Wird der Inhalt eines bestimmten Monats kostenlos (beispielsweise www.onlinemagazine.com/subcription/may2001), wird das Magazin www.onlinemagazine.com/subcription/may2001 in www.onlinemagazine.com/free/may2001 umbenannt. Ein Client, der ein Abonnement für Änderungen an www.onlinemagazine.com/free hat, wird daraufhin informiert, dass der Inhalt vom Mai 2001 nun zur Verfügung steht.
AUTOMATISCHE NAMENSERZEUGUNG UND -ÜBERTRAGUNG
Merkmale nach diesem Aspekt der Erfindung sind:

1. die Fähigkeit des Name-Routers, temporäre VNNs zu erzeugen und sie auf physische Adressen abzubilden;
2. die Fähigkeit eines Name-Routers, ausgehend von einem bestimmten Schlüssel einen VNN zu erzeugen;
3. die Fähigkeit eines Name-Routers, für einen VNN eine Standard-Route bereitzustellen.

Falls gefordert, können Name-Router automatisch eindeutige VNN-Komponenten erzeugen. Derartige eindeutige Komponenten können auf Zufallszahlengeneratoren zurückgreifen wie Tageszeitparameter, Hash-Werte oder dergleichen.
Es wird beispielsweise angenommen, dass ein Administrator eine neue Kommunikations-Endstelle freigibt, die in dem Namespace www.foo.com/a über einen VNN erreichbar ist. Der Administrator kann einen eindeutigen und unbenutzten Namen für den Name-Router anfordern, der den VNN www.foo.com/a bedient; der Administrator richtet eine Anfrage an den Server und der Server sendet Folgendes zurück:
www.foo.com/a/uniquename12345. Anschließend informiert der Administrator den Name-Router über die physische Adresse, unter der der neue Name abgebildet ist.
Name-Router können eindeutige VNN-Komponenten auch auf der Grundlage eines Schlüssels erzeugen. Man nehme beispielsweise an, dass ein Administrator eine VNN-Komponente ausgehend von einer eindeutigen ID bereitstellen will, die einem Nutzer zugewiesen ist, so dass der Name-Router für einen bestimmten Namen eine Sicherheitsregel ausgehend von der Benutzer-ID zur Verfügung stellen kann. Daher fordert der Administrator auf der Basis der Nutzer-ID einen eindeutigen Namen an und informiert anschließend den Name-Router der physischen Adresse, unter der der neue Name abgebildet ist. Wenn Mitteilungen zu jenem neuen Namen gesendet werden, kann der Name-Router die ID des Absenders verwenden, um festzustellen, ob jener Absender Zugriff auf den neuen Namen hat.
Darüber hinaus können Name-Router eine Standard-Route für einen VNN bereitstellen. Man nehme beispielsweise an, dass ein Administrator möchte, dass www.foo.com/a/specialname zur Sonderverarbeitung an die physische Adresse 2.3.4.5 geroutet wird, gleichzeitig aber will, dass alle anderen Komponenten unter /a zur regulären Verarbeitung zu der physischen Adresse 2.4.6.8 geroutet werden. Der Administrator legt eine Standard-Route für /a/* auf 2.4.6.8 fest und eine Sonder-Route für /a/specialname auf 2.3.4.5. Somit werden ungeachtet dessen, welche Namen unter /a erzeugt werden, selbige zu 2.4.6.8 geroutet.
Zwar wurde die Erfindung im Hinblick auf spezifische Beispiele beschrieben, einschließlich gegenwärtig bevorzugter erfindungsgemäßer Ausführungsformen, doch für Fachleute liegt es auf der Hand, dass zahlreiche Varianten und Abwandlungen der oben beschriebenen Systeme und Verfahren denkbar sind, die in den Schutzumfang der beigefügten Ansprüche fallen. Jeder der hier beschriebenen Schritte des Verfahrens und alle in den Figuren gezeigten Funktionen können in Computer-Software implementiert sein und auf einem Computer-lesbaren Medium gespeichert werden, um für allgemeine Anwendungszwecke und für Sonderzwecke auf einem Computer ausgeführt zu werden. Alle Funktionen und Verfahrensschritte können auf einem oder mehreren Computern implementiert sein, zu denen ein Prozessor, ein Speicher, Netzwerkverbindungen und entsprechende Eingabe/Ausgabe-Geräte gehören. Natürlich sind die verschiedenen Begrenzungszeichen (z. B. „/" und „:") lediglich Beispielzeichen, und Verweise auf die Begrenzungszeichen in den Patentansprüchen sind nicht als Einschränkung auf die hier abgebildete spezifische Syntax gedacht.

Claims

Verfahren zum Auflösen eines Namen einer Kommunikations-Endstelle (450), wobei der Name eine Vielzahl einzelner Namenkomponenten umfasst und das Verfahren die folgenden Schritte umfasst: (1) Senden (402) des Namens zu einem ersten Name-Server (440, 502); (2) Empfangen (403) einer ersten Adresse, die der Auflösung einer ersten Komponente des Namens entspricht, von dem ersten Name-Server; und (3) Senden (404) des Namens zu einem zweiten Name-Server (460, 503) an der ersten Adresse, um wenigstens eine andere der Komponenten des Namens zu einer zweiten Adresse aufzulösen, gekennzeichnet durch: Speichern der ersten und der zweiten Adresse in Korrelation zu den entsprechenden Komponenten des Namens in einem fokalen Cache (506).
Verfahren nach Anspruch 1, das des Weiteren die folgenden Schritte umfasst: (4) Empfangen der zweiten Adresse von dem zweiten Name-Server; und (5) Senden einer Mitteilung an die zweite Adresse zur Zustellung an die Kommunikations-Endstelle.
Verfahren nach Anspruch 1, wobei Schritt (3) des Weiteren den Schritt des Sendens des Namens zu dem zweiten Name-Server mit einer Mitteilung umfasst, die zur Zustellung an die Kommunikations-Endstelle bestimmt ist.
Verfahren nach Anspruch 1, wobei Schritt (2) des Weiteren den Schritt des Empfangens einer Internet-Protokoll-Adresse als die erste Adresse umfasst und wobei Schritt (3) des Weiteren den Schritt des Sendens zu einem Name-Server mit der IP-Adresse umfasst.
Verfahren nach einem der Ansprüche 1 bis 4, wobei der Name eine erste Komponente, die ein Protokollverfahren identifiziert, eine zweite Komponente, die einen Host-Server identifiziert, und eine dritte Komponente hat, die eine Ressource identifiziert.
Verfahren nach einem der Ansprüche 1 bis 5, das des Weiteren vor Schritt (1) den Schritt des Prüfens, um festzustellen, ob der Name in dem fokalen Cache gespeichert ist, und wenn dies der Fall ist, des Sendens einer Mitteilung an die Kommunikations-Endstelle ohne Ausführen der Schritte (2) und (3) umfasst.
Verfahren nach einem der Ansprüche 1 bis 6, das des Weiteren den Schritt des Speicherns einer Vielzahl von Teil-Namenauflösungsergebnissen für den gleichen Namen von einer Vielzahl verschiedener Name-Server in einem lokalen Cache umfasst.
Verfahren nach einem der Ansprüche 1 bis 7, das des Weiteren den Schritt des Anforderns von Beschleunigungsinformationen umfasst, die teilweise aufgelöste Namenergebnisse von dem zweiten Name-Server darstellen.
Verfahren nach Anspruch 1, wobei der erste Name-Server ein Domain-Name-Server ist, die empfangene erste Adresse eine erste Internet-Protokoll-Adresse ist, die empfangene zweite Adresse eine zweite Internet-Protokoll-Adresse eines zweiten virtuellen Name-Routers ist und der zweite Name-Server ein erster virtueller Name-Router ist, der so eingerichtet ist, dass er Mitteilungen empfängt und weiterleitet, wobei das Verfahren des Weiteren die folgenden Schritte umfasst: (4) Senden einer Mitteilung an den ersten virtuellen Name-Router, der der ersten Internet-Protokoll-Adresse entspricht; und (5) Weiterleiten der Mitteilung und des Namens zu dem zweiten virtuellen Name-Router, der der zweiten Internet-Protokoll-Adresse entspricht.
Verfahren nach Anspruch 9, das des Weiteren den Schritt des Speicherns einer Kopie eines teilweise aufgelösten Teils des Namens in dem ersten und dem zweiten virtuellen Name-Router umfasst.
Computerlesbares Medium, das durch Computer ausführbare Befehle umfasst, die, wenn sie von einem Computer ausgeführt werden, einen Namen einer Kommunikations-Endstelle (450) auflösen, wobei der Name eine Vielzahl einzelner Namenkomponenten umfasst und die Befehle die folgenden Schritte durchführen: (1) Senden (402) des Namens zu einem ersten Name-Server (440, 502); (2) Empfangen (403) einer ersten Adresse, die der Auflösung einer ersten Komponente des Namens entspricht, von dem ersten Name-Server; und (3) Senden (404) des Namens zu einem zweiten Name-Server (460, 503) an der ersten Adresse, um wenigstens eine andere der Komponenten des Namens zu einer zweiten Adresse aufzulösen, gekennzeichnet durch: Speichern der ersten und der zweiten Adresse in Korrelation zu den entsprechenden Komponenten des Namens in einem lokalen Cache (506).
Computerlesbares Medium nach Anspruch 11, wobei die durch Computer ausführbaren Befehle des Weiteren die folgenden Schritte durchführen: (4) Empfangen der zweiten Adresse von dem zweiten Name-Server; und (5) Senden einer Mitteilung an die zweite Adresse zur Zustellung zu der Kommunikations-Endstelle.
Computerlesbares Medium nach Anspruch 11, wobei die durch Computer ausführbaren Befehle des Weiteren den Schritt des Sendens des Namens zu dem zweiten Name-Server mit einer Mitteilung durchführen, die zur Zustellung an die Kommunikations-Endstelle bestimmt ist.
Computerlesbares Medium nach Anspruch 11, wobei die durch Computer ausführbaren Befehle des Weiteren den Schritt des Empfangens einer Internet-Protokoll-Adresse als die erste Adresse durchführen und wobei Schritt (3) den Schritt des Sendens zu einem Name-Server mit der IP-Adresse umfasst.
Computer, der einen Prozessor und einen Speicher umfasst, der durch Computer ausführbare Befehle enthält, die umfassen: eine erste Gruppe durch Computer ausführbarer Befehle, die einen Client umfassen, der eine Mitteilung an eine virtuelle Netzwerk-Endstelle (450) sendet; und eine zweite Gruppe durch Computer ausführbarer Befehle, die einen virtuellen Namensauflösungs-Proxy-Server umfassen und die folgenden Schritte durchführen: (1) Empfangen einer Mitteilung und eines Namens, der mit der virtuellen Netzwerk-Endstelle verbunden ist, von dem Client, wobei der Name eine Vielzahl von Komponenten umfasst; (2) Senden einer ersten Anforderung an einen ersten Name-Server um eine erste Komponente des Namens aufzulösen; (3) Empfangen einer ersten Adresse von dem ersten Name-Server (440, 502); und (4) Senden des Namens zu einem zweiten Name-Server (460, 503) mit einer Adresse, die der ersten Adresse entspricht, gekennzeichnet durch Speichern der ersten und der zweiten Adresse in Korrelation zu den entsprechenden Komponenten des Namens in einem lokalen Cache (506).
Verfahren zum Auflösen eines Namens einer Kommunikations-Endstelle in einem Computer-Netzwerk, wobei der Name eine Vielzahl einzelner Namenkomponenten umfasst, das die folgenden Schritte umfasst: (1) Senden einer Mitteilung, die zur Zustellung an die Kommunikations-Endstelle (450) bestimmt ist, die durch den Namen identifiziert wird, zu einem ersten virtuellen Name-Router; (2) Auflösen des Namens entsprechend einer ersten Komponente des Namens zu einer ersten Adresse durch den ersten virtuellen Name-Router; (3) Senden der Mitteilung zu einem zweiten virtuellen Name-Router, der der ersten Adresse entspricht; (4) Auflösen des Namens entsprechend einer zweiten Komponente des Namens zu einer zweiten Adresse durch den zweiten virtuellen Name-Router; und (5) Senden der Mitteilung zu der Kommunikations-Endstelle, die der zweiten Adresse entspricht, gekennzeichnet durch: Speichern der ersten und der zweiten Adresse in Korrelation zu den entsprechenden Komponenten des Namens in einem lokalen Cache (506).
Verfahren nach Anspruch 16, das des Weiteren den Schritt des Sendens der ersten Adresse von dem ersten virtuellen Name-Router zu einem Absender der Mitteilung umfasst.
Verfahren nach Anspruch 17, das des Weiteren den Schritt des Sendens der zweiten Adresse von dem zweiten virtuellen Name-Router zu dem Absender der Mitteilung umfasst.
Verfahren nach einem der Ansprüche 16 bis 18, wobei Schritt (2) den Schritt des Auflösens des Namens entsprechend einer ersten Komponente des Namens auf Basis einer Strategie umfasst, die einen bestimmten Namen in Abhängigkeit von einer Auflösungsstrategie, die in dem ersten virtuellen Name-Router gespeichert ist, verschieden auflöst.
Verfahren nach einem der Ansprüche 16 bis 19, das des Weiteren den Schritt des Weiterleitens der Mitteilung zu einer Vielzahl von Adressen in Abhängigkeit von einer Auflösungsstrategie umfasst, die in dem ersten virtuellen Name-Router gespeichert ist.
Verfahren nach einem der Ansprüche 16 bis 20, das des Weiteren den Schritt des Umwandelns eines Protokoll-Formats der Mitteilung in dem zweiten virtuellen Name-Router umfasst.
Verfahren nach einem der Ansprüche 16 bis 20, das des Weiteren den Schritt des Sendens einer Benachrichtigung über eine Namensänderung von dem zweiten virtuellen Name-Router zu dem ersten virtuellen Name-Router umfasst.
Verfahren nach einem der Ansprüche 16 bis 21, das des Weiteren den Schritt des Erzeugens und Zurückführens einer einzigartigen Namenskomponente, die wenigstens einen Teil des Namens enthält, auf Anforderung in dem ersten virtuellen Name-Router umfasst.
Verfahren nach einem der Ansprüche 16 bis 22, wobei Schritt (4) den Schritt des Bereitstellens eines Standard-Routings für den Namen umfasst.
Verfahren nach Anspruch 16, das des Weiteren vor Schritt (3) den Schritt des Umwandelns der Mitteilung von einem ersten Protokoll in ein zweites Protokoll auf Basis von Informationen umfasst, die in einem Teil des Namens enthalten sind.