DE69726701T2

DE69726701T2 - Verfahren zur Übertragung von Verbindungsverwaltungsinformationen in World Wide Web Anforderungen und Antworten

Info

Publication number: DE69726701T2
Application number: DE69726701T
Authority: DE
Inventors: Antonio Ocean DeSimone; Sandeep Matawan Sibal; David Hilton Middletown Shur
Original assignee: AT&T Corp
Current assignee: AT&T Corp
Priority date: 1996-11-05
Filing date: 1997-10-28
Publication date: 2004-10-14
Anticipated expiration: 2017-10-29
Also published as: CA2216266A1; EP0848527A1; DE69726701D1; HK1011587A1; EP0848527B1; US5905872A; JPH10150470A

Description

FACHGEBIET
Die vorliegende Erfindung betrifft Datenübertragung und Computernetzwerktechnik.
HINTERGRUND DER ERFINDUNG
Da das Internet mit einer ständig wachsenden Anzahl von miteinander verbundenen Netzen komplexer wird, laufen paketierte Anfragen von Client-Endgeräten und paketierte Server-Antworten über eine immer größer werdende Anzahl von Routern (Koppeleinrichtungen) zwischen den beiden Endpunkten. Es ist beispielsweise nicht ungewöhnlich, daß diese Pakete auf ihrer Route achtzehn oder mehr Router durchlaufen. Da das Internet keine garantierte Dienstqualität (QoS) bietet, können bestimmte Pakete verzögert werden oder verlorengehen, wenn sie durch diese Router laufen, wobei sich die Wahrscheinlichkeit dafür mit der Anzahl der Router, durch die die Pakete laufen, erhöht. Wenn ein Strom von Paketen, der von einem Server an einen Client übertragen wird, Echtzeit-Multimedia-Inhalt (Ton, Video und Daten) enthält, kann der empfangene Datenstrom fehlende oder verzögerte Pakete enthalten. In vielen Fällen können es solche fehlenden Pakete notwendig machen, daß der Client den Inhalt des vorher angeforderten URL erneut anfordert, so daß der Server den gesamten Inhalt erneut übertragen muß. Bei einem übertragenen Video-Clip bedeutet dies beispielsweise Zurückspulen eines Videobandes an seinen Anfang und erneutes Anschauen des gesamten Bandes, um den fehlenden Abschnitt zu sehen. Dies ist eine Verschwendung von Betriebsmitteln des Servers, des Netzes und der Zeit des Anwenders am Client.
In bestimmten Umgebungen, wo die Clients und die Server in dem gleichen Teilnetz sind, z. B. dem gleichen ATM-Netz oder ISDN-Netz (beispielsweise ein öffentliches Telefonwählnetz oder ein privates ISDN-Netz), kann das Herunterladen von Information vom Server zum Client an den Routern und somit an den Netzelementen vorbei erfolgen, die Verzögerung und Verlust bewirken, wenn die Sprechstellen an beiden Endpunkten mit der Adresse des jeweils anderen in ihrem gemeinsamen Teilnetz versehen sind. Wenn beispielsweise der Client und der Server die jeweils andere Adresse in der ISDN-Domäne kennen, kann im ISDN-Netz im Gegensatz zum Internet zumindest für die Übertragung der Information vom Server zum Client eine direkte Verbindung hergestellt werden. Das Hauptelement zur Verwendung Teilnetzzusammenschaltung ist also; Bereitstellen eines Endpunkts mit der Teilnetzadresse des anderen, von dem eine direkte Verbindung zwischen den Endpunkten im Teilnetz hergestellt werden kann.
Eine recht allgemeine Möglichkeit zur Erkennung solcher Teilnetzadressen besteht darin, spezielle Adreßübersetzungsserver im Internet-Netz zu plazieren. Clients und Server können diese Adreßübersetzer abfragen, um die Teilnetzadressen zu erhalten. Um Weitbereichszusammenschaltung zwischen Clients und Servern zu ermöglichen, ist eine erhebliche Infrastruktur notwendig, um ein solches Netz von Übersetzern an Ort und Stelle zu plazieren. Damit Clients und Server aus diesen Übersetzerservern im Internet Vorteile ziehen können, muß ferner die Software in den Endgeräten der Clients und der Hostserver modifiziert werden, um auf die Übersetzerserver zugreifen zu können, um die alternative Adreßinformation zu erhalten.
EP-A-0 732 835 offenbart ein Client-Server-Netz, das die Verbindung zwischen dem Internet und einem Wählnetz ermöglicht. Clientinformation, die vom Client an den Server über die Internetverbindung übertragen wird, wird verwendet, um es dem Server zu ermöglichen, den angeforderten Dienst bereitzustellen, indem eine Wählnetzverbindung zum Client unter Verwendung einer Kommunikationsnummer des Clients hergestellt wird, die aus der Clientinformation bestimmt wird.
Die vorliegende Erfindung stellt ein Verfahren zur Übertragung von Information in einem Datennetz bereit, das eine Vielzahl von Hosts miteinander verbindet und eine Vielzahl von Teilnetzen umfaßt, wobei das Verfahren Information von einem Server (104; 206; 302; 402; 502) überträgt, der mit einem ersten Teilnetz und einem zweiten Teilnetz (209; 310; 407; 510) verbunden ist und die folgenden Schritte umfaßt:
Empfangen einer Nachricht mit mindestens einem wahlfreien Kopffeld, das Steuerungsverwaltungsinformation enthält, in einem Server (104; 206; 302; 402; 502) über das erste Teilnetz, wobei die Steuerungsverwaltungsinformation eine Information umfaßt, die den Netztyp des zweiten Teilnetzes und eine Adresse im zweiten Teilnetz (209; 310; 407; 510) eines vorbestimmten Hosts (101; 201; 301; 401; 501-1, 501-2, 501-3) identifiziert; und
Verwenden der Information, die den Netztyp des zweiten Teilnetzes und die Adresse im zweiten Teilnetz (209; 310; 407; 510) des vorbestimmten Hosts identifiziert, die in der Nachricht empfangen wird, die das mindestens eine wahlfreie Kopffeld umfaßt, um eine direkte Verbindung in dem zweiten Teilnetz zwischen dem Server (104; 206; 302; 402; 502) und dem vorbestimmten Host (101; 201; 301; 401; 501-1, 501-2, 501-3) herzustellen.
Bevorzugte Merkmale der Erfindung sind in den beigefügten Ansprüchen ausgeführt.
Gemäß der vorliegenden Erfindung wird eine Verbindungsverwaltungsinformation zwischen Web-Clients und -Servern mit Hilfe von Nachrichten übertragen, die in wahlfreien Kopffeldern des HTTP-Protokollkopfs enthalten sind; wobei das HTTP-Protokoll ein Protokoll ist, durch das Web-Clients und -Server miteinander kommunizieren. Diese Felder in einer HTTP-Nachricht transportieren Information, die sich auf die Verbindungsverwaltung bezieht, die für eine direkte Kommunikation des Clients und des Servers entlang alternativer Wege verwendet wird, die eine Dienstqualität bereitstellen, die höher ist als das, was über das Internet erreicht werden kann.
Die Verbindungsverwaltungsinformation, die in die wahlfreien Kopffelder des HTTP-Protokollkopfs einbegriffen ist, weist Adreßinformation auf, die Adressen im Teilnetz angibt, z. B. ATM-Adressen, ISDN- oder POTS E.164-Nummern (herkömmliche Telefonnetznummern des Systems E.164) sowie alternative Internetprotokoll-(IP-)Adressen, die verwendet werden können, um über nichtständige oder Wählverbindungswege zu kommunizieren. Außerdem weist die Adreßinformation den Teilnetztyp auf, in dem die Adressen anwendbar sind. Beispiele für die letzteren können u. a. sein: IEEE 802-Netzfamilie (z. B. Ethernet oder Token-Ring), simuliertes LAN (ELAN), ATM, ISDN, FR (Rahmenweiterleitung) und virtuelle X.25-Verbindungsnetze. Bei diesen Teilnetzen, bei denen die QoS gesteuert werden kann, z. B. bei ATM- oder FR-Netzen, kann die Verbindungsverwaltungsinformation, die in den Kopffeldern übertragen wird, auch solche QoS-Information aufweisen wie etwa erforderliche Bandbreite, maximale Paketverzögerung, maximale Varianz der Paketverzögerung, maximaler Paketverlust und bevorzugter Sockettyp (z. B. Datagramm (UDP) oder Datenstrom (TCP)).
Die wahlfreien Köpfe in der HTTP-Nachricht, die die Verbindungsverwaltungsinformation enthalten, können von einem Server, einem Client oder einem dazwischen geschalteten System im Namen des Clients eingefügt werden, wobei der letztere als Proxy im World Wide Web (WWW) bezeichnet wird. Die HTTP-Nachrichten werden anfänglich über ein Router-Netz (z. B. das Internet) unter Verwendung mehrerer Router-Teilstrecken weitergegeben, und nicht in einer direkten Verbindung zwischen den Kommunikationsendpunkten. Der Web-Client- oder Web-Serverendpunkt verwendet dann die zusätzliche Adreßinformation, die im Kopf enthalten ist, um eine direkte Verbindung mit dem anderen Endpunkt herzustellen, um Dienste (z. B. die Weitergabe von Information) in der direkten Netzverbindung bereitzustellen. Als Alternative kann die Information, die an das andere Ende geliefert wird, aus einem dazwischengeschalteten System (IS) bestehen, z. B. der Proxy oder ein spezialisierter Routerknoten anstelle einer direkten Verbindung zwischen den beiden Endpunkten, einer der ursprünglichen Endpunkte kann eine direkte Verbindung im Teilnetz mit dem dazwischengeschalteten System herstellen. Wenn die darunter liegende Teilnetzschicht auf der Grundlage der QoS-Information arbeiten kann, kann die QoS-Information, die im Kopf enthalten ist, entweder von einem Client oder von einem Proxy, der im Namen des Clients handelt, verwendet werden. Ein Programm, das auf dem Client oder Proxy läuft, interpretiert die QoS-Antwortinformation und zeigt an, mit welcher QoS eine direkte Verbindung (bekannt als Durchschaltung) zwischen Client und Server herzustellen ist.
KURZBESCHREIBUNG DER ZEICHNUNGEN
1 zeigt den Informationsfluß zwischen einem Client und einem Server beim Ausbau einer anfänglichen Verbindung über das Internet zwischen den Endpunkten und einer nachfolgenden direkten Verbindung zwischen diesen als Antwort auf den Empfang einer HTTP-Anforderung eines Teilnetztyps und einer Adresse;
2 zeigt den Informationsfluß zwischen einem Client, einem Proxy und einem Server, wobei der Server eine direkte Verbindung zum Proxy aufbaut;
3 zeigt den Informationsfluß zwischen einem Client, einem Proxy und einem Server, wobei der Server eine direkte Verbindung zum Client ausbaut;
4 zeigt den Informationsfluß, wobei der Client die Durchschaltung zum Server auslöst; und
5 zeigt die Verwendung der vorliegenden Erfindung in einem Multimediakonferenz-Szenario.
AUSFÜHRLICHE BESCHREIBUNG
Mit Bezug auf 1 löst ein erster Host, Client-Endgerät 101, der mit einem LAN 102 verbunden ist, eine HTTP-Anforderung über das Internet 103 an einen zweiten Host, Server 104, aus, der sich in einem LAN 105 befindet. Diese Anforderung wird an den Server 104 über eine Serie von Teilstrecken 115 bis 121 über Router (106 und 107) "außerhalb" des Internet und über Router (108, 109, 110 und 111) "innerhalb" des Internet weitergeleitet. Gemäß der vorliegenden Erfindung weist die HTTP-Anforderung Felder auf, die Verbindungsverwaltungsinformation darstellen. Insbesondere weisen die HTTP-Kopffelder den Typ des Teilnetzes auf, mit dem der Client 101 auch verbunden ist, sowie die Teilnetzadresse des Clients 101. Eine solche Teilnetzadreßinformation kann verwendet werden, um eine direkte Verbindung zwischen dem Client und den Server-Hosts aufzubauen, wenn diese Hosts dem gleichen "logischen" Teilnetztyp zugeordnet sind (z. B. wenn beide Hosts ISDN-Schnittstellen haben oder beide Teile eines gemeinsamen ATM-Internet-Netzes sind).
Wenn der Server 104 die HTTP-Aufforderung empfängt, baut er direkt eine Verbindung (122) in einem Teilnetz auf. Wenn diese Durchschaltung hergestellt ist, erfolgt der Datenfluß im Teilnetz direkt vom Server 104 zum Client 101, ohne daß die Weiterleitung von Paketen durch die IP-Router erfolgen muß. In Abhängigkeit von den Fähigkeiten der Endpunkte kann die Durchschaltung zwischen dem Server 104 und dem Client 101 aus einer IP-Protokoll-Kommunikation (die in das Teilnetzprotokoll eingebettet ist) oder einer Ursprungsmoduskommunikation unter Verwendung lediglich des Teilnetzprotokollmechanismus bestehen. Die letztere Methode kann bei auftauchenden Anwendungsschnittstellen, z. B. WINSOCK II, verwendet werden, die in der Lage sind, mehrere Netzwerktechnologien unterhalb einer abstrakten Anwendungsprogrammierungsschnittstelle (API) zu unterstützen. Die erstere Methode wird verwendet, wenn nur Vorläufer-APIs, z. B. WINSOCK I, verfügbar sind.
Wenn, wie bereits ausgeführt, das darunter liegende Teilnetz in der Lage ist, mit der QoS-Information zu arbeiten, kann die QoS-Information, die im HTTP-Kopf enthalten ist, entweder von einem Client oder einem Proxy, der im Namen des Clients handelt, verwendet werden. Ein Programm, das auf dem Client oder Proxy läuft, interpretiert dann die QoS-Antwortinformation und zeigt an, mit welcher QoS eine Durchschaltung zwischen Client und Server hergestellt werden sollte.
Die nachstehend beschriebenen Szenarios zeigen, wie die vorliegende Erfindung für Multimedia-Abrufdienst-Anwendungen auf WWW-Basis verwendet werden kann, wobei ein Client eine Datei, die Ton- und/oder Videoinformation enthält, zum Abspielen von einem WWW-Server herunterlädt.
Es wird in diesen Szenarien angenommen, daß der Client eine Standard-IP API verwendet. Der Kommunikationsweg in jedem Szenario ist asymmetrisch. Die Kommunikation vom Client zum Server erfolgt nach dem vom Standard-IP geleiteten Weg. Die Kommunikation vom Server zum Client/Proxy erfolgt auf dem abgekürzten Weg. Mit Ausnahme des nachstehend beschriebenen Falles des clientseitigen Proxys, sind keine Änderungen auf der Client-Seite notwendig.
Mit Bezug auf 2 gibt ein Client 201 eine HTTP-Anforderung 202 an einen Proxy 203 über einen Router 204 im Internet 220 weiter, was als die Schritte S1 und S2 bezeichnet ist. Der Proxy 203 fügt den Teilnetztyp und die Teilnetzadresse (SA) eines dazwischenliegenden Systems (IS) als wahlfreien Kopf hinzu und gibt eine modifizierte HTTP-Anforderung 205 an den HTTP-Server 206 weiter. Diese Anforderung läuft über die Router 207 und 208 in den Schritten S3, S4 und S5, um den Server 206 zu erreichen. Wie in der Anforderung 205 ausgeführt wird, ist der angezeigte Teilnetztyp ISDN, mit einer Beispiel-SA, nämlich 9089491234. Dieses Szenario beschreibt den speziellen Fall, wo die IS-Adresse die Adresse des Proxy selbst ist. Wenn der Server 206 die modifizierte Proxy-Anforderung 205 empfängt, baut er eine direkte Verbindung zum Proxy 203 im ISDN-Teilnetz 209 auf die über ISDN-Vermittlungsstellen 210 und 211 führt (Schritt S6). Im Schritt S7 antwortet der Server 206 auf die Proxy-Anforderung 205 mit einer Antwort 212, die sowohl Steuerinformation als auch das angeforderte Medienobjekt enthält. Die Antwort, die vom Proxy 203 empfangen wird, wird an den Client 201 über den Router 204 in den Schritten S8 und S9 weitergeleitet.
In dem Szenario in 3 wird eine direkte Verbindung zwischen einem HTTP-Server 302 und einem Client 301 aufgebaut, anstatt über den Proxy 303, durch den der Client die HTTP-Anforderungen weitergibt und normale Internetantworten empfängt. In 3 gibt der Client 301 die HTTP-Anforderung (nicht dargestellt, aber mit der Anforderung 202 in 2 identisch) an den Proxy 303 über den Router 304 im Internet 320 weiter (Schritt S1 und S2). Der Proxy 303 fügt den Teilnetztyp, mit dem er verbunden ist (in diesem Szenario ISDN) und die SA des Clients 301 als wahlfreien Kopf hinzu und gibt die modifizierte Anforderung an den HTTP-Server 302 über die Router 305 und 306 im Internet (S3, S4 und S5) weiter. Der Server 302 antwortet auf die Proxy-Anforderung mit einer Bestätigung an den Proxy 303, und zwar zurück über die Router 305 und 306, daß die Anforderung Erfolg hatte (oder nicht), und mit einer Information in bezug auf den Typ der Hilfsanwendung, die vom Client 301 benötigt wird (Schritt S6). Im Schritt S7 gibt der Proxy 303 diese Information über den Router 304 zurück an den Client 301. Als Antwort auf diese Information startet der Client 301 eine Hilfsanwendung, um den Inhaltstyp zu behandeln, der vom Server eintraf (Schritt S8). Im Schritt S9 richtet der Server 302 eine Durchschaltungsverbindung zum Client 301 im ISDN-Teilnetz 310 ein, mit der der Client 301 und der Server 302 über ISDN-Vermittlungsstellen 307, 308 und 309 verbunden werden. Der Client 301 zeigt daraufhin dem Server 302 über das ISDN-Teilnetz 310 an, daß er bereit ist, Information zu empfangen (Schritt S10). Die Information fließt dann auf der ISDN-Durchschaltungsverbindung vom Server 302 zum Client 301.
In den oben beschriebenen Szenarien löst der Server die Durchschaltung zum Client aus. In dem in 4 gezeigten Szenario löst der Client/Proxy die Durchschaltung zum Server aus. Es wird angenommen, daß der Client 401 und der Proxy 403 in der gleichen Maschine gemeinsam resident sind. Es wird auch angenommen, daß sowohl der Client 401 als auch der Server 402 eine API von der Art der WINSOCK II verwenden, wobei die API die Auswahl verschiedener Netze für die Datenübertragung ermöglicht. Dadurch kann der Client 401 direkt mit dem Server 402 unter Verwendung der Transportprotokollebene entsprechend der gewählten Teilnetzadresse (SA) unter Verwendung einer Wechselsprechverbindung kommunizieren. Dieses Szenario könnte auch unter Verwendung einer herkömmlichen IP API, z. B. WINSOCK I, durchgeführt werden. Für den letzteren Fall ist ein Extraschritt notwendig, nämlich der Client 401 muß einen spezifischen Leitwegtabelleneintrag, nämlich eine Route zum Server über die direkte Verbindung hinzufügen.
In 4 gibt der Client 401 eine HTTP-Anforderung an den Proxy 403 über eine Interprozeßkommunikation weiter (Schritt S1). Der Proxy 402 fügt dann den Teilnetztyp (ST) des Clients 401 (in diesem Szenario ISDN) hinzu und gibt die modifizierte Anforderung an den HTTP-Server 402 im Internet 420 über die Router 404, 405 und 406 weiter (Schritte S2, S3, S4 und S5). Der Server 402 gibt daraufhin seine eigene Teilnetzadresse (SN) im Teilnetz entsprechend dem wahlfreien ST-Kopffeld zurück, das in der Anforderung (in diesem Beispiel ISDN) empfangen wird. Diese SN wird an den Client 401 im Internet über die Router 406, 405, 404 und den Proxy 403 in den Schritten S6, S7, S8, S9 und S10 zurückgegeben. Der clientseitige Proxy 403 richtet dann eine Wechselsprech-Durchschaltungsverbindung zum Server 402 über das ISDN-Teilnetz 407 über die ISDN-Vermittlungstellen 408, 409 und 410 in den Schritten S11 und S12 ein. Der Client 401 fordert Information vom Server 402 über diese direkte Verbindung im Schritt S13 an. Der Server 402 antwortet über diese gleiche direkte Wechselsprechverbindung.
Wenn der Client 401 und der Proxy 403 nicht gemeinsam in der gleichen Maschine resident sind, aber über den Router 404 kommunizieren, kann die Durchschaltung zwischen dem Proxy 402 und dem Server 402 erfolgen. In diesem Fall, der nicht gesondert dargestellt ist, aber auf den in 4 wiederum Bezug genommen wird, ist das dazwischenliegende System (IS) identisch mit dem Proxy 403. Der Proxy 403 empfängt über den Router 404 die HTTP-Anforderung vom Client 401. Der Proxy 403 fügt dann seinen eigenen Teilnetztyp als wahlfreien Kopf hinzu und gibt die modifizierte Anforderung an den HTTP-Server 402 über die Router 405 und 406 weiter. Der Server 402 gibt seine eigene Teilnetzadresse (entsprechend dem gegebenen ST) an den Proxy 403 in einem wahlfreien Kopf weiter. Der Proxy 403 richtet dann eine Wechselsprechverbindung zum Server 403 ein, und der Proxy 403 kommuniziert danach mit dem Client 401 über den Router 404.
Die vorliegende Erfindung kann auf Multimediakonferenz-Szenarios angewendet werden. Mit Bezug auf 5 sind drei Clients 501-1 bis 501-3 in einer Konferenz über eine Multimediabrücke/Server 502 zusammenzuschalten. Für jeden Client 501-i (i ∊ 1, 2, 3) sendet der Client 501-i oder sein zugehöriger Proxy (nicht dargestellt) seinen Teilnetztyp und die Adresse im ISDN-Teilnetz 510 (und wahlfrei eine Konferenzkennung) an den WWW-Server 503 in einem wahlfreien Kopf über die entsprechenden Netzrouter im Internet 520 (z. B. 504, 505, 506, 507 und 508) im Schritt S1-i. Der Server 503 sendet über das Internet die Teilnetzadresse im ISDN-Teilnetz 510 jedes Clients 501-i an die Brücke/Server 502 im Schritt S2. Die Brücke 502 stellt dann eine direkte Wechselsprechverbindung im ISDN-Teilnetz 510 mit jedem Client 501-i im Schritt S3-i her. Die Kommunikation erfolgt dann zwischen den Clients 501-1 bis 501-3 über die Brücke 502 im ISDN-Teilnetz 510 über die ISDN-Vermittlungsstellen 511, 512, 513 und 514. Es sind in 5 drei Clients dargestellt, die miteinander kommunizieren, man beachte aber, daß dies ohne weiteres auf jede Anzahl von Clients N erweitert werden könnte.
Als Alternative, aber nicht gesondert dargestellt, wobei jedoch auf 5 Bezug genommen werden kann, kann jeder Client 501-i (i ∊ 1, 2, 3) (oder sein Proxy) seine Teilnetzadresse an den Server 503 in einem wahlfreien Kopf senden. Der Server 503 sendet dann eine Teilnetzadresse der Brücke 502 (und wahlfrei eine Konferenzkennung) an den Client 501-i (oder seinen Proxy) in einem wahlfreien Kopf. Jeder Client 501-i (oder sein Proxy) stellt dann eine Wechselsprechverbindung mit der Brücke 502 her.
Die drei (oder allgemeiner N) Clients können den Wunsch haben, ohne Verwendung einer Multimediabrücke, sondern vielmehr über ein Teilnetz, das eine Einweg-Punkt-zu-Mehrpunkt-Verbindungsfähigkeit ermöglicht, z. B. ein ATM-Teilnetz, miteinander zu konferieren. Bei diesem Szenario sendet jeder Client i (i ∊ 1, 2, 3) (oder sein Proxy) seine Teilnetzadresse an einen Server im wahlfreien Kopf. Der Server sendet dann eine Liste von Teilnetzadressen jedes Clients i an alle sendenden Clients j (j ≠ i) in wahlfreien Köpfen. Für jeden Client j (j ≠ i) stellt der Client j (oder sein Proxy) eine 1-bis-3-Mehrpunktverbindung zu jedem Client i her.
Die oben beschriebenen Ausführungsformen sind Darstellungen der Prinzipien der vorliegenden Erfindung. Weitere Ausführungsformen sind für den Fachmann denkbar, ohne den Schutzbereich der vorliegenden Erfindung zu verlassen, wie er in den beigefügten Ansprüchen definiert ist.

