DE69829361T2 - Automatische erkennung von protokollen in einem netzwerk - Google Patents

Automatische erkennung von protokollen in einem netzwerk Download PDF

Info

Publication number
DE69829361T2
DE69829361T2 DE69829361T DE69829361T DE69829361T2 DE 69829361 T2 DE69829361 T2 DE 69829361T2 DE 69829361 T DE69829361 T DE 69829361T DE 69829361 T DE69829361 T DE 69829361T DE 69829361 T2 DE69829361 T2 DE 69829361T2
Authority
DE
Germany
Prior art keywords
protocol
data
computer
http
server
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
DE69829361T
Other languages
English (en)
Other versions
DE69829361D1 (de
Inventor
Prasad Srinivas VELLANKI
William Anthony CANNON
Srinivas Hemanth RAVI
Edgar Anders KLEMETS
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Microsoft Corp
Original Assignee
Microsoft Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Microsoft Corp filed Critical Microsoft Corp
Application granted granted Critical
Publication of DE69829361D1 publication Critical patent/DE69829361D1/de
Publication of DE69829361T2 publication Critical patent/DE69829361T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/16—Analogue secrecy systems; Analogue subscription systems
    • H04N7/173—Analogue secrecy systems; Analogue subscription systems with two-way working, e.g. subscriber sending a programme selection signal
    • H04N7/17309—Transmission or handling of upstream communications
    • H04N7/17336—Handling of requests in head-ends
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/61—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources taking into account QoS or priority requirements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/63—Routing a service request depending on the request content or context
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/18—Multiprotocol handlers, e.g. single devices capable of handling multiple protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/24—Negotiation of communication capabilities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/23406—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving management of server-side video buffer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/234381—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements by altering the temporal resolution, e.g. decreasing the frame rate by frame skipping
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/23439—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements for generating different versions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
    • H04N21/44004—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving video buffer management, e.g. video decoder buffer or video display buffer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
    • H04N21/4402—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving reformatting operations of video signals for household redistribution, storage or real-time display
    • H04N21/440281—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving reformatting operations of video signals for household redistribution, storage or real-time display by altering the temporal resolution, e.g. by frame skipping
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/637—Control signals issued by the client directed to the server or network components
    • H04N21/6373—Control signals issued by the client directed to the server or network components for rate control, e.g. request to the server to modify its transmission rate
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/637—Control signals issued by the client directed to the server or network components
    • H04N21/6377—Control signals issued by the client directed to the server or network components directed to server
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/637—Control signals issued by the client directed to the server or network components
    • H04N21/6377—Control signals issued by the client directed to the server or network components directed to server
    • H04N21/6379—Control signals issued by the client directed to the server or network components directed to server directed to encoder, e.g. for requesting a lower encoding rate
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/65—Transmission of management data between client and server
    • H04N21/658—Transmission by the client directed to the server
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/65—Transmission of management data between client and server
    • H04N21/658—Transmission by the client directed to the server
    • H04N21/6587—Control parameters, e.g. trick play commands, viewpoint selection
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/85—Assembly of content; Generation of multimedia applications
    • H04N21/854—Content authoring
    • H04N21/8547—Content authoring involving timestamps for synchronizing content
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/324—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the data link layer [OSI layer 2], e.g. HDLC

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer And Data Communications (AREA)

Description

  • 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.

Claims (27)

  1. Verfahren zum automatischen Ermitteln eines vorteilhaftesten Protokolls zur Kommunikation zwischen einem Client-Computer (106) und einem Server-Computer (104) über ein Computernetzwerk, umfassend die folgenden Schritte: Senden mehrerer Datenanfragen vom Client-Computer (106) zum Server-Computer (104) über das Netzwerk, wobei jede Datenanfrage ein unterschiedliches Protokoll und eine unterschiedliche Verbindung verwendet; Empfangen wenigstens einer Datenanfrage beim Server-Computer (104); Senden einer Antwort vom Server-Computer (104) zum Client-Computer (106) für jede vom Server-Computer (104) empfangene Datenanfrage, wobei jede Antwort ein Protokoll verwendet, das zu der jeweiligen empfangenen Datenanfrage gehört; Empfangen wenigstens einer dieser Antworten beim Client-Computer (106); und Auswählen eines vorteilhaftesten Protokolls beim Client-Computer (106) für die Kommunikation zwischen dem Client-Computer (106) und dem Server-Computer (104) aus den zu den empfangenen Antworten gehörigen Protokollen, wobei das vorteilhafteste Protokoll gemäß einer vordefinierten Protokollpriorität bestimmt wird.
  2. Verfahren nach Anspruch 1, wobei das Senden der mehreren Datenanfragen in einer im wesentlichen parallelen Weise ausgeführt wird.
  3. Verfahren nach Anspruch 2, wobei die mehreren Datenanfragen im wesentlichen zur gleichen Zeit gesendet werden.
  4. Verfahren nach Anspruch 2, wobei die mehreren Datenanfragen im wesentlichen gleichzeitig ausgeführt werden.
  5. Verfahren nach einem der Ansprüche 1 bis 4, wobei das vorteilhafteste Protokoll ein vordefiniertes bestes Protokoll darstellt und der Auswahlschritt die folgenden Schritte umfaßt: Überwachen der vom Client-Computer (106) empfangenen Antworten; und Kennzeichnen des vordefinierten besten Protokolls als das vorteilhafteste Protokoll, wenn eine das vordefinierte beste Protokoll verwendende Antwort vom Client-Computer (106) empfangen wird.
  6. Verfahren nach Anspruch 5, wobei das Computernetzwerk das Internet umfaßt und das vordefinierte beste Protokoll UDP umfaßt.
  7. Verfahren nach einem der Ansprüche 1 bis 4, wobei der Auswahlschritt umfaßt: bei Ablauf einer Zeitlimitfrist Auswählen des vorteilhaftesten Protokolls aus den Protokollen, die zu den vom Client-Computer (106) während der Zeitlimitfrist empfangenen Antworten gehören.
  8. Verfahren nach Anspruch 7, wobei die Zeitlimitfrist eine von einer Übertragungszeit einer der Datenanfragen an gemessene vordefinierte Zeitfrist ist.
  9. Verfahren nach einem der vorhergehenden Ansprüche, wobei die Datenanfragen mindestens eines der Protokolle UDP, TCP, HTTP proxy, HTTP 80 und HTTP 8080 verwenden.
  10. Verfahren nach Anspruch 9, wobei das HTTP-80-Protokoll ein Protokoll zum Ermöglichen der Übertragung vielfacher HTTP-Datenströme in Multiplex-Weise über Port 80 darstellt, wobei die vielfachen HTTP-Datenströme einen Videodatenstrom und einen Audiodatenstrom darstellen.
  11. Verfahren nach Anspruch 9, wobei das HTTP-8080-Protokoll ein Protokoll zum Ermöglichen der Übertragung vielfacher HTTP-Datenströme in Multiplex-Weise über Port 8080 darstellt, wobei die vielfachen HTTP-Datenströme einen Videodatenstrom und einen Audiodatenstrom darstellen.
  12. Verfahren nach einem der vorhergehenden Ansprüche, ferner umfassend die folgenden Schritte: Empfangen von Echtzeitdaten vom Server-Computer (104) mittels des ausgewählten vorteilhaftesten Protokolls; und Rendern der Echtzeitdaten, während die Daten vom Client-Computer (106) empfangen werden.
  13. Verfahren nach Anspruch 12, wobei die Echtzeitdaten einen Videodatenstrom, einen Audiodatenstrom und einen Kommentardatenstrom umfassen.
  14. Computervorrichtung (106) zum automatischen Ermitteln eines vorteilhaftesten Protokolls für die Kommunikation zwischen der Computervorrichtung (106) und einem entfernten Computer (104) über ein Computernetzwerk, die Computervorrichtung (106) umfassend: eine Erzeugungseinrichtung für Datenanfragen zum Erzeugen und Senden mehrerer Datenanfragen an einen entfernten Computer (104) über das Netzwerk, wobei jede Datenanfrage ein unterschiedliches Protokoll und eine unterschiedliche Verbindung verwendet und dazu ausgelegt ist, eine Antwort vom entfernten Computer (104) zu erbitten, wobei die Antworten ein Protokoll verwenden, das zu den entsprechenden empfangenen Datenanfragen gehört; Empfangseinrichtung, die zum Empfangen von vom entfernten Computer (104) erzeugten Antworten dient; und eine Auswahleinrichtung, die zum Auswählen eines Protokolls als ein vorteilhaftestes Protokoll für die Kommunikation zwischen der Computervorrichtung (106) und einem entfernten Computer (104) aus denjenigen Protokollen dient, die zu den von der Empfangseinrichtung empfangenen Antworten vom entfernten Computer (104) gehören, wobei das vorteilhafteste Protokoll gemäß einer vordefinierten Protokollpriorität bestimmt wird.
  15. Vorrichtung nach Anspruch 14, wobei die Erzeugungseinrichtung für Datenanfragen zum Erzeugen und Senden der mehreren Datenanfragen in im wesentlichen paralleler Weise dient.
  16. Vorrichtung nach Anspruch 15, wobei die Erzeugungseinrichtung für Datenanfragen zum Erzeugen und Senden der mehreren Datenanfragen zur im wesentlichen gleichen Zeit dient.
  17. Vorrichtung nach einem der Ansprüche 14 bis 16, wobei die Auswahleinrichtung ferner umfaßt: einen Timer zur Bestimmung des Ablaufs einer Zeitlimitfrist, wobei die Auswahleinrichtung zum Auswählen eines Protokolls als vorteilhaftestes Protokoll aus den Protokollen dient, die zu den von der Empfangseinrichtung während der vom Timer gemessenen Zeitlimitfrist empfangenen Antworten gehören.
  18. Vorrichtung nach Anspruch 17, wobei der Timer zum Bestimmen des Ablaufs einer Zeitlimitfrist dient, die eine vordefinierte Zeitfrist vom Absenden einer von der Erzeugungseinrichtung für Datenanfragen erzeugten Datenanfrage an umfaßt.
  19. Vorrichtung nach einem der Ansprüche 14 bis 18, wobei die Auswahleinrichtung enthält: eine Einrichtung zum Überwachen der von der Empfangseinrichtung empfangenen Antworten; und eine Einrichtung zum Kennzeichnen eines vordefinierten besten Protokolls als vorteilhaftestes Protokoll unmittelbar als Antwort darauf, daß die Überwachungseinrichtung den Emp fang einer das vordefinierte beste Protokoll verwendenden Antwort durch die Empfangseinrichtung erkennt.
  20. Vorrichtung nach einem der Ansprüche 14 bis 19, wobei die Erzeugungseinrichtung zum Erzeugen von Datenanfragen dient, die mindestens eines der Protokolle UDP, TCP, HTTP proxy, HTTP 80 und HTTP 8080 verwenden.
  21. Vorrichtung nach Anspruch 20, wobei das HTTP-80-Protokoll ein Protokoll zum Ermöglichen der Übertragung vielfacher HTTP-Datenströme in Multiplex-Weise über Port 80 darstellt, wobei die vielfachen HTTP-Datenströme einen Videodatenstrom und einen Audiodatenstrom darstellen.
  22. Vorrichtung nach Anspruch 20, wobei das HTTP 8080 Protokoll ein Protokoll zum Ermöglichen der Übertragung vielfacher HTTP-Datenströme in Multiplex-Weise über Port 8080 darstellt, wobei die vielfachen HTTP-Datenströme einen Videodatenstrom und einen Audiodatenstrom darstellen.
  23. Vorrichtung nach einem der Ansprüche 14 bis 22, ferner umfassend: eine Einrichtung zum Ausführen einer Anwendung zum Rendern von Echtzeitdaten, wobei die Empfangseinrichtung zum Empfangen von Echtzeitdaten vom entfernten Computer (104) mittels des festgelegten vorteilhaftesten Kommunikationsprotokolls dient.
  24. Vorrichtung nach einem der vorhergehenden Ansprüche, wobei die Empfangseinrichtung zum Empfangen von Echtzeitdaten dient, die einen Videodatenstrom, einen Audiodatenstrom oder einen Kommentardatenstrom vom entfernten Computer (104) umfassen.
  25. Computersystem umfassend: eine Computervorrichtung nach einem der Ansprüche 14 bis 24; einen entfernten Computer (104); und ein Computernetzwerk zum Übertragen von Datenanfragen und Antworten zwischen der Computervorrichtung (106) und dem entfernten Computer (104).
  26. Computersystem nach Anspruch 25, wobei das Computernetzwerk das Internet umfaßt.
  27. Computerlesbares Medium, enthaltend computerlesbare Anweisungen, die dazu dienen, daß ein programmierbarer Computer als Computervorrichtung nach einem der Ansprüche 14 bis 24 konfiguriert wird.
DE69829361T 1997-01-30 1998-01-30 Automatische erkennung von protokollen in einem netzwerk Expired - Lifetime DE69829361T2 (de)

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
US3666297P 1997-01-30 1997-01-30
US3666197P 1997-01-30 1997-01-30
US36661P 1997-01-30
US36662P 1997-01-30
US08/818,769 US5999979A (en) 1997-01-30 1997-03-14 Method and apparatus for determining a most advantageous protocol for use in a computer network
US818769 1997-03-14
PCT/US1998/001797 WO1998034385A1 (en) 1997-01-30 1998-01-30 Automatic detection of protocols in a network

Publications (2)

Publication Number Publication Date
DE69829361D1 DE69829361D1 (de) 2005-04-21
DE69829361T2 true DE69829361T2 (de) 2006-04-13

Family

ID=27365074

Family Applications (1)

Application Number Title Priority Date Filing Date
DE69829361T Expired - Lifetime DE69829361T2 (de) 1997-01-30 1998-01-30 Automatische erkennung von protokollen in einem netzwerk

Country Status (5)

Country Link
US (1) US5999979A (de)
EP (1) EP0956686B1 (de)
JP (1) JP3498746B2 (de)
DE (1) DE69829361T2 (de)
WO (1) WO1998034385A1 (de)

Families Citing this family (115)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6128653A (en) * 1997-03-17 2000-10-03 Microsoft Corporation Method and apparatus for communication media commands and media data using the HTTP protocol
US6311215B1 (en) * 1997-03-25 2001-10-30 Intel Corporation System for dynamic determination of client communications capabilities
US6396805B2 (en) * 1997-03-25 2002-05-28 Intel Corporation System for recovering from disruption of a data transfer
US6128668A (en) * 1997-11-07 2000-10-03 International Business Machines Corporation Selective transformation of multimedia objects
US6175860B1 (en) * 1997-11-26 2001-01-16 International Business Machines Corporation Method and apparatus for an automatic multi-rate wireless/wired computer network
US6446225B1 (en) * 1998-04-23 2002-09-03 Microsoft Corporation Server system with scalable session timeout mechanism
CN1291331C (zh) * 1998-04-27 2006-12-20 迪吉多电子股份有限公司 控制用主电脑
US6687753B2 (en) * 1998-06-25 2004-02-03 International Business Machines Corporation Method and system for providing three-dimensional graphics over computer networks
US6233688B1 (en) * 1998-06-30 2001-05-15 Sun Microsystems, Inc. Remote access firewall traversal URL
JP3042504B2 (ja) * 1998-07-03 2000-05-15 富士通株式会社 通信制御プログラムを格納した記録媒体、通信制御方法、通信制御装置
US6202081B1 (en) * 1998-07-21 2001-03-13 3Com Corporation Method and protocol for synchronized transfer-window based firewall traversal
EP1003313B1 (de) * 1998-09-11 2004-11-17 Two Way Media Limited Ablieferung von Interaktiven Anwendungen
US6493342B1 (en) 1998-09-11 2002-12-10 Teledesic Llc Method of data transmission in a data communication network
US6415326B1 (en) 1998-09-15 2002-07-02 Microsoft Corporation Timeline correlation between multiple timeline-altered media streams
US6622171B2 (en) 1998-09-15 2003-09-16 Microsoft Corporation Multimedia timeline modification in networked client/server systems
US6490615B1 (en) * 1998-11-20 2002-12-03 International Business Machines Corporation Scalable cache
JP3472498B2 (ja) * 1999-01-27 2003-12-02 シャープ株式会社 データ転送装置、データ転送方法およびデータ転送プログラムを記録した媒体
US6434617B1 (en) * 1999-02-22 2002-08-13 Hewlett-Packard Co. Extensible, object-oriented network interface
US7293280B1 (en) 1999-07-08 2007-11-06 Microsoft Corporation Skimming continuous multimedia content
US7313808B1 (en) 1999-07-08 2007-12-25 Microsoft Corporation Browsing continuous multimedia content
US6807648B1 (en) * 1999-09-13 2004-10-19 Verizon Laboratories Inc. Variable-strength error correction in ad-hoc networks
US6658476B1 (en) * 1999-11-29 2003-12-02 Microsoft Corporation Client-server protocol support list for standard request-response protocols
US6928655B1 (en) 1999-12-16 2005-08-09 Microsoft Corporation Live presentation searching
US7149359B1 (en) 1999-12-16 2006-12-12 Microsoft Corporation Searching and recording media streams
US6868440B1 (en) 2000-02-04 2005-03-15 Microsoft Corporation Multi-level skimming of multimedia content using playlists
US20020078198A1 (en) * 2000-02-25 2002-06-20 Buchbinder John E. Personal server technology with firewall detection and penetration
US20070214262A1 (en) * 2000-02-25 2007-09-13 Anywheremobile, Inc. Personal server technology with firewall detection and penetration
WO2001069405A1 (en) 2000-03-14 2001-09-20 Joseph Robert Marchese Digital video system using networked cameras
US6985966B1 (en) 2000-03-29 2006-01-10 Microsoft Corporation Resynchronizing globally unsynchronized multimedia streams
US7237254B1 (en) 2000-03-29 2007-06-26 Microsoft Corporation Seamless switching between different playback speeds of time-scale modified data streams
US7814208B2 (en) * 2000-04-11 2010-10-12 Science Applications International Corporation System and method for projecting content beyond firewalls
WO2001080558A2 (en) * 2000-04-14 2001-10-25 Solidstreaming, Inc. A system and method for multimedia streaming
EP1150472B1 (de) * 2000-04-27 2004-10-06 Hewlett-Packard Company Verfahren und System zur Installation von verfügbaren Netzprotokollen
US6601094B1 (en) * 2000-04-27 2003-07-29 Hewlett-Packard Development Company, L.P. Method and system for recommending an available network protocol
US7302490B1 (en) 2000-05-03 2007-11-27 Microsoft Corporation Media file format to support switching between multiple timeline-altered media streams
US6772216B1 (en) 2000-05-19 2004-08-03 Sun Microsystems, Inc. Interaction protocol for managing cross company processes among network-distributed applications
US20020116205A1 (en) * 2000-05-19 2002-08-22 Ankireddipally Lakshmi Narasimha Distributed transaction processing system
US6971096B1 (en) 2000-05-19 2005-11-29 Sun Microsystems, Inc. Transaction data structure for process communications among network-distributed applications
EP1161048A3 (de) * 2000-05-19 2005-02-16 Attachmate Corporation System und Verfahren zur gesicherte duplex Browserskommunikation über unterschiedliche Netzwerke
KR100434459B1 (ko) * 2000-06-27 2004-06-05 삼성전자주식회사 이동통신 시스템에서 패킷의 전송 제어방법 및 장치
US7441270B1 (en) * 2000-07-06 2008-10-21 Intel Corporation Connectivity in the presence of barriers
EP1310060B1 (de) * 2000-08-15 2012-08-01 Polycom Israel Ltd. Eine multimedia-kommunikationssteuereinheit als sicheres gerät zur multimedia-kommunikation zwischen lan-benutzer und anderen netzbenutzern
US7392301B1 (en) * 2000-11-14 2008-06-24 Siemens Subscriber Networks, Inc. Method and apparatus for automated assistance in configuring customer premises equipment
US7155487B2 (en) * 2000-11-30 2006-12-26 Intel Corporation Method, system and article of manufacture for data distribution over a network
KR100501080B1 (ko) * 2000-12-19 2005-07-18 노병희 인터넷상 트래픽의 상위 계층 프로토콜들을 구분하는 방법및 장치
US7631349B2 (en) * 2001-01-11 2009-12-08 Digi International Inc. Method and apparatus for firewall traversal
US7305697B2 (en) * 2001-02-02 2007-12-04 Opentv, Inc. Service gateway for interactive television
FI114265B (fi) * 2001-03-26 2004-09-15 First Hop Oy Menetelmiä ja järjestelyjä tehokkaan tiedonsiirron toteuttamiseksi nopeudeltaan rajoitetun tiedonsiirtolinkin yli
US20020157023A1 (en) * 2001-03-29 2002-10-24 Callahan John R. Layering enterprise application services using semantic firewalls
US20020144276A1 (en) * 2001-03-30 2002-10-03 Jim Radford Method for streamed data delivery over a communications network
KR100757466B1 (ko) * 2001-04-17 2007-09-11 삼성전자주식회사 홈네트워크내의 기기에 서비스를 제공하는 시스템과 그방법 및 홈네트워크에서 서비스를 제공받는 시스템과 그방법
JP3491626B2 (ja) * 2001-05-29 2004-01-26 ソニー株式会社 送信装置、受信装置、及び送受信装置
US6941356B2 (en) * 2001-06-29 2005-09-06 International Business Machines Corporation Automated configuration enabled via interrogation over network
FI110900B (fi) * 2001-07-11 2003-04-15 Nokia Corp Protokollaperusteiset päätevaltuudet
US7369537B1 (en) 2001-07-18 2008-05-06 Global Ip Solutions, Inc. Adaptive Voice-over-Internet-Protocol (VoIP) testing and selecting transport including 3-way proxy, client-to-client, UDP, TCP, SSL, and recipient-connect methods
US20030023731A1 (en) * 2001-07-24 2003-01-30 Adtran, Inc. Mechanism for automatically determining signaling role and associated protocol of frame relay communication device
US8650321B2 (en) * 2001-07-24 2014-02-11 Digi International Inc. Network architecture
JP4224958B2 (ja) * 2001-08-10 2009-02-18 富士ゼロックス株式会社 インターネット印刷方法、そのシステム、プロキシ装置及びプリントサーバ
WO2003028335A1 (de) * 2001-09-25 2003-04-03 Siemens Aktiengesellschaft Verfahren zur übertragung von daten in einem paketorientierten datennetz
US20030154244A1 (en) * 2002-02-13 2003-08-14 Zellers Mark H. Method and system to provide flexible HTTP tunnelling
JP4126928B2 (ja) * 2002-02-28 2008-07-30 日本電気株式会社 プロキシサーバ及びプロキシ制御プログラム
US7979528B2 (en) * 2002-03-27 2011-07-12 Radvision Ltd. System and method for traversing firewalls, NATs, and proxies with rich media communications and other application protocols
US7644172B2 (en) * 2002-06-24 2010-01-05 Microsoft Corporation Communicating via a connection between a streaming server and a client without breaking the connection
US7120858B2 (en) * 2002-08-21 2006-10-10 Sun Microsystems, Inc. Method and device for off-loading message digest calculations
US7277915B2 (en) * 2002-11-11 2007-10-02 Openwave Systems Inc. Application-based protocol and proxy selection by a mobile device in a multi-protocol network environment
US7191356B2 (en) * 2003-02-27 2007-03-13 Sun Microsystems, Inc. Method for asynchronous support of fault-tolerant and adaptive communication
US7178051B2 (en) * 2003-02-27 2007-02-13 Sun Microsystems, Inc. Method for synchronous support of fault-tolerant and adaptive communication
JP4374202B2 (ja) * 2003-02-28 2009-12-02 株式会社日立製作所 ストリーム配信計算機、プログラム、ｎａｓ装置
US7409454B2 (en) * 2003-06-02 2008-08-05 Microsoft Corporation Automatic detection of intermediate network device capabilities
US20050013589A1 (en) * 2003-07-14 2005-01-20 Microsoft Corporation Adding recording functionality to a media player
US7685603B2 (en) * 2003-09-08 2010-03-23 Sap Ag Selecting client adapters
US7486698B2 (en) * 2003-12-19 2009-02-03 Solace Systems, Inc. Multiplexing of control and data over an HTTP connection
US7720983B2 (en) 2004-05-03 2010-05-18 Microsoft Corporation Fast startup for streaming media
US20050283535A1 (en) * 2004-06-17 2005-12-22 Michele Covell Method and system for interactive control of media over a network
US7826401B2 (en) * 2004-06-21 2010-11-02 Insors Integrated Communications Methods and program products for mapping a network address translator
US8689313B2 (en) * 2004-06-21 2014-04-01 Insors Integrated Communications Real time streaming data communications through a security device
JP2006019934A (ja) * 2004-06-30 2006-01-19 Kddi Corp パケット交換網の呼設定方法
US7526557B2 (en) * 2004-06-30 2009-04-28 Signiant, Inc. System and method for transferring data in high latency firewalled networks
US20060106929A1 (en) * 2004-10-15 2006-05-18 Kenoyer Michael L Network conference communications
WO2006085313A2 (en) * 2005-02-09 2006-08-17 Enure Networks Ltd. Device, method, and system for module level network supervision
EP1806786A1 (de) * 2005-02-09 2007-07-11 Matsushita Electric Industrial Co., Ltd. Überwachungskameravorrichtung, überwachungssystem damit und verfahren zur übertragung von übrwachungsbildern
TW200532544A (en) * 2005-03-09 2005-10-01 Tul Corp Personal multimedia on-line broadcasting system and method thereof
WO2006105139A2 (en) 2005-03-30 2006-10-05 Welch Allyn, Inc. Communication of information between a plurality of network elements
US20060235939A1 (en) * 2005-04-18 2006-10-19 Wai Yim Apparatus and methods for tunneling a media streaming application through a firewall
US8190773B2 (en) * 2005-06-03 2012-05-29 Nokia Corporation System and method for accessing a web server on a device with a dynamic IP-address residing behind a firewall
US7600030B2 (en) * 2005-08-31 2009-10-06 Microsoft Corporation Compounding of HTTP authoring protocol
US8010850B2 (en) 2005-08-31 2011-08-30 Microsoft Corporation Client extended error handling
US20070220587A1 (en) * 2006-03-15 2007-09-20 Loyer Douglas E Systems, Methods, and Apparatus for Most Advantageous Media Delivery for Rich Media Applications
US9166883B2 (en) * 2006-04-05 2015-10-20 Joseph Robert Marchese Network device detection, identification, and management
US20070288604A1 (en) * 2006-06-08 2007-12-13 Jeffrey Mark Achtermann Method for determining optimal number of connections in multi-connection download configuration
WO2008045276A2 (en) 2006-10-04 2008-04-17 Welch Allyn, Inc. Dynamic medical object information base
US9516128B2 (en) * 2007-12-13 2016-12-06 International Business Machines Corporation Generic remote connection to a command line interface application
US20090216880A1 (en) * 2008-02-26 2009-08-27 Viasat, Inc. Methods and Systems for Dynamic Transport Selection Based on Last Mile Network Detection
GB2463329B (en) * 2008-09-10 2013-02-20 Echostar Advanced Technologies L L C Set-top box emulation system
JP4737302B2 (ja) 2009-02-03 2011-07-27 ブラザー工業株式会社 管理装置及びコンピュータプログラム
US8762460B2 (en) * 2009-07-13 2014-06-24 Qualcomm Incorporated Group communication sessions between session participants communicating via two or more different contact protocols within a wireless communications system
AU2010275473C1 (en) 2009-07-24 2014-02-27 Welch Allyn, Inc. Configurable health-care equipment apparatus
USD635681S1 (en) 2010-07-22 2011-04-05 Welch Allyn, Inc. Patient-monitor housing
USD632397S1 (en) 2010-07-22 2011-02-08 Welch Allyn, Inc. Portions of a patient-monitor housing
USD671222S1 (en) 2010-07-22 2012-11-20 Welch Allyn, Inc. Module for a patient-monitor or the like
JP2013118493A (ja) * 2011-12-02 2013-06-13 Oki Electric Ind Co Ltd 中継装置、通信端末及び通信ネットワーク
US8930475B1 (en) 2012-03-30 2015-01-06 Signiant Inc. Systems and methods for secure cloud-based media file sharing
US20140095320A1 (en) 2012-05-10 2014-04-03 Drawbridge, Inc. System and Method for Determining Related Digital Identities
US9692799B2 (en) 2012-07-30 2017-06-27 Signiant Inc. System and method for sending and/or receiving digital content based on a delivery specification
US20150244844A1 (en) * 2012-08-31 2015-08-27 David G. Butler Communication system
WO2014056135A1 (zh) * 2012-10-08 2014-04-17 华为终端有限公司 端口设置方法、路由设备及电脑程序产品
US9781214B2 (en) * 2013-04-08 2017-10-03 Amazon Technologies, Inc. Load-balanced, persistent connection techniques
DE102015224886A1 (de) 2015-12-10 2017-06-29 Siemens Aktiengesellschaft Vermeidung von Schwachstellen
KR102347069B1 (ko) * 2015-12-14 2022-01-04 삼성전자주식회사 전자 장치 및 그 동작방법
US10735516B1 (en) 2019-02-15 2020-08-04 Signiant Inc. Cloud-based authority to enhance point-to-point data transfer with machine learning
CN111565332A (zh) * 2020-04-27 2020-08-21 北京字节跳动网络技术有限公司 视频传输方法、电子设备和计算机可读介质
US11902599B2 (en) 2020-12-09 2024-02-13 Hulu, LLC Multiple protocol prediction and in-session adaptation in video streaming
EP4305779A1 (de) * 2021-03-10 2024-01-17 Telefonaktiebolaget LM Ericsson (publ) Verfahren und vorrichtungen zur herstellung einer transportprotokollverbindung
KR102613591B1 (ko) * 2022-10-19 2023-12-14 한국전자기술연구원 워크로드별 최적 동기화 브로커 선정 방법 및 시스템
US11848756B1 (en) 2023-03-20 2023-12-19 International Business Machines Corporation Automatic detection of optimal networking stack and protocol

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4931250A (en) * 1988-05-12 1990-06-05 Codex Corporation Multimode modem
JP2930257B2 (ja) * 1991-04-22 1999-08-03 株式会社東芝 携帯可能電子装置
US5202899A (en) * 1991-08-16 1993-04-13 Rockwell International Corporation Apparatus for providing dynamic selection of modem protocol to support multiple modem types
EP0596648A1 (de) * 1992-11-02 1994-05-11 National Semiconductor Corporation Erkennung du Fähigkeiten eines Netzendpunkts
US5537417A (en) * 1993-01-29 1996-07-16 International Business Machines Corporation Kernel socket structure for concurrent multiple protocol access
US5557724A (en) * 1993-10-12 1996-09-17 Intel Corporation User interface, method, and apparatus selecting and playing channels having video, audio, and/or text streams
US5710908A (en) * 1995-06-27 1998-01-20 Canon Kabushiki Kaisha Adaptive network protocol independent interface

Also Published As

Publication number Publication date
US5999979A (en) 1999-12-07
JP3498746B2 (ja) 2004-02-16
EP0956686A1 (de) 1999-11-17
WO1998034385A1 (en) 1998-08-06
EP0956686B1 (de) 2005-03-16
DE69829361D1 (de) 2005-04-21
JP2000509592A (ja) 2000-07-25

Similar Documents

Publication Publication Date Title
DE69829361T2 (de) Automatische erkennung von protokollen in einem netzwerk
DE69838262T2 (de) Allgemeine benutzer-authentifizierung für netz-rechner
DE60302051T2 (de) Verfahren, netzwerk und gerät zur konfiguration und steuerung von netzressourcen beim zurverfügungstellen von inhalten mit verteilungsregeln
DE102015002119B4 (de) Live-Videostreaming mit geringer Verzögerungszeit
DE69816599T2 (de) Datenübertragungssteuerung und verteilte datenverarbeitung
DE60130011T2 (de) Http-multiplexer/demultiplexer
DE69912017T2 (de) Peripheriegerät und Steuerverfahren dafür
DE69927713T2 (de) Angekündigte Sitzungsbeschreibung
DE60113868T2 (de) Kartennetzwerkschnittstelle, Netzwerkkonferenz-Endgeräteeinrichtung und Netzwerkkonferenzsystem
DE69937762T2 (de) Bidirektionelles Verfahren-zu-Verfahren Bytestromprotokoll
DE602004012010T2 (de) Drucken von einem drahtlosen WAN
DE102012214245B4 (de) Multistream-Datenübertragung
DE60216918T2 (de) Verfahren und computersystem zur auswahl eines randservercomputers
EP2826224B1 (de) Zugriff von clients auf einen serverdienst mittels einer opc-ua
DE69838314T2 (de) Verfahren und Vorrichtung zum dynamischen Laden eines Transportmechanismus in einem Mehrpunktdatenübermittlungssystem
DE69917925T2 (de) Steuerung einer angekündigten sitzung
EP1844390B1 (de) Verfahren und anordnung zum drucken über anwendungsserver sowie ein entsprechendes computerprogramm und ein entsprechendes computerlesbares speichermedium
DE60223604T2 (de) Verfahren, Einrichtung, Computerprogrammprodukt und System zur Worterteilung und Sitzungkontrolle
DE602004013414T2 (de) Verfahren und Vorrichtung zum verbesserten Weitergeben und Hochladen von Netzwerkdaten
DE60316649T2 (de) Konferenzanwendung die keinen bestimmten Verbindungsport verwendet
DE60030902T2 (de) Datenempfangsvorrichung
DE602005004255T2 (de) Bidirektionale SOAP-Kommunikation mittels einer einzigen HTTP-Sitzung
DE10231958B4 (de) Verfahren und System zum Übertragen von Datenpaketen über ein Netzwerk an ausgewählte mehrere Bestimmungsorte, sowie computerlesbares Medium
DE10231941A1 (de) Datenpaketstruktur für direkt adressiertes Multicast-Protokoll
DE60312138T2 (de) Sichere fernsteuerung

Legal Events

Date Code Title Description
8364 No opposition during term of opposition