-
HINTERGRUND DER ERFINDUNG
-
Die
vorliegende Erfindung betrifft die Datenkommunikation in einem Computernetzwerk.
Die vorliegende Erfindung betrifft insbesondere verbesserte Verfahren
und Vorrichtungen, um es einem Client-Computer in einem Computernetzwerk
mit einer Client-Server-Architektur zu ermöglichen, das vorteilhafteste
Protokoll unter den verfügbaren
Protokollen zur Verwendung bei der Kommunikation mit dem Server,
unabhängig
davon, ob in dem Netzwerk Firewalls oder Proxies existieren, automatisch
zu ermitteln.
-
Client-Server-Architekturen
sind Computerfachleuten wohlbekannt. Beispielsweise können in einem
typischen Computernetzwerk ein oder mehrere Client-Computer mit
einer beliebigen Anzahl von Server-Computern verbunden sein. Client-Computer beziehen
sich typischerweise auf Endgeräte
oder Personalcomputer, durch die Endbenutzer mit dem Netzwerk wechselwirken.
Server-Computer stellen typischerweise Knoten in dem Computernetzwerk dar,
an denen sich Daten, Anwendungsprogramme und dergleichen befinden.
Server-Computer können auch
Knoten in dem Netzwerk zum Weiterleiten von Daten, Programmen und
dergleichen von anderen Servern zu den anfordernden Client-Computern
darstellen.
-
Zum
Erleichtern der Erörterung
zeigt 1 ein Computernetzwerk 100, das beispielsweise
eine Teilmenge eines gemeinhin als Internet bekannten internationalen
Computernetzwerks darstellt. Wie wohlbekannt ist, stellt das Internet
ein wohlbekanntes internationales Computernetzwerk dar, das unter
anderem verschiedene militärische
Institutionen, Regierungsinstitutionen, Erziehungsinstitutionen,
ertragsfreie Institutionen, Industrie- und Finanzinstitutionen, Gewerbebetriebe
und Einzelpersonen verbindet. In 1 sind ein
Server 102, ein Server 104 und ein Client-Computer 106 dargestellt.
Der Server-Computer 104 ist vom Client-Computer 106 durch
eine Firewall 108 getrennt, die entweder in Soft ware oder
in Hardware implementiert sein kann und sich in einem Computer und/oder
einer Schaltung zwischen dem Client-Computer 106 und dem Server-Computer 104 befinden
kann.
-
Die
Firewall 108 kann, wie Fachleuten bekannt ist, spezifiziert
werden, um zu verhindern, dass bestimmte Daten- und/oder Protokolltypen durch sie hindurchtreten.
Die spezifischen Daten und/oder Protokolle, die von der Firewall 108 durchgelassen
oder blockiert werden, hängen
von den Parametern der Firewall ab, die typischerweise von einem
Systemadministrator festgelegt werden, der für die Wartung und Sicherheit
des Client-Computers 106 und/oder anderer damit verbundener
Computer, beispielsweise anderer Computer in einem Lokalbereichsnetzwerk,
verantwortlich ist. Beispielsweise kann die Firewall 108 so
eingerichtet werden, dass sie verhindert, dass TCP-, UDP- oder HTTP-(Transmission
Control Protocol, User Datagram Protocol bzw. Hypertext Transfer
Protocol)-Daten und/oder andere Protokolle zwischen dem Client-Computer 106 und
dem Server 104 übertragen
werden. Die Firewalls könnten
so konfiguriert werden, dass sie spezifische TCP- oder UDP-Sitzungen,
beispielsweise eine abgehende TCP-Verbindung zu bestimmten Ports,
UDP-Sitzungen zu bestimmten Ports und dergleichen, zulassen.
-
Ohne
eine Firewall kann jeder beliebige Daten- und/oder Protokolltyp
zwischen einem Client-Computer und einem Server-Computer übermittelt werden, falls geeignete
Software und/oder Hardware verwendet werden. Beispielsweise befindet sich
der Server 102 auf derselben Seite der Firewall 108 wie
der Client-Computer 106, so dass die Firewall 108 nicht
in dem Kommunikationsweg zwischen dem Server 102 und dem
Client-Computer 106 angeordnet
ist. Dementsprechend können,
falls überhaupt,
nur wenige der Protokolle, die der Client-Computer 106 zum
Kommunizieren mit dem Server 102 verwenden kann, blockiert
werden.
-
Wie
Fachleuten wohlbekannt ist, können manche
Computernetzwerke mit Proxies, d.h. Softwarecodes oder Hardware schaltungen,
die die indirekte Kommunikation zwischen einem Client-Computer und
einem Server um eine Firewall herum erleichtern, versehen werden.
Mit Bezug auf 1 sei beispielsweise bemerkt,
dass der Client-Computer 106 mit dem Server 104 über einen
Proxy 120 kommunizieren kann. Durch den Proxy 120 können HTTP-Daten,
die andernfalls für
den Zweck dieses Beispiels durch die Firewall 108 blockiert
werden können,
zwischen dem Client-Computer 106 und dem Server-Computer 104 übertragen
werden.
-
Bei
manchen Computernetzwerken können ein
oder mehrere Protokolle zur Kommunikation zwischen dem Client-Computer
und dem Server-Computer verfügbar
sein. Für
bestimmte Anwendungen ist jedoch häufig eines dieser Protokolle
vorteilhafter, d.h. geeigneter als andere. Beispielsweise ist es
bei Anwendungen, bei denen ein Rendern von Echtzeitdaten ausgeführt wird
(beispielsweise ein Rendern von Audio-, Video- und/oder Kommentardaten,
wenn sie von einem Server übermittelt
werden), sehr vorteilhaft, dass der diese Anwendung ausführende Client-Computer
ein Protokoll auswählt,
das das höchste
Maß an
Kontrolle über
die Übertragung
von Datenpaketen ermöglicht
und/oder das Auftreten der Datenübertragung
bei der höchstmöglichen
Rate zulässt.
Dies liegt daran, dass diese Anwendungen in Bezug auf ihre Bitrate
und ihre Verbindungszuverlässigkeitsanforderungen
ziemlich anspruchsvoll sind. Dementsprechend hängt die Qualität der gerenderten
Daten, beispielsweise der abgespielten Video- und/oder Audioclips, häufig davon
ab, ob der Benutzer den Client-Computer erfolgreich konfiguriert
hat, um Daten vom Server-Computer unter Verwendung des vorteilhaftesten
verfügbaren
Protokolls zu empfangen.
-
Im
Stand der Technik erfordert die Auswahl des vorteilhaftesten Protokolls
zur Kommunikation zwischen dem Client-Computer 106 und dem Server-Computer 104 typischerweise
ein hohes Maß an technischen
Kenntnissen auf der Seite des Benutzers des Client-Computers 106.
Beispielsweise ist es im Stand der Technik typischerweise erforderlich, dass
der Benutzer des Client-Computers 106 die Topologie des
Computernetzwerks 100, die zur Verwendung mit dem Netzwerk
verfügbaren
Protokolle und/oder die Protokolle, die die Firewall 108 durchlaufen
können,
versteht, bevor erwartet werden kann, dass dieser Benutzer seinen
Client-Computer 106 zur Kommunikation konfiguriert.
-
Es
ist jedoch wahrscheinlich, dass das Niveau an technischem Wissen über das
hinausgeht, das ein durchschnittlicher Benutzer eines Client-Computers 106 typischerweise
besitzt. Dementsprechend finden es Benutzer im Stand der Technik häufig schwierig,
ihre Client-Computer selbst für
einfache Kommunikationsanforderungen mit dem Netzwerk zu konfigurieren.
Die Schwierigkeiten können beispielsweise
während
der anfänglichen
Einrichtung oder immer dann, wenn es Änderungen in der Topologie
des Computernetzwerks 100 und/oder in der zum Übertragen
von Daten zwischen dem Client-Computer 106 und dem Server 104 verwendeten Technologie
gibt, auftreten. Typischerweise ist kostspielige Unterstützung von
Experten erforderlich, falls diese Unterstützung in dem geographischen
Gebiet des Benutzers überhaupt
verfügbar
ist.
-
Weiterhin
gibt es selbst dann, wenn der Benutzer den Client-Computer 106 zur
Kommunikation mit dem Server 104 über die Firewall 108 und/oder den
Proxy 120 konfigurieren kann, keine Sicherheit, dass der
Benutzer des Client-Computers 106 unter den verfügbaren Protokollen
die vorteilhafteste Protokollkommunikation (beispielsweise in Bezug
auf die Datenübertragungsrate,
die Übertragungssteuerung und
dergleichen) geeignet ausgewählt
hat. Wie zuvor erwähnt
wurde, ist die Fähigkeit
zur Verwendung des vorteilhaftesten Protokolls zur Kommunikation, wenngleich
sie für
die meisten Netzwerkanwendungen erwünscht ist, bei solchen Anwendungen,
wie dem Rendering von Echtzeitdaten (beispielsweise dem Rendering
von Audio-, Video- und/oder Kommentardaten, wenn sie vom Server
empfangen werden) besonders kritisch. Falls ein nicht ganz optimales
Protokoll zur Kommunikation gewählt wird,
kann die Qualität
der gerenderten Daten, beispielsweise der Videoclips und/oder Audioclips,
leiden.
-
In
Bezug auf das vorstehend Erwähnte
gibt es gewünschte
verbesserte Techniken, um es einem Client-Computer in einem Client-Server-Netzwerk
zu ermöglichen,
das vorteilhafteste Protokoll zur Kommunikation mit einem Server-Computer
wirksam, automatisch und geeignet auszuwählen.
-
In
EP-A-0 613 274 ist eine Socket-Struktur für einen gleichzeitigen Mehrfach-Protokollzugriff
offenbart. Alle Protokolle, die möglicherweise verwendet werden
könnten,
um Daten zu senden oder zu empfangen, werden zum Erzeugen einer
Mehrfach-Socket-Protokollstruktur verwendet. Diese Struktur wird
von einem Client-Computer zu einem Server gesendet. Der Server erwägt dann
die verfügbaren
Protokolle der Reihe nach und richtet eine Kommunikationsverbindung
zwischen dem Server und dem Client-Computer auf der Grundlage des
ersten der enthaltenen Protokolle, die der Server verwenden kann,
ein.
-
Gemäß einem
Aspekt der vorliegenden Erfindung ist ein Verfahren zum automatischen
Ermitteln eines vorteilhaftesten Protokolls zur Kommunikation zwischen
einem Client-Computer und einem Server über ein Computernetzwerk nach
Anspruch 1 vorgesehen.
-
Gemäß einem
anderen Aspekt der vorliegenden Erfindung ist eine Computervorrichtung
zum automatischen Ermitteln einer vorteilhaftesten Protokollkommunikation
zwischen der Computervorrichtung und einem entfernten Computer über ein
Computernetzwerk nach Anspruch 14 vorgesehen.
-
Diese
und andere Merkmale der vorliegenden Erfindung werden nachstehend
in weiteren Einzelheiten in der detaillierten Beschreibung der Erfindung
und in Zusammenhang mit den folgenden Figuren beschrieben.
-
KURZBESCHREIBUNG DER ZEICHNUNG
-
Zum
Erleichtern der Erörterung
zeigt 1 ein Computernetzwerk, das beispielsweise einen
Abschnitt eines gemeinhin als Internet bekannten internationalen
Computernetzwerks darstellt.
-
2 ist
ein Blockdiagramm eines als Beispiel dienenden Computersystems zum
Ausführen der
automatischen Ermittlungstechnik gemäß einer Ausführungsform
der Erfindung.
-
3 zeigt
gemäß einer
Ausführungsform die
Steuer- und Datenverbindungen
zwischen einer Clientanwendung und einem Server-Computer, wenn in
dem Netzwerk keine Firewall bereitgestellt ist.
-
4 zeigt
eine andere Netzwerkanordnung, bei der Steuer- und Datenverbindungen
durch eine Firewall eingerichtet sind.
-
Die 5A–B zeigen
eine andere Netzwerkanordnung, wobei Mediasteuerbefehle und Mediadaten
zwischen einem Client-Computer und einem Server-Computer unter Verwendung
des HTTP-Protokolls übertragen
werden können.
-
Die 5C–D zeigen
eine andere Netzwerkanordnung, wobei mehrere HTTP-Steuer- und Datenverbindungen
durch einen einzigen HTTP-Port multiplexiert sind.
-
6 zeigt
eine andere Netzwerkanordnung, wobei Steuer- und Datenverbindungen
zwischen der Clientanwendung und dem Server-Computer über einen
Proxy übermittelt
werden.
-
7 zeigt
gemäß einer
Ausführungsform der
vorliegenden Erfindung ein vereinfachtes Flussdiagramm, in dem die
Schritte der erfindungsgemäßen Technik
zur automatischen Ermittlung dargestellt sind.
-
8A zeigt
gemäß einem
Aspekt der vorliegenden Erfindung die am Ausführen des UDP-Protokoll-Threads
aus 7 beteiligten Schritte.
-
8B zeigt
gemäß einem
Aspekt der vorliegenden Erfindung die am Ausführen des TCP-Protokoll-Threads
aus 7 beteiligten Schritte.
-
8C zeigt
gemäß einem
Aspekt der vorliegenden Erfindung die am Ausführen des HTTP-Protokoll-Threads
aus 7 beteiligten Schritte.
-
8D zeigt
gemäß einem
Aspekt der vorliegenden Erfindung die am Ausführen des HTTP-80-Protokoll-Threads
aus 7 beteiligten Schritte.
-
8E zeigt
gemäß einem
Aspekt der vorliegenden Erfindung die am Ausführen des HTTP-8080-Protokoll-Threads
aus 7 beteiligten Schritte.
-
9 zeigt
gemäß einer
Ausführungsform der
vorliegenden Erfindung die am Ausführen des Steuer-Threads aus 7 beteiligten
Schritte.
-
DETAILLIERTE BESCHREIBUNG
DER BEVORZUGTEN AUSFÜHRUNGSFORMEN
-
Die
vorliegende Erfindung wird nun detailliert mit Bezug auf einige
bevorzugte Ausführungsformen erklärt, die
in der anliegenden Zeichnung dargestellt sind. In der folgenden
Beschreibung werden zahlreiche spezifische Einzelheiten dargelegt,
um ein gründliches
Verständnis
der vorliegenden Erfindung bereitzustellen. Fachleute werden jedoch
verstehen, dass die vorliegende Erfindung auch ohne einige oder
alle dieser spezifischen Einzelheiten verwirklicht werden kann.
Unter anderen Umständen
wurden wohlbekannte Prozessschritte nicht detailliert beschrieben,
um die vorliegende Erfindung nicht unnötig zu verdecken.
-
Gemäß einem
Aspekt der vorliegenden Erfindung ist der Client-Computer in einem
heterogenen Client-Server-Computernetzwerk (beispielsweise der Client-Computer 106 in 1)
mit einem automatischen Ermittlungsmechanismus versehen. Wenn er
ausgeführt
wird, ermöglicht
der automatische Ermittlungsmechanismus vorteilhafterweise, dass
der Client-Computer 106 wirksam und automatisch das vorteilhafteste
Protokoll zur Kommunikation zwischen dem Client-Computer und seinem
Server auswählt.
Sobald das vorteilhafteste Protokoll ausgewählt wurde, werden Parameter,
die zu dem ausgewählten
Protokoll gehören,
gespeichert, um es dem Client-Computer zu ermöglichen, in künftigen
Sitzungen dasselbe ausgewählte
Protokoll zur Kommunikation zu verwenden.
-
Gemäß einer
besonders vorteilhaften Ausführungsform
verwendet der erfindungsgemäße automatische
Ermittlungsmechanismus gleichzeitig mehrere Threads über mehrere
Verbindungen, um die Kommunikation mit dem Server-Computer, beispielsweise
dem Server 104, einzuleiten. Jeder Thread verwendet vorzugsweise
ein anderes Protokoll und fordert den Server-Computer auf, unter
Verwendung des diesem Thread zugeordneten Protokolls dem Client-Computer
zu antworten. Beispielsweise kann der Client-Computer 106 unter
Verwendung des automatischen Ermittlungsmechanismus fünf verschiedene
Threads unter Verwendung des TCP-, UDP-, eines von HTTP- und HTTP-Proxy-, HTTP-Über-Port-(Multiplex)-80-
und HTTP-Über-Port-(Multiplex)-8080-Protokolls
einleiten, um den Server 104 zum Antworten aufzufordern.
-
Nach
dem Empfang einer Anfrage antwortet der Server 104 unter
Verwendung desselben Protokolls, das dem Thread zugeordnet ist,
auf dem die Anfrage ankommt, mit Daten. Falls ein oder mehrere Protokolle
blockiert werden und den Server 104 nicht erreichen (beispielsweise
infolge einer Firewall), wird natürlich keine Antwort, bei der
das blockierte Protokoll verwendet wird, vom Server 104 zum
Client-Computer 106 gesendet. Weiterhin können auch einige
der vom Server 104 zum Client-Computer 106 gesendeten
Protokolle blockiert werden. Dementsprechend kann der Client-Computer
nur eine Teilmenge der vom Server 104 gesendeten Antworten empfangen.
-
Gemäß einer
Ausführungsform überwacht der
Client-Computer 106 die Menge der empfangenen Antworten.
Falls das vordefinierte "beste" Protokoll empfangen
wird, wird dieses Protokoll dann vom Client-Computer 106 für die Kommunikation
ausgewählt.
Das vordefinierte "beste" Protokoll kann vorab vom
Benutzer und/oder vom Anwendungsprogramm definiert werden. Falls
das vordefinierte "beste" Protokoll jedoch
blockiert wird (wenn beispielsweise die Anfrage vom Client-Computer gesendet
wird oder die Antwort vom Server gesendet wird), kann das vorteilhafteste
Protokoll einfach aus der Menge der vom Client-Computer wieder empfangenen
Protokolle ausgewählt
werden. Gemäß einer
Ausführungsform kann
die Auswahl unter der Menge der innerhalb eines vordefinierten Zeitraums,
nachdem die Anfragen parallel ausgesendet wurden, wieder vom Client-Computer
empfangenen Protokolle vorgenommen werden.
-
Die
Auswahl des vorteilhaftesten Protokolls zur Kommunikation aus den
vom Client-Computer 106 empfangenen Protokollen kann entsprechend
einer vordefinierten Priorität
vorgenommen werden. Beispielsweise kann bei der Echtzeit-Datenrenderinganwendung
das UDP-Protokoll dem TCP-Protokoll vorgezogen werden, das wiederum
dem HTTP-Protokoll vorgezogen werden kann. Dies liegt daran, dass
das UDP-Protokoll typischerweise eine höhere Datenübertragungsrate handhaben kann
und es dem Client-Computer 106 ermöglichen kann, ein höheres Maß an Kontrolle über die Übertragung
von Datenpaketen auszuüben.
-
Wenngleich
HTTP-Daten heutzutage für
die Verwendung bei der Übertragung
von Webseiten beliebt sind, tritt bei ihnen typischerweise eine
höhere Anzahl
von Zusatzbits auf, wodurch sie für die Übertragung von Echtzeitdaten
weniger wirksam werden als das UDP-Protokoll. Wie bekannt ist, ist
das HTTP-Protokoll
typischerweise über
dem TCP-Protokoll angeordnet. Das zugrunde liegende TCP-Protokoll
behandelt die Übertragungs-
und Neuübertragungsanforderungen
individueller Datenpakete automatisch. Dementsprechend neigt das
HTTP-Protokoll dazu,
den Grad an Kontrolle, den der Client-Computer 106 über die Übertragung
der Datenpakete zwischen dem Server 104 und dem Client-Computer 106 hat,
zu verringern. Natürlich
können
andere Prioritätsschemata
für verschiedene
Anwendungen oder sogar für
verschiedene Echtzeit-Datenrendering-Anwendungen
existieren.
-
Gemäß einer
Ausführungsform
wird, wenn der Client-Computer 106 für die Kommunikation
mit dem Server 104 zum ersten Mal installiert und initialisiert
wird, der automatische Ermittlungsmechanismus aufgerufen, um es
dem Client-Computer 106 zu ermöglichen, Übertragungsanforderungen in
der zuvor erörterten
Weise parallel zu senden (beispielsweise unter Verwendung verschiedener
Protokolle über
verschiedene Verbindungen). Nachdem der Server 104 über mehrere
Verbindungen bzw. Protokolle mit Daten geantwortet hat und das vorteilhafteste
Protokoll vom Client-Computer 106 für eine Kommunikation ausgewählt wurde
(entsprechend einer vordefinierten Priorität), werden dann die dem ausgewählten Protokoll
zugeordneten Parameter für
die künftige
Kommunikation gespeichert.
-
Sobald
das vorteilhafteste Protokoll ausgewählt wurde, kann der automatische
Ermittlungsmechanismus deaktiviert werden, und die weitere Kommunikation
zwischen dem Client-Computer 106 und dem
Server 104 kann unter Verwendung des ausgewählten vorteilhaftesten
Protokolls ohne weiteres Aufrufen des automatischen Ermittlungsmechanismus
fortgesetzt werden. Falls sich die Topologie des Computernetzwerks 100 ändert und
die Kommunikation unter Verwendung des zuvor ausgewählten "vorteilhaftesten" Protokolls nicht
mehr angemessen ist, kann der automatische Ermittlungsmechanismus wieder
ausgeführt
werden, um es dem Client-Computer 106 zu ermöglichen,
ein neues "vorteilhaftestes" Protokoll zur Kommunikation
mit dem Server 104 zu ermitteln. Gemäß einer Ausführungsform
kann der Benutzer des Client-Computers 106, falls dies
erwünscht
ist, den automatischen Ermittlungsmechanismus zu einer bestimmten
Zeit initialisieren, um den Client-Computer 106 in die
Lage zu versetzen, das "vorteilhafteste" Protokoll zur Kommunikation
mit dem Server 104 zu aktualisieren (wenn der Benutzer des
Client-Computers 106 beispielsweise Gründe hat, zu vermuten, dass
das zuvor ausgewählte "vorteilhafteste" Protokoll nicht
mehr das optimale Protokoll zur Kommunikation ist).
-
Der
erfindungsgemäße automatische
Ermittlungsmechanismus kann entweder in Software oder in Hardware,
beispielsweise über
einen IC-Chip, implementiert werden. Falls er in Software implementiert
ist, kann er von einer beliebigen Anzahl von Computern ausgeführt werden,
die in der Lage sind, als ein Client-Computer in einem Computernetzwerk zu
funktionieren. 2 ist ein Blockdiagramm eines als
Beispiel dienenden Computersystems 200 zum Ausführen der
automatischen Ermittlungstechnik gemäß einer Ausführungsform
der Erfindung. Das Computersystem 200 oder ein analoges
System kann verwendet werden, um entweder einen Client oder einen
Server eines Computernetzwerks zu implementieren. Das Computersystem 200 umfasst
einen Digitalcomputer 202, einen Anzeigebildschirm (oder
Bildschirm) 204, einen Drucker 206, ein Diskettenlaufwerk 208,
ein Festplattenlaufwerk 210, eine Netzwerkschnittstelle 212 und
eine Tastatur 214. Der Digitalcomputer 202 umfasst
einen Mikroprozessor 216, einen Speicherbus 218,
einen Direktzugriffsspeicher (RAM) 220, einen Nurlesespeicher
(ROM) 222, einen peripheren Bus 224 und eine Tastatursteuereinrichtung 226.
Der Digitalcomputer 200 kann ein Personalcomputer (beispielsweise
ein Apple-Computer, z.B. ein Apple Macintosh, ein IBM-Personalcomputer
oder ein dazu kompatibler Computer), ein Workstationcomputer (in
der Art einer Workstation von Sun Microsystems oder Hewlett-Packard) oder ein
Computer eines anderen Typs sein.
-
Der
Mikroprozessor 216 ist ein digitaler Vielzweckprozessor,
der den Betrieb des Computersystems 200 steuert. Der Mikroprozessor 216 kann ein
Einzelchipprozessor sein, oder er kann mit mehreren Komponenten
implementiert sein. Unter Verwendung aus dem Speicher abgerufener
Anweisungen steuert der Mikroprozessor 216 den Empfang und
die Manipulation eingegebener Daten und die Ausgabe und die Anzeige
von Daten auf Ausgabevorrichtungen.
-
Der
Speicherbus 218 wird vom Mikroprozessor 216 verwendet,
um auf den RAM 220 und den ROM 222 zuzugreifen.
Der RAM 220 wird vom Mikroprozessor 216 als ein
allgemeiner Speicherbereich und als ein Notizblockspeicher verwendet,
und er kann auch zum Speichern eingegebener und verarbeiteter Daten
verwendet werden. Der ROM 222 kann zum Speichern vom Mikroprozessor 216 verfolgter
Anweisungen oder Programmcode sowie anderer Daten verwendet werden.
-
Der
periphere Bus 224 wird verwendet, um auf die vom Digitalcomputer 202 verwendeten
Eingabe-, Ausgabe- und Speichervorrichtungen zuzugreifen. Gemäß der beschriebenen
Ausführungsform umfassen
diese Vorrichtungen den Anzeigebildschirm 204, die Druckervorrichtung 206,
das Diskettenlaufwerk 208, das Festplattenlaufwerk 210 und die
Netzwerkschnittstelle 212, die zum Verbinden des Computers 200 mit
dem Netzwerk eingesetzt wird. Die Tastatursteuereinrichtung 226 wird
zum Empfangen der Eingabe von der Tastatur 214 und zum
Senden decodierter Symbole für
jede gedrückte Taste
zum Mikroprozessor 216 über
den Bus 228 verwendet.
-
Der
Anzeigebildschirm 204 ist eine Ausgabevorrichtung, die
Bilder von durch den Mikroprozessor 216 über den
peripheren Bus 224 oder durch andere Komponenten im Computersystem 200 bereitgestellten
Daten anzeigt. Die Druckervorrichtung 206 stellt, wenn
sie als ein Drucker arbeitet, ein Bild auf einem Blatt Papier oder
einer ähnlichen
Oberfläche
bereit. Andere Ausgabevorrichtungen, wie ein Plotter, ein Typograph
usw., können
an Stelle der Druckervorrichtung 206 oder zusätzlich zu
dieser verwendet werden.
-
Das
Diskettenlaufwerk 208 und das Festplattenlaufwerk 210 können zum
Speichern verschiedener Datentypen verwendet werden. Das Diskettenlaufwerk 208 erleichtert
das Transportieren solcher Daten zu anderen Computersystemen, und
das Festplattenlaufwerk 210 ermöglicht einen schnellen Zugriff
auf große
Mengen gespeicherter Daten.
-
Der
Mikroprozessor 216 arbeitet mit einem Betriebssystem zusammen,
um Computercode auszuführen
und Daten zu erzeugen und zu verwenden. Der Computercode und die
Daten können
im RAM 220, im ROM 222 oder im Festplattenlaufwerk 220 oder
sogar auf einem anderen Computer im Netzwerk vorhanden sein. Der
Computercode und die Daten könnten
auch auf einem entfernbaren Programmmedium vorhanden sein oder nach
Bedarf in das Computersystem 200 geladen oder darin installiert werden.
Entfernbare Programmmedien sind beispielsweise CD-ROMs, PC-Karten,
Disketten und Magnetbänder.
-
Die
Netzwerkschnittstellenschaltung 212 wird verwendet, um
Daten über
ein mit anderen Computersystemen verbundenes Netzwerk zu senden und
davon zu empfangen. Eine Schnittstellenkarte oder eine ähnliche
Vorrichtung und geeignete vom Mikroprozessor 216 implementierte
Software können verwendet
werden, um das Computersystem 200 mit einem existierenden
Netzwerk zu verbinden und Daten entsprechend Standardprotokollen
zu übertragen.
-
Die
Tastatur 214 wird von einem Benutzer zur Eingabe von Befehlen
und anderen Anweisungen in das Computersystem 200 verwendet.
Es können auch
andere Typen von Benutzereingabevorrichtungen in Zusammenhang mit
der vorliegenden Erfindung verwendet werden. Beispielsweise können Zeigevorrichtungen,
wie eine Computermaus, ein Trackball, ein Stift oder ein Tablett,
zum Manipulieren eines Zeigers auf einem Bildschirm eines Vielzweckcomputers
verwendet werden.
-
Die
Erfindung kann auch als ein computerlesbarer Code auf einem computerlesbaren
Medium verwirklicht werden. Das computerlesbare Medium ist eine
Datenspeichervorrichtung, die Daten speichern kann, welche anschließend von
einem Computersystem gelesen werden können. Beispiele computerlesbarer
Medien umfassen Nurlesespeicher, Direktzugriffsspeicher, CD-ROMs, Magnetbänder und optische
Datenspeichervorrichtungen. Der computerlesbare Code kann auch über ein
mit dem Netzwerk gekoppeltes Computersystem verteilt werden, so dass
der computerlesbare Code in verteilter Weise gespeichert und ausgeführt wird.
-
Die
nachstehenden 3–6 zeigen zum
Erleichtern der Erörterung
einige mögliche
Anordnungen für
die Übertragung
und den Empfang von Daten in einem Computernetzwerk. Die Anordnungen
unterscheiden sich abhängig
davon, welches Protokoll verwendet wird, und abhängig von der Konfiguration
des Netzwerks selbst. 3 zeigt gemäß einer Ausführungsform
die Steuer- und Datenverbindungen zwischen einer Clientanwendung 300 und
einem Server 302, wenn in dem Netzwerk keine Firewall bereitgestellt
ist.
-
Die
Clientanwendung 300 kann beispielsweise die ausführbaren
Codes für
das Ausführen
eines Echtzeit-Datenrendering-Programms
in der Art des von VXtreme, Inc. aus Sunnyvale, Kalifornien verfügbaren Web
Theater Client 2.0 darstellen. In dem Beispiel aus 3 umfasst
die Clientanwendung 300 den erfindungsgemäßen automatischen
Ermittlungsmechanismus und kann ein Plug-In-Softwaremodul darstellen,
das über
einem Browser 306 installiert werden kann. Der Browser 306 kann
beispielsweise das Anwendungsprogramm darstellen, das der Benutzer
des Client-Computers einsetzt, um in dem Netzwerk zu navigieren.
Beispielsweise kann der Browser 306 eines von den beliebten
Internet-Browserprogrammen, wie NetscapeTM von
Netscape Communications Inc. aus Mountain View, Kalifornien, oder
Microsoft Explorer von Microsoft Corporation aus Redmond, Washington,
darstellen.
-
Wenn
der automatische Ermittlungsmechanismus der Clientanwendung 300 im
Browser 306 ausgeführt
wird (beispielsweise während
der Einrichtung der Clientanwendung 300), sendet die Clientanwendung 300 eine
Steueranforderung über
eine Steuerverbindung 308 zum Server 302. Wenngleich typischerweise
mehrere Steueranforderungen unter Verwendung verschiedener Protokolle
parallel über mehrere
Steuerverbindungen gesendet werden, wie zuvor erörtert wurde, ist in 3 nur
eine Steueranforderung dargestellt, um die Erläuterung zu erleichtern.
-
Das
zum Senden der Steueranforderung über die Steuerverbindung 308 verwendete
Protokoll kann beispielsweise TCP oder HTTP sein. Falls das UDP-Protokoll
vom Server angefordert wird, kann die Anforderung vom Client unter
Verwendung beispielsweise des TCP-Protokolls über die Steuerverbindung gesendet
werden. Zunächst
kann jede Steueranforderung von der Clientanwendung 300 beispielsweise den
Servernamen, der den Server 302 identifiziert, den Port, über den
die Steuerverbindung eingerichtet werden kann, und den Namen des
von der Clientanwendung 300 angeforderten Video stroms enthalten. Der
Server 302 antwortet dann mit Daten über die Datenverbindung 310.
-
In 3 wird
angenommen, dass keine Proxies und/oder Firewalls existieren. Dementsprechend antwortet
der Server 302 unter Verwendung desselben Protokolls, das
in der Anforderung eingesetzt wurde. Falls die Anforderung TCP verwendet,
kann der Server 302 jedoch versuchen, unter Verwendung entweder
von UDP oder TCP-Datenverbindungen zu antworten (abhängig von
den spezifischen Eigenschaften der Anforderung). Die Antwort wird über die Datenverbindung 310 zur
Clientanwendung gesendet. Falls das von der Clientanwendung empfangene Protokoll
anschließend
als das "vorteilhafteste" Protokoll ausgewählt wird,
kann die anschließende
Kommunikation zwischen der Clientanwendung 300 und dem
Server 302 über
die Steuerverbindung 308 und die Datenverbindung 310 geschehen.
Von der Clientanwendung 300 über die Steuerverbindung 308 gesendete
anschließende
Steueranforderungen können
beispielsweise Stopp, Abspielen, schneller Vorlauf, Rückspulen,
Pause, Pause aufheben und dergleichen enthalten. Diese Steueranforderungen
können
vom Server 302 verwendet werden, um die Übertragung
des Datenstroms vom Server 302 zur Clientanwendung 300 über die
Datenverbindung 310 zu steuern.
-
Es
sei bemerkt, dass, wenngleich in 3 zur Vereinfachung
der Darstellung nur eine Steuerverbindung und eine Datenverbindung
dargestellt ist, während
einer Datenrendering-Sitzung mehrere Steuer- und Datenverbindungen
existieren können, bei
denen dasselbe Protokoll verwendet wird. Es können mehrere Steuer- und Datenverbindungen
erforderlich sein, um die mehreren Datenströme (beispielsweise Audio, Video,
Kommentar) zu behandeln, die bei einer bestimmten Datenrendering-Sitzung
erforderlich sein können.
Falls gewünscht,
können
mehrere Clientanwendungen 300 innerhalb des Browsers 306 installiert
werden, um beispielsweise gleichzeitig mehrere Videoclips zu rendern,
die jeweils ihren eigenen Ton und ihre eigenen Kommentare aufweisen.
-
4 zeigt
eine weitere Netzwerkanordnung, bei der Steuer- und Datenverbindungen über eine
Firewall eingerichtet sind. Wie zuvor erwähnt wurde, kann eine Firewall
Richtlinien haben, die das Durchlassen bestimmter Typen von Daten
und/oder Protokollen beschränken
oder unterbinden. In 4 ist eine Firewall 400 zwischen
der Clientanwendung 300 und einem Server 402 angeordnet.
Bei der Ausführung
sendet die Clientanwendung 300 eine Steueranforderung unter
Verwendung eines gegebenen Protokolls über die Firewall 400 zum
Server 402. Der Server 402 antwortet dann, wiederum über die
Firewall 400, mit Daten über eine Datenverbindung 410.
-
Falls
die Daten und/oder das Protokoll über die Firewall 400 vom
Client-Computer empfangen werden können, kann die Clientanwendung 300 dann in
demselben Protokoll, das in der Anforderung verwendet wird, Daten
vom Server 402 empfangen (über die Datenverbindung 408).
Wie zuvor kann der Server, falls in der Anforderung das TCP-Protokoll verwendet
wird, mit Datenverbindungen entweder für das TCP- oder das UDP-Protokoll antworten
(abhängig
von den spezifischen Eigenschaften der Anforderung). Protokolle,
die eine Firewall durchqueren können,
können
eines oder mehrere von UDP, TCP und HTTP aufweisen.
-
Gemäß einem
Aspekt der vorliegenden Erfindung kann das HTTP-Protokoll zum Senden
bzw. Empfangen von Mediadaten (Video, Audio, Kommentare oder dergleichen)
zwischen dem Client und dem Server verwendet werden. 5A ist
eine Darstellung aus dem Stand der Technik, worin dargestellt ist,
wie ein Client-Browser unter Verwendung eines für die Kommunikation zugewiesenen
Ports mit einem Web-Server kommunizieren kann. In 5 ist ein
Web-Server 550 dargestellt, der das Softwaremodul zum Zuführen von
Webseiten zu einer Browseranwendung 552 darstellt. Der
Web-Server 550 kann ein beliebiger der im Handel erhältlichen
Web-Server sein, die beispielsweise von Netscape Communications
Inc. aus Mountain View, Kalifornien oder von Microsoft Corporation
aus Redmond, Washington verfügbar
sind. Die Browseranwendung 552 stellt beispielsweise den
Netscape-Browser von der erwähnten
Netscape Communications, Inc. oder eine ähnliche geeignete Browseranwendung
dar.
-
Durch
die Browseranwendung 552 kann der Benutzer beispielsweise
durch Senden einer HTTP-Anforderung (beispielsweise GET), die die URL
(uniform resource locator) enthält,
die die Webseitendatei identifiziert, zu einer bestimmten Einheit gehörende Webseiten
erhalten. Die über
die Steuerverbindung 553 gesendete Anforderung kann durch den
HTTP-Port 554 am Web-Server 550 ankommen. Der
HTTP-Port 554 kann jeden beliebigen Port darstellen, durch
den die HTTP-Kommunikation
ermöglicht
wird. Der HTTP-Port 554 kann auch den Standardport für den Austausch
von Webseiten mit Client-Browsern
darstellen. Der HTTP-Standardport kann beispielsweise entweder den
Port 80 oder den Port 8080 auf dem Web-Server 550 darstellen. Wie bekannt
ist, können
einer oder beide dieser Ports auf dem Web-Server 550 für die Webseitenkommunikation
verfügbar
sein, selbst wenn sich zwischen dem Web-Server 550 und
der Client-Browseranwendung 552 Firewalls befinden, welche
ansonsten den gesamten HTTP-Verkehr in anderen Ports blockieren. Unter
Verwendung der angelieferten URL kann der Web-Server 550 dann
die gewünschte
Webseite bzw. die gewünschten
Webseiten erhalten, um sie über
eine Datenverbindung 556 zur Client-Browseranwendung 552 zu
senden.
-
Gemäß einer
Ausführungsform
der Erfindung wird das HTTP-Protokoll
zum Übermitteln
von Mediabefehlen von einer Browseranwendung oder einem Browser-Plug-In
zum Server verwendet. Mediabefehle sind beispielsweise ABSPIELEN,
STOPP, RÜCKSPULEN,
SCHNELLER VORLAUF und PAUSE. Der Server-Computer kann beispielsweise
einen Web-Server darstellen. Der Server-Computer kann auch einen Videoserver
zum Übermitteln
von Videodaten zum Client-Computer darstellen. Durch die Verwendung
des HTTP-Protokolls kann der Client-Computer erfolgreich Mediasteueranforderungen über einen
HTTP-Port senden und Mediadaten darüber empfangen. Falls der Standard-HTTP-Port, beispielsweise
Port 80 oder Port 8080, spezifiziert ist, kann der Client selbst
dann erfolgreich Mediasteueranforderungen senden und Mediadaten
empfangen, wenn sich zwischen dem Server-Computer und dem Client-Computer eine Firewall
oder ein HTTP-Proxy befindet, wodurch ansonsten der gesamte Verkehr blockiert
wird, der nicht das HTTP-Protokoll verwendet. Beispielsweise ermöglichen
diese Firewalls oder HTTP-Proxies nicht das Hindurchtreten gewöhnlicher
TCP- oder UDP-Pakete.
-
Wie
Fachleuten wohlbekannt ist, definiert das beispielsweise durch "Internet Request
For Comments RFC 1945" (T.
Berners-Lee u. a.) spezifizierte HTTP-Protokoll typischerweise nur
drei Typen von Anforderungen, die vom Client-Computer zum Server
zu senden sind, nämlich
GET, POST und HEAD. Beispielsweise ist in RFC 1945 spezifiziert,
dass der POST-Befehl aus einer Anforderungszeile, einem oder mehreren
Kopfteilen und einem Einheitskörper zusammengesetzt
ist. Für
das Senden von Mediabefehlen, wie ABSPIELEN, RÜCKSPULEN usw., sendet die Erfindung
gemäß einer
Ausführungsform
den Mediabefehl als Teil des Einheitskörpers des HTTP-POST-Befehls.
Der Mediabefehl kann in jedem beliebigen Format oder Protokoll vorliegen
und beispielsweise in demselben Format vorliegen wie dasjenige,
das verwendet wird, wenn Firewalls kein Problem darstellen und das
einfache TCP-Protokoll verwendet werden kann. Dieses Format kann
beispielsweise RTSP (Real Time Streaming Protocol) sein.
-
Wenn
ein Server eine HTTP-Anforderung erhält, antwortet er dem Client
mit einer HTTP-Antwort. Antworten bestehen typischerweise aus einer
Statuszeile, einem oder mehreren Kopfteilen und einem Einheitskörper. Gemäß einer
Ausführungsform
dieser Erfindung wird die Antwort auf die Mediabefehle als der Einheitskörper der
Antwort zu der ursprünglichen
HTTP-Anforderung gesendet, die den Mediabefehl übertragen hat.
-
5B zeigt
diese Verwendung von HTTP zum Senden beliebiger Mediabefehle. In 5B kann
die Plug-In-Anwendung 560 innerhalb der Client-Browseranwendung 562 versuchen, Mediadaten (beispielsweise
Video, Audio, Kommentare oder dergleichen) zu empfangen, indem sie
zuerst über
eine Steuerverbindung 565 eine HTTP-Anforderung zu einem
Server 564 sendet. Beispielsweise könnte ein RÜCKSPULEN-Befehl als ein HTTP-Paket 570 mit der
folgenden Form vom Client 560 zum Server 564 gesendet
werden: "POST/HTTP/1.0<Einheitskörper, der
den Rückspulbefehl
in einem geeigneten Mediaprotokoll enthält>".
Der Server kann auf diese Anforderung mit einer HTTP-Antwort 572 der
folgenden Form antworten: "HTTP/1.0
200ok<Einheitskörper, der
die Rückspulantwort
in einem geeigneten Mediaprotokoll enthält>".
-
Das
HTTP-Protokoll kann auch zum Senden von Mediadaten über Firewalls
verwendet werden. Der Client kann eine GET-Anforderung zum Video-Server
senden, und der Video-Server kann die Videodaten als den Einheitskörper der
HTTP-Antwort auf diese GET-Anforderung senden.
-
Manche
Firewalls können
in Bezug auf HTTP-Daten restriktiv sein und das Hindurchtreten von
HTTP-Paketen nur an einem bestimmten Port, beispielsweise Port 80
und/oder Port 8080, ermöglichen. 5C zeigt
eine solche Situation. In diesem Fall können die Steuerung und die
Datenkommunikation für
die verschiedenen Datenströme,
beispielsweise Audiodaten, Video-daten
und/oder Kommentare, die verschiedenen Rendering-Sitzungen (und verschiedenen Clients)
zugeordnet sind, an der Clientanwendung 300 unter Verwendung
eines herkömmlichen
Multiplexercodes und/oder einer Schaltung 506 multiplexiert
werden, bevor sie über
einen Port 502 gesendet werden (der beispielsweise den
HTTP-Port 80 oder den HTTP-Port 8080 darstellen kann). Die erfindungsgemäße kombinierte
Verwendung des HTTP-Protokolls und des Multiplexers zum Übertragen
der Mediasteuerung und von Mediadaten wird als das HTTP-Multiplexprotokoll
bezeichnet und kann verwendet werden, um diese Daten über Firewalls
zu senden, die nur HTTP-Verkehr auf verschiedenen Ports, beispielsweise
Port 80 oder Port 8080, zulassen.
-
Am
Server 402, der beispielsweise den Server 104 aus 1 darstellt,
können
ein herkömmlicher
Demultiplexercode und/oder eine Schaltung 508 zum Decodieren
der empfangenen Datenpakete verwendet werden, um zu identifizieren,
welchem Strom die Steueranforderung zugeordnet ist. Ebenso können vom
Server 402 zur Clientanwendung 300 gesendete Daten
vorab am Server 402, beispielsweise unter Verwendung von
herkömmlichem
Multiplexercode und/oder der Schaltung 510, multiplexiert
werden. Die multiplexierten Daten werden dann über den Port 502 gesendet.
An der Clientanwendung 300 können die multiplexierten Daten
durch herkömmlichen
Demultiplexercode und/oder eine Schaltung 512 decodiert
werden, um zu identifizieren, welchem Strom die empfangenen Datenpakete
zugeordnet sind (Audio, Video oder Kommentare).
-
Das
Multiplexieren und Demultiplexieren am Client und/oder am Server
können
beispielsweise durch die Verwendung des Anforderungs-URL-Teils der
Anforderungszeile von HTTP-Anforderungen
erleichtert werden. Wie vorstehend erwähnt wurde, ist der Aufbau von
HTTP-Anforderungen in RFC 1945 beschrieben. Die Anforderungs-URL
kann beispielsweise den Strom identifizieren, der den gesendeten Daten
und/oder der gesendeten Steueranforderung zugeordnet ist. Gemäß einer
Ausführungsform
können
die zusätzlichen
Informationen in der Anforderungs-URL im HTTP-Kopfteil lediglich
ein oder wenige Bits ausmachen, die der von der Clientanwendung 300 zum
Server 402 gesendeten HTTP-Anforderung hinzugefügt sind.
-
Zum
weiteren Erleichtern der Erörterung
der erfindungsgemäßen HTTP-Multiplextechnik
kann nun auf 5D Bezug genommen werden. In 5D kann
die Plug-In-Anwendung 660 innerhalb der Client-Plug-In-Anwendung 660 versuchen,
Mediadaten (beispielsweise Video, Audio, Kommentare oder dergleichen)
zu empfangen, indem sie zuerst über
eine Steuerverbindung 665 eine Steueranforderung 670 zu
einem Server 664 sendet. Die Steueranforderung ist eine
HTTP-Anforderung, die am HTTP-Standardport 654 am Server 664 ankommt. Wie
zuvor erwähnt
wurde, kann der Standard-HTTP-Port gemäß einer Ausführungsform
entweder Port 80 oder Port 8080 sein.
-
Bei
einem Beispiel nimmt die Steueranforderung 670 vom Client-Plug-In 660 die
Form eines Befehls "POST/12469
HTTP/1.0<Einheitskörper>" an, wodurch dem Server (durch die Bezeichnung
12469 als die Anforderungs-URL) angegeben wird, dass dies eine Steuerverbindung
ist. Der Einheitskörper enthält, wie
vorstehend beschrieben wurde, binäre Daten, wodurch der Video-Server
informiert wird, dass der Client-Plug-In 660 einen bestimmten Video- oder
Audioclip anzeigen möchte.
Softwarecodes innerhalb des Servers 664 können verwendet
werden, um dieser bestimmten Anforderung von diesem bestimmten Client
eine eindeutige Kennung zuzuweisen.
-
Für die Zwecke
der Erörterung
sei angenommen, dass der Server 664 einer Videodatenverbindung
zwischen sich und der Client-Plug-In-Anwendung 660 eine
eindeutige Kennung 35122 zuordnet und einer Audiodatenverbindung
zwischen sich und der Client-Plug-In-Anwendung eine eindeutige Kennung
29999 zuordnet. Die eindeutige Kennung wird dann als eine Nachricht 672 vom
Server 664, wiederum über
den erwähnten
HTTP-Standardport
unter Verwendung einer Datenverbindung 667, zur Client-Plug-In-Anwendung 660 übermittelt.
Der Einheitskörper
der Nachricht 672 enthält
unter anderem, und wie detailliert bei 673 dargestellt
ist, die Kennung der Audio- und/oder der Videositzung. Es sei bemerkt,
dass die eindeutige Kennung für
jede Datenverbindung (beispielsweise jede Audio-, Video- und Kommentarverbindung)
jeder Client-Plug-In-Anwendung eindeutig ist (weil es mehrere Client-Plug-In-Anwendungen
geben kann, die versuchen, über
denselben Port zu kommunizieren).
-
Sobald
die Verbindung eingerichtet wurde, wird dieselbe eindeutige Kennnummer
vom Client verwendet, um HTTP-Steueranforderungen an den Server 664 auszugeben.
Beispielsweise kann die Client-Plug-In-Anwendung 660 einen
Befehl "GET/35122
HTTP/1.0" oder "POST/35122 HTTP/1.0<Einheitskörper, der
binäre
Daten mit dem RÜCKSPULEN-Mediabefehl
enthält>" ausgeben, um eine Videodatei anzufordern
oder die Videodatei zurückzuspulen.
Wenngleich der Rückspulbefehl
in den 5A–5D verwendet
wird, um die Erörterung zu
erleichtern, können
natürlich
auch andere Mediabefehle, beispielsweise schneller Vorlauf, Pause, Echtzeit-Abspielen,
Live-Abspielen oder dergleichen, in dem Einheitskörper gesendet
werden. Es sei bemerkt, dass die eindeutige Kennung an Stelle der
Anforderungs-URL oder zusätzlich
zu dieser verwendet wird, um die Anforderungs-URL zu qualifizieren.
-
Sobald
der Befehl vom Server 664 empfangen wurde, kann die eindeutige
Kennnummer (beispielsweise 35122) vom Server zum Demultiplexieren
des Befehls verwendet werden, um den Befehl einem bestimmten Client
und einer bestimmten Datendatei zuzuordnen. Diese eindeutige Kennnummer kann
auch über
denselben HTTP-Standardport 654 auf dem Server 664 an
den HTTP-Kopfteil von HTTP-Antworten angehängt werden, der vom Server 664 in
der Client-Plug-In-Anwendung 660 festgelegt wurde, um es
der Client-Plug-In-Anwendung 660 zu ermöglichen, festzustellen, ob
ein HTTP-Datenpaket einem gegebenen Datenstrom zugeordnet ist.
-
Vorteilhafterweise
ermöglicht
die Erfindung, dass Mediasteuerbefehle und Mediadaten über den Standard-HTTP-Port,
gemäß einer
Ausführungsform beispielsweise
Port 80 oder Port 8080, zwischen dem Client-Computer und dem Server-Computer übertragen
werden, selbst wenn HTTP-Pakete andernfalls durch eine zwischen
dem Client-Computer und dem Server-Computer angeordnete Firewall
blockiert werden. Dadurch, dass jeder Steuerverbindung und jeder
Datenverbindung zu jedem Client eine eindeutige Kennung zugeordnet
wird, wird vorteilhafterweise ermöglicht, dass eine Mehrfachsteuerung
von Datenverbindungen (von einem oder mehreren Clients) über denselben
Standard-HTTP-Port am Server, vorzugsweise durch Umgehen der Firewall,
eingerichtet wird. Weil sowohl der Server als auch der Client den Demultiplexercode
und/oder die Schaltung aufweisen, wodurch eine bestimmte eindeutige
Kennung in einen bestimmten Datenstrom aufgelöst wird, wird dadurch vorteilhafterweise
eine mutliplexierte Datenkommunikation erleichtert.
-
Es
kann bei manchen Netzwerken infolge strenger Firewall-Richtlinien
nicht möglich
sein, die Firewall zu durchqueren. Wie früher erwähnt wurde, kann es in diesen
Situationen möglich
sein, zu ermöglichen,
dass die Clientanwendung unter Verwendung eines Proxy mit einem
Server kommuniziert. 6 zeigt diese Situation, wobei
die Clientanwendung 300 einen Proxy 602 zum Kommunizieren
mit dem Server 402 verwendet. Die Verwendung des Proxy 602 kann
erforderlich sein, weil die Clientanwendung 300 ein Protokoll
verwenden kann, das durch die Firewall 604 streng verboten
ist. Die Identität
des Proxy 602 kann im Browserprogramm 306, beispielsweise
von Netscape, gefunden werden, weil dabei der Proxy zum Herunterladen
von Webseiten verwendet wird, oder er kann durch den Benutzer selbst
konfiguriert werden. Typische Protokolle, die einen Proxy, beispielsweise
den Proxy 602, für
die Kommunikation verwenden, umfassen HTTP und UDP.
-
Gemäß einer
Ausführungsform
der vorliegenden Erfindung werden mehrere Protokolle, die für die Kommunikation
zwischen einem Server-Computer und einem Client-Computer eingesetzt
werden, während
der automatischen Ermittlung parallel ausprobiert. Mit anderen Worten
können
die in den 3, 4, 5C und 6 dargestellten
Verbindungen durch den Client-Computer gleichzeitig und parallel über verschiedene
Steuerverbindungen versucht werden. Durch diese Steuerverbindungen wird
der Server aufgefordert, mit verschiedenen Protokollen zu antworten.
-
Falls
das vordefinierte "beste" Protokoll (entsprechend
irgendeiner vordefinierten Protokollpriorität bestimmt) durch die Clientanwendung
vom Server empfangen wird, kann die automatische Ermittlung gemäß einer
Ausführungsform
sofort enden, und das "beste" Protokoll wird für die sofortige
Kommunikation ausgewählt.
Bei einer Echtzeit-Datenrendering-Anwendung wird UDP als das "beste" Protokoll angesehen,
und der Empfang von UDP-Daten durch den Client kann die Beendigung
der automatischen Ermittlung auslösen.
-
Falls
das "beste" Protokoll nach einem
vordefinierten Zeitraum nicht empfangen worden ist, wird das vorteilhafteste
Protokoll (beispielsweise in Bezug auf die Datenübertragungsrate und/oder die Übertragungssteuerung)
aus dem Satz der vom Client empfangenen Protokolle ausgewählt. Das
ausgewählte
Protokoll kann dann zur Kommunikation zwischen dem Client und dem
Server verwendet werden.
-
7 zeigt
gemäß einer
Ausführungsform der
vorliegenden Erfindung ein vereinfachtes Flussdiagramm, in dem die
Schritte der erfindungsgemäßen automatischen
Ermittlungstechnik dargestellt sind. In 7 beginnt
die Clientanwendung (in Schritt 702) damit, den HTTP-Proxy,
falls ein solcher vorhanden ist, vom Browser aufzusuchen. Wie zuvor erwähnt wurde,
kann der Client-Computer eine Webseite vom Browser empfangen haben,
was impliziert, dass das HTTP-Protokoll
vom Browserprogramm für
die Kommunikation verwendet worden sein kann. Falls ein HTTP-Proxy
erforderlich ist, sind der Name und der Ort des HTTP-Proxy- dem
Browser wahrscheinlich bekannt, und dieses Wissen kann anschließend vom
Client verwendet werden, um zumindest die Kommunikation mit dem
Server unter Verwendung des HTTP-Proxy-Protokolls zu ermöglichen,
d.h. falls ein vorteilhafteres Protokoll nach der automatischen
Ermittlung nicht festgestellt werden kann.
-
In
Schritt 704 beginnt der Client die Abfolge der automatischen
Ermittlung durch paralleles Einleiten des Steuer-Threads 794,
zusammen mit fünf
Protokoll-Threads 790, 792, 796, 798 und 788.
Wie der Begriff hier verwendet wird, betrifft parallel sowohl die Situation,
in der die mehreren Protokoll-Threads, im Wesentlichen gleichzeitig
beginnend (mit einer im Wesentlichen ähnlichen Anfangszeit) parallel
gesendet werden, und die Situation, in der die mehreren Protokoll-Threads
gleichzeitig ausgeführt
werden (zur selben Zeit ausgeführt
werden), unabhängig
davon, wann jeder Protokoll-Thread eingeleitet wird. Im letztgenannten
Fall können die
mehreren Threads beispielsweise abgestufte Anfangszeiten aufweisen, und
die Einleitung eines Threads kann nicht von der Beendigung eines
anderen Threads abhängen.
-
Der
Steuer-Thread 794 stellt den Thread zum Auswählen des
vorteilhaftesten Protokolls zur Kommunikation dar. Die anderen Protokoll-Threads 790, 792, 796, 798 und 788 stellen
Threads zur Einleitung bei der parallelen Kommunikation unter Verwendung
der verschiedenen Protokolle, beispielsweise UDP, TCP, HTTP-Proxy,
HTTP-Über-Port-80 (HTTP
80) und HTTP-Über-Port-8080 (HTTP 8080), dar.
Wenngleich nur fünf
Protokoll-Threads
dargestellt sind, kann jede beliebige Anzahl von Protokoll-Threads
vom Client unter Verwendung beliebiger herkömmlicher und/oder geeigneter
Protokolle eingeleitet werden. Die jedem der Threads 794, 790, 792, 796, 798 und 788 zugeordneten
Protokolle werden hier in Zusammenhang mit den 8A–8E und 9 erörtert.
-
In 8A wird
der UDP-Protokoll-Thread ausgeführt.
Der Client fragt in Schritt 716 an, ob ein UDP-Proxy erforderlich
ist. Falls der UDP-Proxy erforderlich ist, kann der Benutzer den
Namen des UDP-Proxy- beispielsweise vom Systemadministrator erhalten,
um den UDP-Proxy zu verwenden, um die Kommunikation mit dem Proxy
zu erleichtern (in Schritt 718). Falls kein UDP-Proxy erforderlich
ist, kann der Client eine direkte Verbindung zum Server herstellen
(in Schritt 720). Anschließend kann der Client in Schritt 722 damit
beginnen, unter Verwendung des UDP-Protokolls (entweder über den
Proxy, falls ein Proxy beteiligt ist, oder direkt zum Server, falls kein
Proxy erforderlich ist) eine Datenanforderung (d.h. eine Steueranforderung)
zum Server zu senden.
-
In 8B wird
der TCP-Protokoll-Thread ausgeführt.
Falls das TCP-Protokoll verwendet wird, verbindet sich der Client
typischerweise direkt mit dem Server (in Schritt 726).
Anschließend
kann der Client damit beginnen, eine Datenanforderung (d.h. eine
Steueranforderung) unter Verwendung des TCP-Protokolls zum Server
zu senden (Schritt 724).
-
In 8C wird
der HTTP-Protokoll-Thread ausgeführt.
Der Client fragt in Schritt 716 an, ob ein HTTP-Proxy erforderlich
ist. Falls der HTTP-Proxy erforderlich ist, kann der Benutzer den
Namen des HTTP-Proxy beispielsweise vom Browser erhalten, weil,
wie zuvor erörtert
wurde, die zum Proxy gehörenden
Daten vom Browser beibehalten werden können. Alternativ kann der Benutzer
zum HTTP-Proxy gehörende
Daten vom Systemadministrator erhalten, um den HTTP-Proxy zum Erleichtern
der Kommunikation mit dem Server zu verwenden (in Schritt 732).
-
Falls
kein HTTP-Proxy erforderlich ist, kann sich der Client direkt mit
dem Server verbinden (in Schritt 730). Anschließend kann
der Client in Schritt 734 damit beginnen, eine Datenanforderung
(d.h. eine Steueranforderung) unter Verwendung des HTTP-Protokolls
zum Server zu senden (entweder über
den Proxy, falls ein Proxy beteiligt ist, oder direkt zum Server,
falls kein Proxy erforderlich ist).
-
In 8D wird
der HTTP-80-Protokoll-Thread ausgeführt. Falls das HTTP-80-Protokoll verwendet
wird, können
HTTP-Daten ausgetauscht werden, jedoch nur über Port 80, wobei es sich
beispielsweise um den Port am Client-Computer handeln kann, über den
die Kommunikation mit dem Netzwerk zulässig ist. Durch Port 80 verbindet
sich der Client typischerweise direkt mit dem Server (in Schritt 736).
Anschließend
kann der Client damit beginnen, eine Datenanforderung (d.h. eine
Steueranforderung) unter Verwendung des HTTP-80-Protokolls zum Server
zu senden (Schritt 738).
-
In 8E wird
der HTTP-8080-Protokoll-Thread ausgeführt. Falls das HTTP-8080-Protokoll
verwendet wird, können
HTTP-Daten ausgetauscht werden, jedoch nur über Port 8080, der der Port
am Client-Computer für
die Kommunikation mit dem Netzwerk sein kann. Durch Port 8080 verbindet sich
der Client typischerweise direkt mit dem Server (in Schritt 740).
Anschließend
kann der Client damit beginnen, eine Datenanforderung (d.h. eine
Steueranforderung) unter Verwendung des HTTP-8080-Protokolls zum
Server zu senden (Schritt 742). Die Multiplex- und die
Demultiplextechniken, die zur Kommunikation über Port 8080 sowie über Port
80 aus 8D verwendet werden können, wurden
früher
erörtert
und werden hier aus Gründen der
Kürze nicht
wiederholt.
-
9 zeigt
gemäß einer
Ausführungsform der
vorliegenden Erfindung den Steuer-Thread 794 aus 7.
Es sollte hervorgehoben werden, dass 7 lediglich
ein Weg zum Implementieren des Steuer-Threads ist. Andere Techniken
zum Implementieren des Steuer-Threads, die dazu dienen, die automatische
Ermittlung zu erleichtern, sollten Fachleuten angesichts dieser
Offenbarung offensichtlich sein. In Schritt 746 stellt
der Thread fest, ob die vordefinierte Zeitlimitfrist abgelaufen
ist. Die vordefinierte Zeitlimitfrist kann eine vordefinierte Dauer
(beispielsweise 7 Sekunden) von der Zeit, zu der die Datenanforderung
zum Server ausgesendet wird, aufweisen (beispielsweise Schritt 722 aus 8A).
Gemäß einer
Ausführungsform
weist jeder Protokoll-Thread seine eigene Zeitlimitfrist auf, deren
Ablauf beim Ablauf einer vordefinierten Dauer, nachdem die Datenanforderung
unter Verwendung dieses Protokolls ausgesendet worden ist, auftritt.
Wenn alle Zeitlimitfristen, die allen Protokollen zugeordnet sind, berücksichtigt
wurden, wird davon ausgegangen, dass die Zeitlimitfrist für die automatische
Ermittlungstechnik abgelaufen ist.
-
Falls
die zeitliche Beendigung aufgetreten ist, geht der Thread zu Schritt 754,
wo das vorteilhafteste Protokoll unter den vom Server empfangenen Protokollsätzen zur
Kommunikation ausgewählt
wird. Wie erwähnt
wurde, kann die Auswahl des vorteilhaftesten Protokolls entsprechend
einem vordefinierten Prioritätsschema
ausgeführt
werden, und Daten in Bezug auf das ausgewählte Protokoll können für künftige Kommunikationssitzungen
zwischen diesem Server und seinem Client gespeichert werden.
-
Falls
keine zeitliche Beendigung aufgetreten ist, wird der Thread mit
Schritt 748 fortgesetzt, um entweder auf Daten vom Server
oder auf den Ablauf der Zeitlimitfrist zu warten.
-
Falls
eine zeitliche Beendigung auftritt, geht der Thread zu Schritt 754,
der zuvor erörtert
wurde. Falls Daten vom Server empfangen werden, geht der Thread
zu Schritt 750, um, beispielsweise entsprechend der vordefinierten
Priorität,
festzustellen, ob das den vom Server empfangenen Daten zugeordnete
Protokoll das vordefinierte "beste" Protokoll ist.
-
Falls
das vordefinierte "beste" Protokoll (beispielsweise
UDP bei manchen Echtzeit-Datenrendering-Anwendungen) empfangen wird,
geht der Thread vorzugsweise zu Schritt 754, um die automatische
Ermittlung zu beendigen und um die Verwendung dieses Protokolls
für die
Datenkommunikation sofort zu beginnen, statt auf die zeitliche Beendigung zu
warten. Vorteilhafterweise kann die Dauer der automatischen Ermittlungssequenz
erheblich kürzer sein
als die vordefinierte Zeitlimitfrist. Auf diese Weise werden eine
schnelle automatische Ermittlung des geeignetsten Protokolls und
ein schnelles Einrichten der Kommunikation vorteilhafterweise erleichtert.
-
Falls
das vordefinierte "beste" Protokoll in Schritt 750 nicht
empfangen wird, wird der Thread in Schritt 752 fortgesetzt,
um das empfangene Protokoll zu dem empfangenen Satz hinzuzufügen. Dieser empfangene
Protokollsatz stellt den Protokollsatz dar, aus dem das "vorteilhafteste" (relativ ausgedrückt) Protokoll
ausgewählt
wird. Das vorteilhafteste Protokoll wird in Bezug auf andere Protokolle
in dem Satz empfangener Protokolle unabhängig davon ermittelt, ob es
entsprechend der vordefinierten Priorität das vordefinierte "beste" Protokoll ist. Als
ein Beispiel einer vordefinierten Protokollpriorität kann UDP als
am besten angesehen werden (d.h. als das vordefiniert beste), wobei
TCP, HTTP und dann HTTP 80 und HTTP 8080 folgen (die letzten beiden
können eine
gleiche Priorität
aufweisen). Wie früher
erwähnt wurde,
wird das vorteilhafteste Protokoll vorzugsweise nach Ablauf der
vordefinierten Zeitlimitfrist aus dem Satz empfangener Protokolle
ausgewählt.
-
Von
Schritt 752 kehrt der Thread zu Schritt 746 zurück, um zu
testen, ob die Zeitlimitfrist verstrichen ist. Falls dies nicht
der Fall ist, wird der Thread entlang den zuvor erörterten
Schritten fortgesetzt.
-
Es
sei bemerkt, dass die Verzögerung
zwischen der Zeit, zu der mit der Ausführung des automatischen Ermittlungsmechanismus
begonnen wird, und der Zeit, zu der das vorteilhafteste Protokoll
bestimmt wird, minimal ist, weil gemäß der Erfindung versucht wird,
eine Kommunikation zwischen der Clientanwendung und dem Server-Computer
parallel herzustellen. Falls Kommunikationsversuche in Reihe versucht
worden sind, erleidet der Benutzer beispielsweise die jedem Protokoll-Thread
zugeordnete Verzögerung
in Reihe, wodurch der Zeitraum zwischen dem Kommunikationsversuch
und der erfolgreichen Herstellung der Kommunikation unvorteilhafterweise
verlängert
wird.
-
Die
Zeiteinsparung ist in dem Fall, in dem das Netzwerk verstopft oder
beschädigt
ist, sogar noch dramatischer. Bei manchen Netzwerken können zwischen
30 und 90 Sekunden erforderlich sein, bevor die Clientanwendung
bemerkt, dass ein Versuch zur Verbindung mit dem Server (beispielsweise die
Schritte 720, 726, 730, 736 oder 740)
herzustellen, fehlgeschlagen ist. Falls jedes Protokoll in Reihe ausprobiert
wird, wie es gemäß einer
Ausführungsform
geschieht, kann die Verzögerung
in manchen Fällen
Minuten erreichen, bevor der Benutzer bemerkt, dass das Netzwerk
unbrauchbar ist, und es sollten zu einer späteren Zeit Versuche unternommen
werden.
-
Durch
den Versuch, eine Kommunikation über
die mehreren Protokolle parallel herzustellen, werden netzwerkbezogene
Verzögerungen
parallel erlitten. Demgemäß braucht
der Benutzer nicht auf mehrere Versuche und Fehlschläge zu warten,
bevor er feststellen kann, dass das Netzwerk unbrauchbar ist, und
es sollte ein Versuch zum Herstellen der Kommunikation zu einer
späteren
Zeit gemacht werden. Gemäß einer
Ausführungsform
ist es, sobald der Benutzer bemerkt, dass alle parallelen Versuche zur
Verbindung mit dem Netzwerk und/oder den Proxies fehlgeschlagen
sind, nicht erforderlich, dass der Benutzer wartengelassen wird,
bis die Zeitablauffristen jedes Threads abgelaufen sind. Gemäß dieser Ausführungsform
wird dem Benutzer geraten, es erneut zu versuchen, sobald festgestellt
wurde, dass alle parallelen Versuche zum Verbinden mit dem Server
fehlgeschlagen sind. Auf diese Weise ist weniger von der Zeit des
Benutzers erforderlich, um eine optimale Kommunikation mit einem
Netzwerk herzustellen.
-
Wenngleich
diese Erfindung in Bezug auf mehrere bevorzugte Ausführungsformen
beschrieben wurde, gibt es Abänderungen,
Permutationen und gleichwertige Ausgestaltungen, die innerhalb des
Schutzumfangs dieser Erfindung liegen. Wenngleich die Erfindung
beispielsweise in Bezug auf das parallele Aussenden von Protokoll-Threads
beschrieben wurde, lässt
sich die automatische Protokollermittlungstechnik auch anwenden,
wenn die Protokoll-Threads seriell gesendet werden. Wenngleich es in
diesem Fall länger
dauern kann, um das vorteilhafteste Protokoll zur Kommunikation
auszuwählen,
erreicht die automatische Protokollermittlungstechnik diese Aufgabe,
ohne dass höheres
technisches Wissen auf der Seite des Benutzers des Client-Computers
erforderlich wäre.
Die Dauer der automatischen Ermittlungstechnik kann, selbst wenn
eine serielle automatische Ermittlung verwendet wird, verkürzt werden,
indem die Protokolle in der Reihenfolge ihrer Erwünschtheit
ausprobiert werden und weniger erwünschte Protokolle ignoriert
werden, sobald ein wünschenswerteres
Protokoll erhalten wurde. Es sei auch bemerkt, dass es viele alternative
Wege für
das Implementieren der Verfahren und Vorrichtungen der vorliegenden
Erfindung gibt.