Claims

Verfahren zur Übertragung von Information in einem Datennetz, das eine Vielzahl von Hosts miteinander verbindet und eine Vielzahl von Teilnetzen umfaßt, wobei das Verfahren Information von einem Server (104; 206; 302; 402; 502) überträgt, der mit einem ersten Teilnetz und einem zweiten Teilnetz (209; 310; 407; 510) verbunden ist und die folgenden Schritte umfaßt: Empfangen einer Nachricht mit mindestens einem wahlfreien Kopffeld, das Steuerungsverwaltungsinformation enthält, in einem Server (104; 206; 302; 402; 502) über das erste Teilnetz, wobei die Steuerungsverwaltungsinformation eine Information umfaßt, die den Netztyp des zweiten Teilnetzes und eine Adresse im zweiten Teilnetz (209; 310; 407; 510) eines vorbestimmten Hosts (101; 201; 301; 401; 501-1, 501-2, 501-3) identifiziert; und Verwenden der Information, die den Netztyp des zweiten Teilnetzes und die Adresse im zweiten Teilnetz (209; 310; 407; 510) des vorbestimmten Hosts identifiziert, die in der Nachricht empfangen wird, die das mindestens eine wahlfreie Kopffeld umfaßt, um eine direkte Verbindung in dem zweiten Teilnetz zwischen dem Server (104; 206; 302; 402; 502) und dem vorbestimmten Host (101; 201; 301; 401; 501-1, 501-2, 501-3) herzustellen.
Verfahren nach Anspruch 1, wobei der vorbestimmte Host ein Client ist.
Verfahren nach Anspruch 1, wobei der vorbestimmte Host ein Proxy für einen Client ist.
Verfahren nach Anspruch 1, wobei die Steuerungsverwaltungsinformation ferner Information zum Angeben einer Dienstgüte in der Direktverbindung in dem zweiten Teilnetz umfaßt.
Verfahren nach einem der vorhergehenden Ansprüche, wobei das mindestens eine optionale Kopffeld ein HTTP-Kopf ist.