[go: up one dir, main page]

DE602004011211T2 - Verfahren zur anpassung der dienstortplazierung auf der basis von aus dienstknoten empfangenen neueren daten und aktionen des dienstortsmanagers - Google Patents

Verfahren zur anpassung der dienstortplazierung auf der basis von aus dienstknoten empfangenen neueren daten und aktionen des dienstortsmanagers Download PDF

Info

Publication number
DE602004011211T2
DE602004011211T2 DE602004011211T DE602004011211T DE602004011211T2 DE 602004011211 T2 DE602004011211 T2 DE 602004011211T2 DE 602004011211 T DE602004011211 T DE 602004011211T DE 602004011211 T DE602004011211 T DE 602004011211T DE 602004011211 T2 DE602004011211 T2 DE 602004011211T2
Authority
DE
Germany
Prior art keywords
service
service provider
information
content
client device
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
DE602004011211T
Other languages
English (en)
Other versions
DE602004011211D1 (de
Inventor
Michele Palo Alto COVELL
Sumit Menlo Park ROY
John Palo Alto ANKCORN
John G. Palo Alto APOSTOLOPOULOS
Michael Palo Alto HARVILLE
Bo Fremont Shen
Wai-tian Sunnyvale TAN
Susie J Palo Alto WEE
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.)
Hewlett Packard Development Co LP
Original Assignee
Hewlett Packard Development Co LP
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 Hewlett Packard Development Co LP filed Critical Hewlett Packard Development Co LP
Publication of DE602004011211D1 publication Critical patent/DE602004011211D1/de
Application granted granted Critical
Publication of DE602004011211T2 publication Critical patent/DE602004011211T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING OR CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00Digital computers in general; Data processing equipment in general
    • G06F15/16Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/14Session management
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066Session management
    • H04L65/1101Session protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • H04L65/61Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/613Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for the control of the source by the destination
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • H04L65/75Media network packet handling
    • H04L65/752Media network packet handling adapting media to network capabilities
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/51Discovery or management thereof, e.g. service location protocol [SLP] or web services
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/55Push-based network services
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/56Provisioning of proxy services
    • H04L67/567Integrating service provisioning from a plurality of service providers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Hardware Design (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Business, Economics & Management (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Information Transfer Between Computers (AREA)
  • Computer And Data Communications (AREA)
  • Telephonic Communication Services (AREA)

Description

  • Technisches Gebiet
  • Ausführungsbeispiele der vorliegenden Erfindung beziehen sich auf ein Bedienen (Servicing) und eine Lieferung eines Inhalts über ein Netzwerk.
  • Technischer Hintergrund
  • Das Bedienen eines Inhalts für eine Lieferung über Computersystemnetzwerke erleichtert die Verbreitung eines Inhalts, der zweckmäßig zugreifbar ist und für einen Endbenutzerverbrauch geeignet ist. Typischerweise lokalisieren Menschen erwünschte Inhaltsorte (z. B. eine videobasierte Filmwebseite) während der Netzdurchstöberungsstreifzüge derselben mit den Tisch- oder Laptop-Rechnern derselben. Diese Vorrichtungen sind für die Anforderungen einer Eingabe (z. B. Einheitsressourcenlokalisierer (Uniform Resource Locators) oder Suchanfragen) und einer Ausgabe (zuverlässige Verbindungen hoher Bandbreite) gut geeignet, die einem Netzdurchstöbern zugeordnet sind, um einen verfügbaren Inhalt zu lokalisieren und auf denselben zuzugreifen. Wenn derartige Orte einmal lokalisiert sind, können Netzbenutzer nachfolgend versuchen, eine Verbindung zu denselben unter Verwendung mobiler Vorrichtungen herzustellen, wie beispielsweise videofähiger Personaldigitalassistenten (PDAs, PDAs = Personal Digital Assistants) oder zellulären Telefonen.
  • Um die Verschiedenartigkeit bei Benutzervorrichtungen (Clientvorrichtungen) aufzunehmen, müssen Inhaltsanbieter in der Lage sein, einen breiten Bereich unterschiedlicher Bitraten (gemäß der Bandbreite der Verbindung), Videorahmenraten (gemäß der Verarbeitungsleistung, die bei der Clientvorrichtung verfügbar ist, die selbst dynamisch gemäß Leistungsverwaltungsstrategien variiert, die durch die Clientvorrichtung eingesetzt werden), Videorahmengrößen (gemäß der Anzeigegröße, die bei der Clientvorrichtung verfügbar ist) oder dergleichen zu unterstützen.
  • Eine Möglichkeit, um diese Probleme anzusprechen, besteht darin, das Netzwerk mit der Fähigkeit auszustatten, Mediendaten zu transcodieren, wenn dieselben strömungsmäßig übertragen (gestreamt) werden, so dass dieselben an einer Clientvorrichtung in einem Format ankommen, das auf die Clientvorrichtung zugeschnitten ist. Anders ausgedrückt wird eine Verarbeitung durch das Netzwerk an einem Eingangsmedieninhaltsstrom durchgeführt, so dass ein Ausgangsinhaltsstrom mit einer unterschiedlichen Bitrate, Videorahmenrate, Videorahmengröße oder anderen Parametern erzeugt wird, was den Ausgangsinhaltsstrom für einen Verbrauch an der Clientvorrichtung geeigneter macht. Diesen Transcodiervorgang kann man sich als einen Dienst vorstellen, der durch das Netzwerk geliefert wird. Ineffizienzen, wie beispielsweise die Auswahl eines Transcodierdienstes, um einen Dienst durchzuführen, wenn die Ressourcen des ausgewählten Transcodierdienstes bereits erschöpft sind, können eine Systemleistungsfähigkeit verschlechtern.
  • Auf Grund derartiger Ineffizienzen kann es sein, dass Clientvorrichtungen für verlängerte Zeitperioden warten müssen, falls ein Server viele getrennte Anforderungen, eine Inhaltsverarbeitung und ein Übertragen einer Aufgabe (z. B. das Senden von Mediendateien zu unterschiedlichen anfordernden Clientvorrichtungen) durchzuführen, verwaltet. Zudem kann eine Streaming-Mediendatei sehr groß sein, wobei so die Zeit erhöht wird, die erforderlich ist, um das angeforderte Verarbeiten des Inhalts abzuschließen. Dies kann für einen Clientvorrichtungsbenutzer frustrierend sein, besonders falls er oder sie versucht, ein Projekt vor einer nahenden Frist abzuschließen. Herkömmliche Inhaltsbedienungs- und Liefersysteme liefern nicht die Art einer Medienverarbeitung und -analyse, die innerhalb des Netz werks durchgeführt wird und die ermöglichen würde, dass ein Inhalt, ein modifizierter Inhalt oder Daten, die von einem Inhalt abgeleitet sind, der durch das Netzwerk verfügbar ist, zu Clientvorrichtungen geliefert wird, die am effizientesten den besten Gebrauch von Systemressourcen machen.
  • MA W-Y et al. beschreibt in „Content Services Network: The architecture and Protocols" Proceedings of the WCW'01, 20. Juni 2001, Seiten 89–107, ein „Content Services Network" (CSN), das die Möglichkeit eines Anforderns eines Inhaltsanpassungsdienstes von einem CSN vorsieht, so dass der Inhalt vor einer Lieferung an Clients automatisch an der Netzwerkkante angepasst wird. Das CSN weist eine Mehrzahl von Anwendungsproxyservern (AP, AP = Application Proxy), die die Software von Mehrwertdiensten für eine Inhaltslieferung beherbergen, die Rechenressourcen bereitstellen, um einen Inhalt im Namen von Inhaltsanbietern (Inhaltsservern) oder Endbenutzern (Clients) zu verarbeiten. Derartige Anwendungsproxys weisen eine Vielfalt von Betriebsmodi auf, abhängig davon, wie der Dienst durchgeführt wird. Weitere Dienstverteilungs- und -verwaltungsserver (SDM, SDM = Services Distribution and Management) sind ebenso wie Umleitungsserver vorgesehen. Der Umleitungsserver leitet eine Dienstanforderung zu einem Anwendungsproxyserver gemäß einer Anzahl von Attributen und Messungen. Der Umleitungsdienst leitet Anforderungen, die zu einem CSN gesendet werden, zu einem der Anwendungsproxyserver gemäß der Örtlichkeit, der Serverlast und der Dienstart um.
  • Es ist die Aufgabe der vorliegenden Erfindung, ein verbessertes Verfahren für eine Dienstpositionsverwaltung zu schaffen, die ermöglicht, dass ein Inhalt, ein modifizierter Inhalt oder Daten, die von einem Inhalt abgeleitet sind, der durch ein Netzwerk verfügbar ist, zu Clientvorrichtungen geliefert wird, die am effizientesten den besten Gebrauch von Systemressourcen machen.
  • Diese Aufgabe wird durch ein Verfahren gemäß Anspruch 1 gelöst.
  • Offenbarung der Erfindung
  • Ausführungsbeispiele der vorliegenden Erfindung betreffen Verfahren und Systeme zu Auswählen von Mediendienstanbietern. Es wird eine Dienstart, die an einem Inhaltselement durchgeführt werden soll, identifiziert. Das Inhaltselement wird während einer Sitzung mit einer Clientvorrichtung identifiziert. Informationen hinsichtlich einer aktuellen Ressourcenverfügbarkeit werden von einer Mehrzahl von Dienstanbietern empfangen. Die Informationen werden aus andauernden Ressourcenmessungen ermittelt. Ein Dienstanbieter wird aus der Mehrzahl von Dienstanbietern basierend auf den Informationen, die empfangen werden, ausgewählt. Informationen werden zum Übertragen der Sitzung an den Dienstanbieter geliefert. Der Dienstanbieter führt den Dienst an dem Inhaltselement durch.
  • Kurze Beschreibung der Zeichnungen
  • Die zugehörigen Zeichnungen, die in dieser Beschreibung enthalten sind und einen Teil derselben bilden, stellen Ausführungsbeispiele der Erfindung dar und dienen zusammen mit der Beschreibung dazu, die Grundlagen der Erfindung zu erläutern:
  • 1 ist ein Blockdiagramm, das einen Informationsfluss in ein und aus einem System zum Bedienen und Liefern eines Inhalts basierend auf einer Ressourcenverfügbarkeit gemäß einem Ausführungsbeispiel der Erfindung zeigt.
  • 2 stellt eine Ressourcenverfügbarkeitsüberwachung für eine Dienstanbieterauswahl gemäß einem Ausführungsbeispiel der Erfindung dar.
  • 3A ist ein Blockdiagramm, das einen Informationsfluss in ein und aus einem System zum Bedienen und Liefern eines Inhalts basierend auf einer Ressourcenverfügbarkeit gemäß einem Ausführungsbeispiel der vorliegenden Erfindung zeigt.
  • 3B ist ein Blockdiagramm, das einen Informationsfluss in ein und aus einem System zum Bedienen und Liefern eines Inhalts zu einer Clientvorrichtung gemäß noch einem anderen Ausführungsbeispiel der vorliegenden Erfindung zeigt.
  • 4 stellt ein Verfahren zum Bedienen und Liefern eines Inhalts basierend auf einer Ressourcenverfügbarkeit gemäß einem Ausführungsbeispiel der vorliegenden Erfindung dar.
  • 5 stellt ein Verfahren zum Verwalten des Bedienens eines Inhalts basierend auf einer Ressourcenverfügbarkeit gemäß einem Ausführungsbeispiel der vorliegenden Erfindung dar.
  • Die Zeichnungen, auf die in dieser Beschreibung Bezug genommen wird, sind nicht als maßstabsgerecht gezeichnet zu verstehen, außer wenn es spezifisch angegeben ist.
  • Bester Modus zum Ausführen der Erfindung
  • Nun wird im Detail Bezug auf verschiedene Ausführungsbeispiele der Erfindung genommen, von denen Beispiele in den zugehörigen Zeichnungen dargestellt sind. Während die Erfindung in Verbindung mit diesen Ausführungsbeispielen beschrieben wird, ist klar, dass dieselben die Erfindung nicht auf diese Ausführungsbeispiele begrenzen sollen. Ferner sind in der folgenden Beschreibung der vorliegenden Erfindung zahlreiche spezifische Details dargelegt, um ein gründliches Verständnis der vorliegenden Erfindung zu liefern. In anderen Fällen wurden gut bekannte Verfahren, Prozeduren, Komponenten und Schaltungen nicht detailliert beschrieben, um Aspekte der vorliegenden Erfindung nicht unnötig zu verschleiern.
  • 1 ist ein Blockdiagramm eines Systems 100 zum Bedienen eines Inhalts, der durch eine Inhaltsquelle 110 geliefert wird, und zum Liefern des Dienstergebnisinhalts an eine Clientvorrichtung 150 gemäß einem Ausführungsbeispiel der vorliegenden Erfindung. Die Auswahl eines Dienstanbieters, um den Inhalt zu bedienen, der durch die Inhaltsquelle 110 geliefert wird, wird durch einen Dienstpositionsverwalter (SLM, SLM = Service Location Manager) 120 vorgenommen. Die vorgenommene Auswahl basiert auf dynamisch gesammelten Ressourcenmessungen, die durch den SLM 120 jüngst empfangen wurden und die die Ressourcenverfügbarkeit von Dienstanbietern angeben. Die Ressourcenmessungen, die empfangen werden, können sowohl Poll-basierte (abfragebasierte) als auch Push-basierte Daten umfassen. Gemäß einem Ausführungsbeispiel kann die Auswahl basierend auf einer Kombination von Poll-basierten und Push-basierten Daten vorgenommen werden. Dieser Ansatz ermöglicht, dass der SLM 120 seine Auswahl einer Dienstposition (z. B. eines Dienstanbieters) anpassen kann, um mit verfügbaren Ressourcen übereinzustimmen. Bei dem vorliegenden Ausführungsbeispiel umfasst das System 100 einen Dienstpositionsverwalter (SLM) 120, eine Mehrzahl von Dienstanbietern, die durch Dienstanbieter 130 und 132 veranschaulicht sind, eine Clientvorrichtung 150 und ein Portal 140.
  • Der Dienstpositionsverwalter (SLM) 120 kann sowohl eine Poll-basierte als auch eine Push-basierte Datensammlung nutzen. Eine Poll-basierte Ressourceninformationssammlung betrifft die Übertragung von Anforderungen an Dienstanbie ter (z. B. 130 und 132) durch den SLM 120 als ein Mittel zum Herausholen von Informationen von den Dienstanbietern hinsichtlich einer Ressourcenverfügbarkeit. Eine Push-basierte Informationssammlung betrifft den regelmäßigen „Push" oder die regelmäßige Übertragung von Informationen hinsichtlich einer Ressourcenverfügbarkeit zu dem SLM 120 durch die Dienstanbieter (z. B. 130 und 132). Wie es oben erwähnt ist, kann eine Kombination von sowohl Poll-basierter als auch Push-basierter Informationssammlung gemäß einem Ausführungsbeispiel eingesetzt werden.
  • Unter Bezugnahme auf 1 stellen Nachrichten A und B die Ressourcenüberwachungskommunikation dar, die durch den Dienstpositionsverwalter (SLM) 120 übertragen oder empfangen werden. Diese Nachrichten sind in 1 durch gestrichelte doppelköpfige Pfeile A und B gezeigt. Diese Nachrichten können entweder eine Poll-basierte Übertragung einer Anforderung an einen Dienstanbieter, eine Push-basierte Übertragung von Informationen hinsichtlich der Ressourcenverfügbarkeit eines Dienstanbieters an den SLM 120 oder eine Kombination von beiden bilden.
  • Ein Ansatz, der beide Informationsarten nutzt, könnte folgendes betreffen: (1) den Push von Informationen hinsichtlich einer Ressourcenverfügbarkeit durch einen Dienstanbieter (z. B. 130 oder 132) zu dem SLM 120 in der gleichen Nachricht, die verwendet wird, um den SLM 120 über den Beginn und das Ende einer Sitzung zu benachrichtigen (alleinstehende Aktualisierungen könnten übertragen werden, falls Sitzungsbeginn-/-beendigungsereignisse nicht häufig genug aufgetreten wären, um die erwünschte Zeitsteuerung einer Statistikübertragung zu erfüllen), und (2) der SLM 120 könnte regelmäßig die Dienstanbieter (z. B. 130 und 132) abfragen, wenn bestimmt wird, dass Statistiken von den Dienstanbietern (z. B. 130 und 132) nicht in einer vorbestimmten Zeitperiode empfangen wurden, und könnte das Neustarten von Hintergrundroutinen betreffen, die bei den Dienstanbietern resident sind, um die regelmäßigen Übertra gungen neu zu starten. Es ist zu erkennen, dass die Poll-basierten und die Push-basierten Informationen, die gesammelt werden, bei dem SLM 120 mit der jüngsten Historie von Dienstsitzungsabsendungen kombiniert werden können, um die bevorstehende Ressourcenverfügbarkeit besser vorauszusagen.
  • Der Dienstpositionsverwalter (SLM) 120, die Dienstanbieter 130 und 132 und das Portal 140 sind logische Entitäten, die an einer einzigen Vorrichtung oder unter Verwendung mehrerer Vorrichtung implementiert sein können. Somit kann das System 100 beispielsweise ein einziges Computersystem darstellen, das die Funktionalität des SLM 120, der Dienstanbieter 130 und 132 und des Portals 140 implementiert. Alternativ kann das System 100 unterschiedliche Knoten oder Vorrichtungen in einem Computersystemnetzwerk einschließen. Diese Knoten können Servercomputersysteme, Schalter (Switches), Router oder dergleichen sein, die Verarbeitungs- und Speicherfähigkeiten aufweisen, die ausreichend sind, um die verschiedenen Funktionalitäten durchzuführen, die hierin beschrieben werden. Allgemein gesagt, kann die Funktionalität, die durch das System 100 geliefert wird, unter Verwendung einer oder mehrerer Vorrichtungen implementiert sein. Obwohl das System 100 für einen einzigen Dienstpositionsverwalter 120 und ein einziges Portal 140 beschrieben ist, kann es mehr als eines von irgendwelchen dieser Elemente geben. Zusätzlich kann es mehr als zwei Dienstanbieter geben.
  • Das System 100 kann in einem bestehenden Computersystemnetzwerk durch ein Überlagern der Funktionalität des SLM 120, der Dienstanbieter 130 und 132 und/oder des Portals 140 auf das bestehende Netzwerk implementiert sein. Das heißt, alles oder ein Teil der Funktionalität, die durch das System 100 geliefert wird, kann in bestehende Netzwerkknoten eingegliedert sein. Alternativ kann alles oder ein Teil des Systems 100 durch ein Hinzufügen von Knoten in ein bestehendes Netzwerk implementiert sein. Beispielsweise können bestehende Inhaltsquellen und Portale verwendet werden, wobei Knoten zum Bedienen eines Inhalts und zum Verwalten von Dienstanbietern hinzugefügt sind.
  • Bei dem vorliegenden Ausführungsbeispiel kann das System 100 mit einer Inhaltsquelle 110 und einer Clientvorrichtung 150 kommunizieren. Obgleich für eine einzige Inhaltsquelle 110 und eine einzige Clientvorrichtung 150 beschrieben, kann es mehr als eines von jedem dieser Elemente geben. Eine Kommunikation zwischen dem System 100, der Inhaltsquelle 110 und der Clientvorrichtung 150, sowie eine Kommunikation innerhalb des Systems 100, kann drahtlos sein.
  • Die Clientvorrichtung 150 kann praktisch ein jegliche Art einer Benutzervorrichtung sein, wie beispielsweise ein Tisch- oder Laptop-Computersystem oder ein videofähiges Handhaltecomputersystem (z. B. ein tragbarer digitaler Assistent) oder ein zelluläres Telefon, aber ist nicht beschränkt darauf. Im Allgemeinen wird die Clientvorrichtung 150 verwendet, um ein Inhaltselement anzufordern und nachfolgend zu empfangen.
  • Ein Inhaltselement bezieht sich auf Medien- oder Nichtmediendaten, die live oder aufgezeichnet sein können. Ein Inhaltselement kann videobasierte Daten, audiobasierte Daten, bildbasierte Daten, webseitenbasierte Daten, Grafikdaten, textbasierte Daten oder irgendwelche Kombinationen derselben umfassen, aber ist nicht darauf begrenzt. Beispielsweise kann ein Inhaltselement ein Film von DVD-Qualität (DVD = Digital Video Disk) sein.
  • Eine Dienstart muss eventuell an dem Inhaltselement durchgeführt werden, bevor der Inhalt zu der Clientvorrichtung 150 geliefert wird. Dienstarten können das Verarbeiten eines Inhaltselements und/oder die Analyse eines Inhaltselements umfassen. Beispielsweise können Dienstarten eine Videoverarbeitung umfassen, wie beispielsweise ein Transcodieren, eine Zitterentfernung (Dither-Entfernung), ein dynamisches Abschneiden basierend auf einer Gesichtserken nung, eine Videoanalyse, ein Neuproportionieren des Videos, ein optisches Lesen eines Schriftzeichens von Video, eine Hintergrundentfernung und dergleichen, aber sind nicht begrenzt darauf.
  • Zusätzlich können Dienstarten eine Audioverarbeitung umfassen, wie beispielsweise eine Hintergrundentfernung, eine Audioverstärkung, eine Audiobeschleunigung oder -verlangsamung, eine Audioverstärkung, eine Rauschreduzierung, eine Spracherkennung, eine Audioanalyse und dergleichen, aber sind nicht darauf begrenzt. Die Analyse eines Inhaltselements kann beispielsweise eine Spracherkennung, die ein Texttransskript erzeugt, oder eine optische Schriftzeichenerkennung umfassen, die auf eines oder mehrere Videobilder eines Videostroms angewandt wird, um eine Textausgabe zu erzeugen. Ein videobasierter Personenverfolgungsdienst, der einen Strom von Aufzeichnungen einer Personenposition und von Zeiten ausgibt, ist ein anderes Beispiel, das verwendet werden kann, um eine Analyse eines Inhaltselements darzustellen. Die Positionen könnten hinsichtlich Bildkoordinaten ausgedrückt sein, aber sind eventuell nützlicher, wenn dieselben hinsichtlich Koordinaten der physischen Welt ausgedrückt sind (z. B. „x, y"-Koordinaten, die sich auf den Boden eines Raums beziehen). Ein weiteres Beispiel, das verwendet werden kann, um eine Analyse eines Inhaltselements darzustellen, betrifft einen Gesichtsdetektordienst, der Schnappschüsse von Gesichtern, die aus einem Videostrom extrahiert werden, sowie die Zeiten und Bildpositionen, an denen die Schnappschüsse erfasst wurden, Identitäten für die Gesichter und/oder die Klassifikation der Gesichter ausgibt. Ein gewisser Teil dieser Informationen kann als Textdaten dargestellt sein.
  • Wie es hierin verwendet wird, kann ein Inhaltselement bedient worden sein, kann sich in dem Prozess eines Bedientwerdens befinden, wird eventuell nicht bedient, oder ist eventuell noch nicht bedient worden. In anderen Worten ausgedrückt, kann ein Inhaltselement, ob dasselbe nun bedient wurde oder nicht, immer noch als ein Inhaltselement bezeichnet werden. Ein Bedienen eines Inhaltselements kann die Analyse oder Verarbeitung eines Inhaltselements umfassen. Wenn für eine Klarheit einer Erörterung notwendig, wird das Ergebnis eines Bedienens eines Inhaltselements hierin unter Verwendung von Begriffen bezeichnet, wie beispielsweise „Dienstergebnis" oder „Dienstergebnisinhalt" oder „Dienstergebnisdaten Ein Dienstergebnisinhalt kann folgendes umfassen: eine modifizierte Version des ursprünglichen bedienten Inhaltselements (z. B. wenn eine Hintergrundentfernung auf einen Videostrom angewandt wird); ein Inhaltselement, das von dem ursprünglichen Inhaltselement abgeleitet ist (z. B. wenn eine optische Schriftzeichenerkennung verwendet wird, um eine Textausgabe zu erzeugen); ein Inhaltselement, das durch einen Dienstanbieter hindurchgeleitet wird und nicht modifiziert, sondern bloß weitergeleitet wird (z. B. ein Inhalt, der keine Transcodierung erfordert, wenn derselbe durch einen Transcodierdienstanbieter empfangen wird); oder ein Inhaltselement, das vorhergehend zu einem Dienstanbieter gesendet wurde und nun bei dem Dienstanbieter cachegespeichert/gespeichert ist (z. B. ein Inhalt, der vorhergehend bedient wurde und nun in einem Speicher bei dem Dienstanbieter gespeichert ist). Zusätzlich kann ein Dienstergebnisinhalt irgendeine Kombination der obigen Beispiele umfassen.
  • Unter weiterer Bezugnahme auf 1 wirken die Dienstanbieter 130 und 132 jeweils, um eine oder mehrere Dienstarten zu liefern. Das heißt, die Dienstanbieter 130 und 132 können jeweils mehrere und unterschiedliche Dienstarten liefern. Der Dienstanbieter 130 kann beispielsweise zum Transcodieren eines Inhaltselements und für eine Hintergrundentfernung eines anderen Inhaltselements verwendet werden. Unterschiedliche Arten von Diensten können parallel an unterschiedlichen Inhaltselementen durchgeführt werden. Das heißt, die Dienstanbieter 130 und 132 können einen Dienst an unterschiedlichen, aber gleichzeitigen Inhaltsströmen durchführen. Die Dienstanbieter 130 und 132 können ferner Cachespeicherdienste liefern. Der Dienstanbieter 130 oder 132 beispielsweise kann ein Inhaltselement ganz oder zum Teil cachespeichern, bevor das Inhaltselement durch den Dienstanbieter 130 oder 132 bedient wird. Auf ähnliche Weise kann der Dienstanbieter 130 oder 132 das Dienstergebnis ganz oder zum Teil cachespeichern, bevor der Dienstergebnisinhalt zu der Clientvorrichtung 150 weitergeleitet wird.
  • Das Portal 140 ist ein gut veröffentlichter Portalort, der als der erste Kontaktpunkt zwischen der Clientvorrichtung 150 und dem System 100 dient. Die Inhaltsquelle 110 ist die Quelle des Inhaltselements.
  • Der Dienstpositionsverwalter (SLM) 120 wählt einen Dienstanbieter (z. B. den Dienstanbieter 130 oder 132) aus, der die Dienstart durchführen kann, die eventuell an dem Inhaltselement durchgeführt werden soll, bevor das Dienstergebnis zu der Clientvorrichtung 150 geliefert wird. Gemäß einem Ausführungsbeispiel kann diese Auswahl basierend auf verfügbaren Dienstanbieterressourcen vorgenommen werden, die bestimmt sind, wie es hierin beschrieben ist. Die Dienstanbieter 130 und 132 und irgendwelche anderen verfügbaren Dienstanbieter sind dem SLM 120 bekannt. Die Art oder Arten von Diensten, die jeder Dienstanbieter durchführen kann oder die durchzuführen derselbe veranlasst werden kann, sind ebenfalls dem Dienstpositionsverwalter 120 bekannt.
  • Die Art und Weise, auf die der SLM 120 einen Dienstanbieter auswählt, ist unten ausführlicher beschrieben. Operationen bei diesem Prozess sind durch einköpfige Pfeile dargestellt und entsprechen Nachrichten 16, die in 1 gezeigt sind. Die doppelköpfigen Pfeile A und B, die in 1 gezeigt sind, stellen Ressourcenüberwachungskommunikationen (z. B. Poll-basiert und Push-basiert) zwischen dem SLM 120 und den Dienstanbietern (z. B. 130 und 132) dar.
  • Unter erneuter Bezugnahme sendet am Beginn einer Sitzung die Clientvorrichtung 150 eine Nachricht 1 an das Portal 140. Die Nachricht 1 identifiziert ein spezielles Inhaltselement (z. B. den Namen eines Films).
  • Bei einem Ausführungsbeispiel umfasst die Nachricht 1 ferner Informationen, die zum Identifizieren einer Dienstart ausreichend sind, die an dem Inhaltselement durchgeführt werden sollte, bevor das Dienstergebnis zu der Clientvorrichtung 150 geliefert wird. Diese Informationen können viele Formen annehmen. Bei einer Form identifiziert die Nachricht 1 spezifisch eine Dienstart (z. B. Hintergrundentfernung oder Spracherkennung). Bei einer anderen Form identifizier die Nachricht 1 Attribute der Clientvorrichtung 150, wie beispielsweise die Speicherkapazität, Bildschirmgröße, Verarbeitungsfähigkeit derselben und dergleichen. Basierend auf diesen Attributen kann das System 100 (z. B. das Portal 140) eine Dienstart ableiten, die durchgeführt werden sollte (z. B. Transcodieren). Bei noch einer anderen Form identifiziert die Nachricht 1 die Art der Clientvorrichtung 150, und basierend auf einer gespeicherten Kenntnis dieser Vorrichtungsart kann das System 100 (z. B. das Portal 140) eine Dienstart ableiten, die durchgeführt werden sollte (z. B. Transcodieren).
  • Die Nachricht 1 kann andere Informationen umfassen. Falls die Quelle des Inhaltselements durch die Clientvorrichtung 150 bekannt ist, dann kann das Inhaltselement auch in der Nachricht 1 identifizier sein. Beispielsweise kann die Nachricht 1 den Einheitsressourcenlokalisierer (URL) für die Inhaltsquelle 110 umfassen. Falls die Quelle des Inhaltselements der Clientvorrichtung 150 nicht bekannt ist, kann die Inhaltsquelle durch das System 100 (z. B. durch das Portal 140) lokalisiert werden, falls diese Informationen dem System 100 noch nicht bekannt sind.
  • Nach einem Empfangen der Nachricht 1 sendet das Portal 140 eine Nachricht 2 an den SLM 120. Bei einem Ausführungsbei spiel umfasst die Nachricht 2 Informationen, die zum Identifizieren einer Dienstart ausreichend sind, die an dem Inhaltselement durchgeführt werden sollte, bevor das Dienstergebnis an die Clientvorrichtung 150 geliefert wird. Wie es eben beschrieben wurde, können diese Informationen viele Formen annehmen. In einer Form identifiziert die Nachricht 2 genauer gesagt eine Dienstart (z. B. Hintergrundentfernung oder Spracherkennung). In einer anderen Form identifiziert die Nachricht 2 Attribute der Clientvorrichtung 150, wie beispielsweise eine Speicherkapazität, Bildschirmgröße, Verarbeitungsfähigkeit derselben und dergleichen. Basierend auf diesen Attributen kann das System 100 (z. B. der SLM 120) eine Dienstart ableiten, die durchgeführt werden sollte (z. B. Transcodieren). In noch einer anderen Form identifiziert die Nachricht 2 die Art der Clientvorrichtung 150, und basierend auf einer gespeicherten Kenntnis dieser Vorrichtungsart kann das System 100 (z. B. der SLM 120) eine Dienstart ableiten, die durchgeführt werden sollte (z. B. Transcodieren). Basierend auf den Informationen, die durch die Nachricht 2 geliefert werden, identifiziert der SLM 120 die Dienstart, die durchgeführt werden soll.
  • Die Nachricht 2 kann andere Informationen umfassen. Beispielsweise kann die Nachricht 2 auch das Inhaltselement und/oder die Inhaltsquelle identifizieren.
  • Die Dienstanbieter 130 und 132 und die Dienste, die dieselben liefern können, sind dem SLM 120 bekannt. Dem SLM 120 sind ebenfalls bestimmte statische Serveranbieter- und Netzwerkcharakteristika bekannt, wie beispielsweise Rechen- und Speicherressourcen von netzwerkgekoppelten Vorrichtungen, eine Konnektivität und eine erwartete Bandbreite und eine Latenz zwischen Servern, Client-/Inhaltsadressen, eine Sitzungsversandhistorie und eine Netzwerknähe. Gemäß einigen Ausführungsbeispielen ist zusätzlich die Identität einer zweckspezifischen Hardware (z. B. Verschlüsselung oder Komprimierung), die durch den Dienstanbieter verwendet wird, bekannt, was ermöglicht, dass der SLM 120 statische Charakteristika der zweckspezifischen Hardware bei der Auswahl geeigneter Dienstanbieter berücksichtigen kann. Der SLM kann ferner regelmäßige Übertragungen von Dienstsitzungsinformationen von den Dienstanbietern 130 und 132 empfangen. Diese Informationen können in der Form von Dienstsitzungsbeginn- und -beendigungsinformationen erfolgen (z. B. Dienstsitzungseinleitungs- und -beendigungsinformationen).
  • Es ist zu beachten, dass eine Kombination von einigen oder allen der Dienstanbieter- und Netzwerkcharakteristika und Dienstsitzungsinformationen, die unter Verwendung statischer Informationen und dynamischer Messungen beschrieben sind, durch den SLM bei der Auswahl eines Dienstanbieters eingesetzt werden können. Es ist zu beachten, dass der SLM 120 unter Verwendung dieser Informationen einen Dienstanbieter 130 oder 132 (oder andere gekoppelte Dienstanbieter) auswählt, um den Dienst durchzuführen, der aus der Nachricht 2 identifiziert ist.
  • Gemäß einem Ausführungsbeispiel wählt der SLM 120 entweder den Dienstanbieter 130 oder 132 basierend auf der Eignung derselben (hinsichtlich einer bestimmten Ressourcenverfügbarkeit) aus, einen bestimmten Dienst zu liefern. Bei einem Ausführungsbeispiel wählt der Dienstpositionsverwalter 120 zufällig entweder den Dienstanbieter 130 oder 132 aus. Bei einem anderen Ausführungsbeispiel wählt der SLM 120 entweder den Dienstanbieter 130 oder 132 unter Verwendung eines Schemas wie beispielsweise eines zyklischen Umlaufschemas (Round-Robin-Schemas) aus.
  • Bei noch einem anderen Ausführungsbeispiel behält der SLM 120 eine Historie oder Aufzeichnung von Dienstanbietern bei, die andere Sitzungen bedienen, die bereits im Gang sind. Das heißt, wie es vorhergehend erwähnt wurde, kann es mehrere Clientvorrichtungen geben, die jeweils an einer Sitzung teilnehmen (z. B. je ein Inhaltselement anfordern).
  • Für diese anderen Sitzungen, bei denen das Inhaltselement bedient wird, wird der SLM 120 einen Dienstanbieter ausgewählt haben, um den Dienst durchzuführen. Bei dem vorliegenden Ausführungsbeispiel behält der SLM 120 eine Aufzeichnung der Dienstanbieter bei, die ausgewählt wurden, um Dienste für diese anderen Sitzungen zu liefern. Basierend auf den Informationen in der Aufzeichnung kann der SLM 120 einen Dienstanbieter für die neue Sitzung mit einer Clientvorrichtung 150 auswählen. Basierend auf den Informationen in der Aufzeichnung kann beispielsweise der SLM 120 beurteilen, welche Dienstanbieter relativ zu den anderen Dienstanbietern am beschäftigtsten sind. Die Aufzeichnung kann durch den SLM 120 unter Verwendung einer Vielfalt von Ansätzen aktualisiert werden, die weiter unten beschrieben werden sollen.
  • Bei dem Beispiel von 1 wählt der SLM 120 den Dienstanbieter 130 aus. Der SLM 120 sendet dann eine Nachricht 3 an das Portal 140. Die Nachricht 3 umfasst Informationen, die zum Positionieren und Kontaktieren des Dienstanbieters 130 ausreichend sind. Beispielsweise kann die Nachricht 3 den URL für den Dienstanbieter 130 umfassen.
  • Die Nachricht 3 kann andere Informationen umfassen. Beispielsweise kann die Nachricht 3 ferner das Inhaltselement und/oder die Inhaltsquelle identifizieren.
  • Nach einem Empfangen der Nachricht 3 sendet das Portal 140 eine Nachricht 4 an die Clientvorrichtung 150. Die Nachricht 4 umfasst die Informationen zum Lokalisieren und Kontaktieren des Dienstanbieters 130, die durch die Nachricht 3 geliefert wurden. Die Nachricht 4 kann mit der Nachricht 3 identisch sein (die Nachricht 4 kann einfach eine Weiterleitung der Nachricht 3 sein). Die Nachricht 4 kann jedoch andere (zusätzliche) Informationen umfassen, die durch das Portal 140 hinzugefügt sind. Die Nachricht 4 kann beispielsweise ferner das Inhaltselement und/oder die Inhaltsquelle identifizieren, falls diese Informationen durch das Portal 140 anstelle des Dienstpositionsverwalters 120 bestimmt sind.
  • Bei einem anderen Ausführungsbeispiel sendet der SLM 120 anstelle der Nachrichten 3 und 4 eine Nachricht direkt an die Clientvorrichtung 150. Die Nachricht von dem SLM 120 an die Clientvorrichtung 150 umfasst die Informationen zum Lokalisieren und Kontaktieren des Dienstanbieters 130. Diese Nachricht kann andere Informationen umfassen, wie beispielsweise die Identität des Inhaltselements und/oder der Inhaltsquelle.
  • In jedem Fall empfängt die Clientvorrichtung 150 eine Nachricht, die Informationen umfasst, die zum Lokalisieren und Kontaktieren des Dienstanbieters 130 ausreichend sind. Basierend auf diesen Informationen wird eine Kommunikation zwischen der Clientvorrichtung 150 und dem Dienstanbieter 130 eingerichtet. Mit anderen Worten wird die Sitzung, die durch die Clientvorrichtung 150 eingeleitet wird, automatisch von dem Portal 140 an den Dienstanbieter 130 übertragen. Bedeutsamerweise ist die Übertragung von dem Portal 140 auf den Dienstanbieter 130 nahtlos und transparent für einen Endbenutzer an der Clientvorrichtung 150.
  • Bei einem Ausführungsbeispiel verwendet die Nachricht, die durch die Clientvorrichtung 150 empfangen wird (z. B. die Nachricht 4) eine synchronisierte Multimedia-Integrationssprache (SMIL, SMIL = Synchronized Multimedia Integration Language) oder basiert auf derselben. Eine Umleitung der Clientvorrichtung 150 von dem Portal 140 zu dem Dienstanbieter 130 kann unter Verwendung einer dynamischen SMIL-Umschreibung erzielt werden.
  • Unter weiterer Bezugnahme auf das Beispiel angesichts von 1 sendet nach dem Empfangen der Nachricht 4 von dem Portal 140 (oder einer äquivalenten Nachricht von dem SLM 120) die Clientvorrichtung 150 eine Nachricht 5 an den Dienstanbieter 130. Die Nachricht 5 identifiziert das Inhaltselement und die Dienstart, die durch den Dienstanbieter 120 durchgeführt werden soll. Die Nachricht 5 kann andere Informationen umfassen. Falls beispielsweise die Inhaltsquelle an diesem Punkt der Clientvorrichtung 150 bekannt ist, können diese Informationen in der Nachricht 5 enthalten sein.
  • Nach einem Empfangen der Nachricht 5 sendet der Dienstanbieter 130 eine Nachricht 6 and die Inhaltsquelle 110. Wie es oben erwähnt ist, kann die Inhaltsquelle 110 dem Dienstanbieter 130 in der Nachricht 5 identifiziert sein. Andernfalls kann der Dienstanbieter 130 die Inhaltsquelle 110 lokalisieren. In der Nachricht 6 fordert der Dienstanbieter 130 an, dass das Inhaltselement geliefert wird.
  • Ansprechend auf die Nachricht 6 sendet die Inhaltsquelle 110 das Inhaltselement an den Dienstanbieter 130 zum Bedienen (durch einen Pfeil 7 in 1 dargestellt). Bei einem Ausführungsbeispiel wird das Inhaltselement zu dem Dienstanbieter 130 strömungsmäßig übertragen.
  • Bei einem Ausführungsbeispiel ist der Dienstanbieter 130 immer eingerichtet und bereit, um den spezifizierten Dienst auszuführen. Das heißt, der spezifizierte Dienst kann an dem Dienstanbieter 130 kontinuierlich ausführen und auf Daten warten, um an denselben wirksam zu sein. Bei einem anderen Ausführungsbeispiel ist der spezifizierte Dienst ruhend, bis entweder die Nachricht 5 oder das Inhaltselement durch den Dienstanbieter 130 empfangen werden. Das heißt, der Dienstanbieter 130 muss eventuell den spezifizierten Dienst einrichten oder starten und wird dies nicht tun, bis der mögliche Bedarf nach dem Dienst identifiziert ist oder bis es einen tatsächlichen Bedarf gibt, den Dienst durchzuführen.
  • In jedem Fall kann der Dienstanbieter 130 dann den spezifizierten Dienst an dem Inhaltselement durchführen. Das Inhaltselement kann durch den Dienstanbieter 130 im Ganzen oder zum Teil vor einem Bedienen cachegespeichert werden oder das Inhaltselement kann bedient werden, wenn dasselbe durch den Dienstanbieter 130 empfangen wird.
  • Der Dienstergebnisinhalt wird dann durch den Dienstanbieter 130 an die Clientvorrichtung 150 gesendet (durch einen Pfeil 8 in 1 dargestellt). Bei einem Ausführungsbeispiel wird der Dienstergebnisinhalt zu der Clientvorrichtung 150 strömungsmäßig übertragen. Der Dienstergebnisinhalt kann durch den Dienstanbieter 130 im Ganzen oder zum Teil nach dem Bedienen (vor dem strömungsmäßigen Übertragen) cachegespeichert werden oder der Dienstergebnisinhalt kann strömungsmäßig übertragen werden, wenn derselbe durch den Dienstanbieter 130 bedient wird.
  • Sobald der Dienstergebnisinhalt durch den ausgewählten Dienstanbieter (z. B. den Dienstanbieter 130) geliefert und durch die Clientvorrichtung 150 empfangen wurde, kann die im Gang befindliche Sitzung beendet werden. Bei einem Ausführungsbeispiel, bei dem eine Historie oder Aufzeichnung durch den SLM 120 beibehalten wird, kann die Historie oder Aufzeichnung aktualisiert werden, um wiederzuspiegeln, dass der Dienstanbieter 130 die Bedienungsaufgaben desselben abgeschlossen hat. Unterschiedliche Ansätze können verwendet werden, um eine Aktualisierung der Aufzeichnung zu veranlassen. Bei einem Ansatz schätzt zu der Zeit oder um dieselbe herum, zu der der SLM 120 eine Auswahl eines Dienstanbieters vornimmt, der SLM 120 die Menge an Zeit, die benötigt wird, um den Dienst abzuschließen, der an dem Inhaltselement durchgeführt werden soll. Die Aufzeichnung kann aktualisiert werden, um wiederzuspiegeln, dass der Dienst abgeschlossen wurde, wenn diese Menge an Zeit verstrichen ist.
  • Alternativ kann der ausgewählte Dienstanbieter (z. B. der Dienstanbieter 130) eine Angabe an den SLM 120 liefern, wann derselbe einen Dienst abgeschlossen hat, und die Aufzeichnung kann entsprechend aktualisiert werden. Diese Ansätze können erweitert werden, um die Lieferung des Dienstergebnisinhalts an die Clientvorrichtung 150 zu berücksichtigen. Beispielsweise kann die Menge an Zeit, die durch den SLM 120 für den Dienstanbieter 130 geschätzt wird, um den Dienst durchzuführen, erhöht werden, um irgendeine zusätzliche Zeit zu berücksichtigen, die durch den Dienstanbieter 130 benötigt wird, um den Dienstergebnisinhalt an die Clientvorrichtung 150 zu senden. Auf ähnliche Weise kann der Dienstanbieter 130 dem SLM 120 angeben, wann derselbe das Senden des Dienstergebnisinhalts an die Clientvorrichtung 150 abgeschlossen hat.
  • Bei der obigen Erörterung wird das Inhaltselement an den Dienstanbieter 130 ansprechend auf die Nachricht 6 gesendet. Wie es vorhergehend hierin erwähnt ist, kann der Dienstanbieter 130 anstelle dessen einen Inhalt, der vorhergehend empfangen und/oder bedient wurde, speichern oder cachespeichern, wobei die Verwendung der Nachricht 6 und die Antwort auf die Nachricht 6 umgangen wird (z. B. der Datenfluss, der in 1 durch den Pfeil 7 angegeben ist, umgangen wird).
  • In der Übersicht kontaktiert eine Clientvorrichtung 150, die einen Dienst sucht, das System 100 (z. B. das Portal 140). Die Clientvorrichtung 150 wird zu einem Anbieter des Dienstes (z. B. den Dienstanbieter 130) umgeleitet. Ein Inhalt von einer Inhaltsquelle (z. B. der Inhaltsquelle 110) wird über den Dienstanbieter zu dem Client gesendet (z. B. strömungsmäßig übertragen). Bei einem Ausführungsbeispiel ist somit das System 100 zum strömungsmäßigen Übertragen von Medien von einer Inhaltsquelle zu einer Clientvorrichtung vorgesehen.
  • Zu Zwecken der vorliegenden Anmeldung bedeutet ein strömungsmäßiges Übertragen von Medien, wie dasselbe hierin verwendet wird, Daten, die zwischen Netzwerkknoten auf kontinuierliche Weise kommuniziert werden. Beispiele umfassen Streaming-Audio und -Video, die eventuell strenge Zeitbeschränkungen auf einer Lieferung aufweisen. Falls bei diesen Beispielen Abschnitte dieser Ströme zu spät geliefert werden, werden die Abschnitte auf Grund von Verspätung ignoriert (dieselben sind zu spät, um zu das bewirken, was durch die Clientanwendung gerade abgespielt wird, und sind deshalb größtenteils nutzlos). Falls jedoch Abschnitte dieser Ströme zu früh geliefert werden, werden dieselben auf Grund von Puffereinschränkungen innerhalb des Dienstes oder der Clientanwendung verloren. Andere Beispiele von Daten, die auf kontinuierliche Weise übertragen werden, umfassen Ströme von Versuchsergebnissen. Diese Arten von Strömen umfassen Wetterablesungen von entfernten Sensoren und Temperaturablesungen von Kühlsystemen. Bei diesen Beispielen gibt es keine strengen Zeitbeschränkungen bei der Lieferung; die Datenübertragung weist jedoch eine zeitliche Komponente auf, die am besten durch nahtlos vonstatten gehende Übertragungen bedient wird.
  • An sich weist durch ein Verwenden von Streaming-Medien die Wirkung einer Dienstplatzierung eine langlebige Auswirkung auf Ressourcen von sowohl dem Netzwerk als auch den Serverknoten auf. Bei einem Transcodieren eines Films zum Betrachten unter Streaming-Bedingungen beispielsweise überspannen die Daten soviel wie zwei Stunden und deshalb kann die Transcodiersitzung soviel wie zwei Stunden der Serverzeit überspannen. Bei anderen Arten von strömungsmäßigem Übertragen (z. B. Instrumentenablesungen) kann die Dauer des Stroms und der Dienst, der an dem Strom vorgenommen wird, unendlich sein. Die Rechenressourcen des Serverknotens sind für lange Zeitperioden mit unbestimmten Dauern beeinflusst. Auf ähnliche Weise sind die Netzwerkressourcen an den Serverknoten, an allen Verbindungen zwischen dem Server und dem Inhaltsanbieter und zwischen dem Server und der Clientmaschine für lange Zeitperioden mit unbestimmten Dauern beeinflusst. Dies steht im starken Gegensatz zu klassischeren Netzwerktransaktionen, bei denen die Datenübertragung in einem Block vorgenommen wird, häufig eine Sache von Sekunden oder Minuten, und bei denen der Dienst, der an diesen Daten durchgeführt wird, eine beschränkte Dauer aufweist.
  • Bei einem Ausführungsbeispiel, das sich mit Streaming-Medien beschäftigt, sind die folgenden einige der Probleme, die betrachtet werden müssen; das heißt im Vergleich zu einer netzbasierten Verteilung und netzbasierten Geschäftstransaktionen und/oder Herunterladungen weist Streaming-Medien die folgenden Charakteristika auf, die angesprochen werden müssen:
    eine große Menge an Daten – der Endpunkt der Daten ist eventuell nicht bekannt und ein Cachespeichern einer Anzahl von Inhaltselementen kann erhebliche Speicherressourcen verbrauchen; zeitlich sortierte Daten – die zeitliche Reihenfolge, in der Daten empfangen werden, kann bedeutsam sein; ein Zugriff kann nicht bis zu einem Abschluss durchgeführt werden – beispielsweise kann lediglich auf einen gewissen Abschnitt eines Inhaltselements zugegriffen werden (z. B. die ersten paar Minuten eines Films voller Länge); eine benötigte Bandbreite kann nicht ohne einen gewissen Grad eines Verständnisses der betreffenden Medien bestimmt werden – beispielsweise kann eine Videodatei in einer hohen räumlichen Auflösung sein und eine andere Videodatei ist dies eventuell nicht, und somit kann, während die Dateien, die beide Videodateien sind, eventuell gleich erscheinen, die jeweilige Bandbreite derselben ziemlich unterschiedlich sein; ein Zittern (Jitter) bei einer Latenz oder Bandbreite kann problematisch sein – eine beständige Latenz kann annehmbar sein, aber eine Latenz, die während einer Sitzung beträchtlich variiert, kann auf Grund eines Pufferüberlaufs oder -unterlaufs problematisch sein; unangemessene Rechen- oder Bandbreitenressourcen können Ergebnisse auf Grund von Zeitbeschränkungen nutzlos machen; Daten sind typischerweise codiert (komprimiert) und somit kann ein Verlust oder eine Verspätung eines gewissen Teils der Daten Folgen für eine nachfolgende Datendecodierung (Dekomprimierung) haben; verlorene Daten werden typischerweise auf Grund von Zeitbeschränkungen nicht neu übertragen; und eine Zustandsauf zeichnung sollte für alle Clientvorrichtungen beibehalten werden – für Streaming-Medien muss der Streaming-Knoten mit einem strömungsmäßigen Übertragen von Daten fortfahren und kann nicht warten, um Zustandsinformationen von Clients zu empfangen. Das Ergebnis dieser Unterschiede besteht darin, den Bedarf nach einer Verwaltung und Überwachung von Diensten stark zu erhöhen, die an Streaming-Medien durchgeführt werden.
  • Ressourcenüberwachung für Dienstanbieterauswahl
  • 2 stellt eine Ressourcenverfügbarkeitsüberwachung für eine Dienstanbieterauswahl gemäß einem Ausführungsbeispiel der vorliegenden Erfindung dar. Gemäß einem Ausführungsbeispiel der vorliegenden Erfindung untersucht der Dienstpositionsverwalter (SLM 120) den Ressourcenverfügbarkeitsstatus von jedem der Mediendienstanbieter (z. B. 130, 132 und 230), der unter der Steuerung desselben ist, um zu bestimmen, welcher Dienstanbieter ausgewählt wird, um die Mediendienstaufgabe durchzuführen, die durch die aktuelle Clientanforderung angefordert ist. Es gibt verschiedene Arten und Weisen, auf die diese Untersuchung abgeschlossen werden kann. Die folgende Erörterung beschreibt unterschiedliche Ressourcenüberwachungsansätze, die gemäß der vorliegenden Erfindung implementiert werden können. 2 zeigt den Dienstpositionsverwalter (SLM 120), Dienstanbieter 130, 132 und 230, das Netzwerk 100, Dienstportale 140 und 240, die Inhaltsquelle 110 und Clientvorrichtungen 210, 212, 214, 216, 218, 220 und 222.
  • Unter Bezugnahme auf 2 stellen Nachrichten A, B und C die Ressourcenüberwachungskommunikationen dar, die durch den Dienstpositionsverwalter (SLM 120) gesendet oder empfangen werden. Diese Nachrichten sind in 2 durch gestrichelte doppelköpfige Pfeile A, B und C dargestellt. Diese Nachrichten können entweder eine Poll-basierte Übertragung einer Anforderung zu einem Dienstanbieter, eine Push-basierte Übertragung von Informationen hinsichtlich der Ressourcenverfügbarkeit eines Dienstanbieters an den SLM 120 oder eine Kommunikation von beiden bilden.
  • Poll-basierte Ressourcenüberwachung
  • Gemäß einem Ausführungsbeispiel kann ein Überwachen des Ressourcenverfügbarkeitsstatus von Mediendienstanbietern (z. B. 130, 132 und 230), die durch den SLM 120 gesteuert sind, „Poll-basiert" sein. Gemäß diesem Ansatz kontaktiert, immer wenn der SLM 120 eine neue Anforderung eines Client (z. B. 210, 212, 214, 216, 220, etc.) nach Mediendiensten erhält, derselbe aktiv jeden der Dienstanbieter, die geeignete Ressourcen aufweisen (z. B. hinsichtlich einer Anzahl und Taktgeschwindigkeiten der CPUs desselben, des installierten Speichers desselben und der Netzwerkbandbreite im besten Fall), um eine Ressourcenverfügbarkeit zu bestimmen (z. B. Nachricht A, B oder C). Ansprechend auf diese „Ressourcenabfrage", liefert jeder Dienstanbieter 130 (z. B. 130, 132 und 230) eine Beschreibung der aktuell verfügbaren Ressourcen desselben (z. B. Nachricht A, B oder C). Diese kann die Anzahl von verfügbaren Rechenzyklen und die Menge an Speicher umfassen, die zu einem gegebenen Zeitpunkt verfügbar ist. Idealerweise würde die Antwort auch einen gewissen Schätzwert der Netzwerkbandbreite umfassen, die für die Inhaltsquelle 110 und für den Client (z. B. 210, 212, 214, 216, 220, etc.) verfügbar ist. Der SLM 120 kann diese Informationen sammeln und dieselben als eine Grundlage zum Auswählen des geeigneten Dienstanbieters verwenden, um die angeforderte Aufgabe durchzuführen. Gemäß einem Ausführungsbeispiel wählt der SLM 120 den Dienstanbieter (z. B. 130, 132 und 230) aus, der die beste Kombination einer verfügbaren Netzwerkbandbreite und von Rechen- und Speicherressourcen liefert.
  • Der „Poll-basierte" Ansatz weist den Vorteil eines Lieferns von aktuellen Schnappschüssen von verfügbaren Ressourcen eines Dienstanbieters (z. B. 130, 132 und 230) auf. Derselbe liefert ferner eine deutliche Angabe dessen, wann ein Dienstanbieter (z. B. 130, 132 und 230) auf Grund entweder eines Netzwerk- oder Maschinenausfalls außer Dienst ist.
  • Push-basierte Ressourcenüberwachung
  • Gemäß einem Ausführungsbeispiel können Ressourceninformationen von den Dienstanbietern (z. B. 130, 132 und 230) zu dem überwachenden SLM 120 „gepusht" werden. Gemäß diesem Ausführungsbeispiel werden Aktualisierungen (z. B. Nachrichten A, B oder C) auf einer regelmäßigen Basis durch einen Dienstpositionsüberwacher (SLS, SLS = Service-Location Supervisor) geliefert, der als eine Hintergrundroutine implementiert sein kann, die auf jedem Mediendienstanbieter (nicht gezeigt) läuft. Gemäß einem Ausführungsbeispiel kann die Hintergrundroutine unter Verwendung einer System- und Netzwerkverwaltungssoftware implementiert sein. Bei anderen Ausführungsbeispielen können andere Implementierungen genutzt werden.
  • Für jede Clientanforderung greift der SLM 120 auf eine Datenbank verfügbarer Ressourcen zu, die aus der Sammlung (und der Datierung) der SLS-gelieferten Informationen erzeugt ist. Dies reduziert die Verbindungsanforderungen, die aus einer Ressourcenüberwachung eingefahren werden, von einer quadratischen auf eine lineare Abhängigkeit von der Anzahl von Mediendienstanbietern, die Informationen hinsichtlich verfügbarer Ressourcen übertragen (z. B. pushen).
  • Gemäß einem Ausführungsbeispiel können Überwachungs- und „Neustart"-Fähigkeiten dem SLM 120 selbst verliehen werden. Dies würde die Verwendung einer Hintergrundroutine des SLM 120 betreffen, um die Zeitstempel der spätesten SLS-Datenbankauffrischungen zu überwachen und zu versuchen, SLS-Maschinen zu kontaktieren, die mehr als ein gewisses voreingestelltes Zeitintervall außer Kontakt sind. In einigen Fällen können die Kontaktversuche fehlschlagen, beispielsweise auf Grund eines fortlaufenden Netzwerk- oder Mediendienstanbieterausfalls. Da jedoch derartige Versuche, den SLS-Kontakt neu zu starten, asynchron vorgenommen werden würden, beeinflussen dieselben gemäß exemplarischen Ausführungsbeispielen nicht die Ansprechzeit des SLM 120 auf Clientanforderungen.
  • Verbesserte Push-basierte Überwachung
  • Gemäß einem Ausführungsbeispiel kann der Push-basierte Überwachungsansatz modifiziert werden, um die Wahrscheinlichkeit der Kommunikation durch Dienstanbieter von veralteten Informationen zu dem SLM 120 zu verringern. Dies kann durch ein Veranlassen vorgenommen werden, dass der SLM 120 eine Kurzzeitaufzeichnung der Mediendienstanbieter beibehält, an die derselbe kürzlich Clientaufgaben versandt hat. Der SLM 120 kann dann seine Voraussage einer Ressourcenverfügbarkeit für neue Aufträge entsprechend einstellen. Wenn beispielsweise eine Mediendienstaufgabe an einen Mediendienstanbieter weniger als eine Minute, bevor die Ressourcenstatistiken zuletzt von diesem Dienstanbieter übertragen wurden, versandt wird, würde die Ressourcenaufzeichnung dieses Dienstanbieters um das Ressourcenbudget gesenkt, das durch diesen vorhergehend versandten Mediendienstauftrag angefordert wird.
  • Wie es vorhergehend erörtert ist, kann die Auswahl eines Dienstanbieters basierend auf einer Kombination von Poll-basierten und Push-basierten Daten vorgenommen werden. Durch ein Verwenden beider Arten von Daten kann ein vollständigeres Bild verfügbarer Ressourcen ermittelt werden. Dieser Ansatz ermöglicht, dass der Dienstpositionsverwalter seine Auswahl einer Dienstposition (z. B. eines Dienstanbieters) anpassen kann, um mit verfügbaren Ressourcen enger übereinzustimmen.
  • 3A ist ein Blockdiagramm, das einen Informationsfluss in das und aus dem System 100 gemäß einem anderen Ausführungsbeispiel der vorliegenden Erfindung zeigt. Ein Unterschied zwischen 1 und 3A besteht in der Hinzufügung einer Nachricht D von dem Dienstpositionsverwalter (SLM 120) an den ausgewählten Dienstanbieter (z. B. den Dienstanbieter 130). Die Nachricht D kann von dem Dienstpositionsverwalter 120 an den Dienstanbieter 130 zu irgendeiner Zeit nach der Nachricht 2 und vor der Nachricht 5 gesendet werden.
  • Die Nachricht D kann für irgendeine Anzahl unterschiedlicher Zwecke verwendet werden. In einer Situation beispielsweise, in der die Art eines Dienstes, die an dem spezifizierten Inhaltselement durchgeführt werden soll, an dem Dienstanbieter 130 nicht kontinuierlich ausgeführt wird, kann die Nachricht D verwendet werden, um den Dienstanbieter 130 vor dem bevorstehenden Bedarf nach dem Dienst zu warnen. Folglich kann die Einrichtung (Setup) und/oder der Start (Startup) des Dienstes eingeleitet und vielleicht abgeschlossen werden, bevor die Nachricht 5 von der Clientvorrichtung 150 empfangen wird, was eine Gesamtlatenz verringert.
  • Ferner kann die Nachricht D verwendet werden, um dem Dienstanbieter 130 die Identität des Inhaltselements und vielleicht die Identität der Inhaltsquelle 110 zu liefern. Mit diesen Informationen kann der Dienstanbieter 130 anfordern, dass die Inhaltsquelle 110 das Inhaltselement liefert (z. B. ein strömungsmäßiges Übertragen beginnt), bevor die Nachricht 5 empfangen wird, was ferner zu einer Verringerung einer Latenz beiträgt. Zusätzlich kann die Verwendung der Nachricht D in dieser Weise zu einer verbesserten Sicherheit führen, weil die Inhaltsquelle 110 der Clientvorrichtung 150 gegenüber beispielsweise nicht identifiziert werden muss.
  • Ferner kann die Nachricht D anstelle der Nachrichten 3, 4 und 5 verwendet werden, wie es in 3B dargestellt ist. Zusätzlich zu dem Identifizieren des Inhaltselements und möglicherweise der Inhaltsquelle kann die Nachricht D beispielsweise ferner Informationen umfassen, die ermöglichen, dass der Dienstanbieter 130 eine Kommunikation mit der Clientvorrichtung 150 einrichtet. Anders ausgedrückt kann anstelle dessen, dass die Clientvorrichtung 150 die Kommunikationsübertragung von dem Portal 140 an den Dienstanbieter 130 einleitet, die Kommunikationsübertragung durch den Dienstanbieter 130 in einer Weise eingeleitet werden, die für einen Benutzer der Clientvorrichtung 150 nahtlos und transparent bleibt.
  • Wie es mit Bezug auf 1 erörtert ist, stellen die Nachrichten A und B (von 3) die Ressourcenüberwachungskommunikationen dar, die durch den SLM 120 übertragen oder empfangen werden. Diese Nachrichten sind in 3 durch gestrichelte doppelköpfige Pfeile A, B und C dargestellt. Diese Nachrichten können entweder eine Poll-basierte Übertragung einer Anforderung an einen Dienstanbieter, eine Push-basierte Übertragung von Informationen hinsichtlich der Ressourcenverfügbarkeit eines Dienstanbieters an den SLM 120 oder eine Kombination von beiden bilden.
  • 4 ist ein Flussdiagramm 400 eines Verfahrens zum Bedienen und Liefern eines Dienstergebnisinhalts gemäß einem Ausführungsbeispiel der vorliegenden Erfindung. Obwohl in dem Flussdiagramm 400 spezifische Schritte offenbart sind, sind derartige Schritte exemplarisch. Das heißt, Ausführungsbeispiele der vorliegenden Erfindung sind für ein Durchführen verschiedener anderer Schritte oder Variationen der Schritte, die in dem Flussdiagramm 400 dargelegt sind, gut geeignet. Es ist ersichtlich, dass die Schritte in dem Flussdiagramm 400 in einer zu der präsentierten unterschiedlichen Reihenfolge durchgeführt werden können und dass eventuell nicht alle der Schritte in dem Flussdiagramm 400 durchgeführt werden.
  • Alle oder ein Teil der Verfahren, die durch das Flussdiagramm 400 beschrieben sind, können unter Verwendung computerlesbarer und computerausführbarer Anweisungen implementiert werden, die beispielsweise in computerverwendbaren Medien eines Computersystems oder einer ähnlichen Vorrichtung resident sind. Bei dem vorliegenden Ausführungsbeispiel wird das Flussdiagramm 400 durch das System 100 von 13 implementiert. Das heißt, einige der Schritte, die in dem Flussdiagramm 400 dargelegt sind, werden durch das Portal (z. B. 140) durchgeführt, andere durch den Dienstpositionsverwalter (z. B. SLM 120) und noch andere durch den Dienstanbieter (z. B. 130, 132 und 230) von 13.
  • Bei einem Schritt 402 von 4 empfängt während einer Sitzung mit einer Clientvorrichtung ein Portal eine Anforderung von der Clientvorrichtung, die ein Inhaltselement identifiziert. Die Anforderung kann andere Informationen umfassen. Bei einem Ausführungsbeispiel empfängt mit Bezug auf 1 und 2 das Portal 140 die Nachricht 1 von der Clientvorrichtung 150.
  • Bei einem Schritt 404 von 4 wird eine Dienstart, die an dem Inhaltselement durchgeführt werden soll, identifiziert. Die Dienstart kann in der Anforderung des Schritts 402 identifiziert sein, oder dieselbe kann basierend auf Informationen abgeleitet werden, die in dieser Anforderung geliefert werden. Mit Bezug auf 1 und 3 kann die Dienstart durch die Clientvorrichtung 150, durch das Portal 140 oder durch den Dienstpositionsverwalter 120 identifiziert werden.
  • Bei einem Schritt 406 von 4 werden Informationen hinsichtlich einer aktuellen Ressourcenverfügbarkeit von einer Mehrzahl von Dienstanbietern empfangen. Die Informationen werden aus fortlaufenden Ressourcenmessungen ermit telt. Die Ressourcenmessungen, die empfangen werden, können sowohl Poll-basierte als auch Push-basierte Daten umfassen. Gemäß einem Ausführungsbeispiel kann die Auswahl basierend auf einer Kombination von Poll-basierten und Push-basierten Daten vorgenommen werden. Dieser Ansatz ermöglicht, dass der Dienstpositionsverwalter seine Auswahl einer Dienstposition (z. B. eines Dienstanbieters) anpassen kann, um mit verfügbaren Ressourcen übereinzustimmen.
  • Bei einem Schritt 408 von 4 wird ein Anbieter der Dienstart aus einer Anzahl von Anbietern ausgewählt, die zum Durchführen des Dienstes in der Lage sind. Bei einem Ausführungsbeispiel, auch unter Bezugnahme auf 1 und 3, wird ein Dienstanbieter (z. B. der Dienstanbieter 130, etc.) durch den SLM 120 ausgewählt. Wie es oben erwähnt ist, kann der SLM 120 entweder Poll-basierte oder Push-basierte Ressourcenverfügbarkeitsinformationen verwenden, die ermöglichen, dass der Dienstpositionsverwalter seine Auswahl einer Dienstposition (z. B. eines Dienstanbieters) anpassen kann, um mit verfügbaren Ressourcen übereinzustimmen.
  • Zusätzlich kann der SLM 120 einen Dienstanbieter zufällig oder unter Verwendung eines Schemas wie beispielsweise eines zyklischen Umlaufschemas auswählen. Alternativ kann der SLM 120 eine Aufzeichnung beibehalten, die wiederspiegelt, zu welchen der Dienstanbieter andere Sitzungen übertragen wurden. Bei diesem letzteren Ansatz wählt der SLM 120 einen Dienstanbieter basierend den Informationen in der Aufzeichnung aus.
  • Bei einem Schritt 410 von 4 wird eine Kommunikation mit der Clientvorrichtung von dem Portal an den ausgewählten Dienstanbieter übertragen. Anders ausgedrückt, wird die Sitzung von dem Portal an den ausgewählten Dienstanbieter übertragen.
  • Bei einem Schritt 412 von 4 wird eine Quelle des Inhaltselements identifiziert. Mit Bezug auf 1 und 3 kann die Quelle des Inhaltselements durch die Clientvorrichtung 150, durch das Portal 140, durch den SLM 120 oder durch den ausgewählten Dienstanbieter (z. B. den Dienstanbieter 130) identifiziert werden. Die Inhaltsquelle wird dann kontaktiert, um eine Lieferung von Daten für das Inhaltselement an den ausgewählten Dienstanbieter zu beginnen.
  • Bei einem Schritt 414 von 4 wird das Inhaltselement durch den ausgewählten Dienstanbieter empfangen (z. B. strömungsmäßig an denselben übertragen).
  • Bei einem Schritt 416 wird das Inhaltselement gemäß der spezifizierten Dienstart bedient. Daten, die das Inhaltselement bilden, können bedient werden, wenn die Daten an dem Dienstanbieter empfangen werden, oder die Daten können vor einem Bedienen cachegespeichert werden. Wie es oben erwähnt ist, kann ein Inhaltselement bedient worden sein, kann sich in dem Prozess eines Bedientwerdens befinden, wird eventuell nicht bedient oder wird eventuell noch nicht bedient. Das Bedienen eines Inhaltselements kann die Analyse oder Verarbeitung eines Inhaltselements umfassen. Der Dienstergebnisinhalt kann bestehen aus: einer modifizierten Version des ursprünglichen Dienstelements (z. B. wenn eine Hintergrundentfernung auf einen Videostrom angewandt wird); einem Inhaltselement, das von dem ursprünglichen Inhaltselement abgeleitet ist (z. B. wenn eine optische Schriftzeichenerkennung verwendet wird, um eine Textausgabe zu erzeugen); einem Inhaltselement, das durch einen Dienstanbieter geleitet wird und nicht modifiziert, sondern bloß weitergeleitet wird (z. B. ein Inhalt, der kein Transcodieren erfordert, wenn derselbe durch einen Transcodierdienstanbieter empfangen wird); oder einem Inhaltselement, das vorhergehend an einen Dienstanbieter gesendet wurde und nun an dem Dienstanbieter cachegespeichert/gespeichert wird (z. B. ein Inhalt, der vorhergehend bedient wurde und nun in einem Speicher bei dem Dienstanbieter gespeichert wird). Zusätzlich kann ein Dienstergebnisinhalt aus irgendeiner Kombination der obigen Beispiele bestehen.
  • Bei einem Ausführungsbeispiel wird der Dienst durch den Dienstanbieter kontinuierlich ausgeführt. Bei einem anderen Ausführungsbeispiel wird der Dienst nicht eingerichtet oder beginnt nicht wirksam zu sein, bis die Clientvorrichtung eine Kommunikation mit dem Dienstanbieter eingerichtet hat. Bei noch einem anderen Ausführungsbeispiel wird der Dienst eingerichtet und/oder startet, nachdem der Dienstanbieter durch den Dienstpositionsverwalter identifiziert ist, bevor die Clientvorrichtung eine Kommunikation mit dem Dienstanbieter einrichtet. Mit Bezug auf 3A und 3B beispielsweise wird, nachdem der SLM 120 einen Dienstanbieter 130 als einen Anbieter der spezifizierten Dienstart ausgewählt hat, eine Nachricht A an den Dienstanbieter 130 gesendet, wobei bewirkt wird, dass der Dienstanbieter 130 den Dienst einrichtet und/oder startet.
  • Bei einem Schritt 418 von 4 wird der Dienstergebnisinhalt an die Clientvorrichtung gesendet (z. B. strömungsmäßig übertragen). Die Daten, die das Dienstergebnis bilden, können gesendet werden, wenn die Eingangsdaten bedient werden, oder die Dienstergebnisdaten können cachegespeichert werden, bevor dieselben gesendet werden.
  • Die Schritte 414, 416 und 418 können gleichzeitig durchgeführt werden. Das heißt, der ausgewählte Dienstanbieter (z. B. der Dienstanbieter 130 von 13) kann ein Bedienen des Inhaltselements beginnen, bevor das gesamte Inhaltselement bei dem Dienstanbieter 130 empfangen ist, und Dienstergebnisdaten können beginnen, aus dem Dienstanbieter 130 zu fließen, bevor das Bedienen des gesamten Inhaltselements abgeschlossen ist. Auf ähnliche Weise kann das Bedienen eines Abschnitts eines Inhaltselements im Gange sein, während das Ergebnis eines Bedienens eines anderen Ab schnitts des Inhaltselements durch die Clientvorrichtung empfangen wird.
  • Wenn der Dienstergebnisinhalt einmal an die Clientvorrichtung 150 geliefert ist (1 und 3), kann die Sitzung beendet werden. Es sollte klar sein, dass eine Dienstsitzung auf den Abschluss einer Dienstsitzung oder vor dem Abschluss einer Dienstsitzung beendet werden kann, wenn die angeforderte Beendigung der Dienstsitzung vorgenommen wurde. Bei einem Ausführungsbeispiel, bei dem der SLM 120 eine gewisse Art einer Aufzeichnung von Anbietern hält, denen Sitzungen zugewiesen wurden, kann die Aufzeichnung aktualisiert werden, sobald die Sitzung beendet ist oder sobald ein Dienstanbieter ein Inhaltselement bedient hat. Ansätze zum Aktualisieren der Aufzeichnung wurden oben beschrieben.
  • 5 ist ein Flussdiagramm 500 eines Verfahrens zum Verwalten des Bedienens eines Inhalts gemäß einem Ausführungsbeispiel der vorliegenden Erfindung. Obwohl in dem Flussdiagramm 500 spezifische Schritte offenbart sind, sind derartige Schritte exemplarisch. Das heißt, Ausführungsbeispiele der vorliegenden Erfindung sind für ein Durchführen verschiedener anderer Schritte oder Variationen der Schritte, die in dem Flussdiagramm 500 dargelegt sind, gut geeignet. Es ist klar, dass die Schritte in dem Flussdiagramm 500 in einer zu der präsentierten unterschiedlichen Reihenfolge durchgeführt werden können und dass eventuell nicht alle der Schritte in dem Flussdiagramm 500 durchgeführt werden.
  • Alle oder ein Teil der Verfahren, die durch das Flussdiagramm 500 beschrieben sind, können unter Verwendung computerlesbarer und computerausführbarer Anweisungen implementiert werden, die beispielsweise in computerverwendbaren Medien eines Computersystems oder einer ähnlichen Vorrichtung resident sind. Bei dem vorliegenden Ausführungsbeispiel ist das Flussdiagramm 500 durch das System 100 von
  • 13 implementiert. Genauer gesagt, wird das Flussdiagramm 500 durch den Dienstpositionsverwalter 120 von 13 implementiert.
  • Bei einem Schritt 502 von 5, auch unter Bezugnahme auf 1 und 3, wird eine erste Nachricht (z. B. die Nachricht 2) von dem Portal 140 empfangen, die ein Inhaltselement identifiziert. Das Portal 140 befindet sich in Kommunikation mit der Clientvorrichtung 150.
  • Bei einem Schritt 504 von 5 wird eine Dienstart, die an dem Inhaltselement durchgeführt werden soll, identifiziert. Die Dienstart kann in der Nachricht des Schritts 502 identifiziert sein. Mit Bezug auf 1 und 3 kann die Dienstart durch die Clientvorrichtung 150, durch das Portal 140 oder durch den Dienstpositionsverwalter 120 identifiziert werden.
  • Bei einem Schritt 506 von 5 werden Informationen hinsichtlich einer aktuellen Ressourcenverfügbarkeit von einer Mehrzahl von Dienstanbietern empfangen. Die Informationen werden aus fortlaufenden Ressourcenmessungen ermittelt. Die Ressourcenmessungen, die empfangen werden, können sowohl Poll-basierte als auch Push-basierte Daten umfassen. Gemäß einem Ausführungsbeispiel kann die Auswahl basierend auf einer Kombination von Poll-basierten und Push-basierten Daten vorgenommen werden. Dieser Ansatz ermöglicht, dass der SLM 120 seine Auswahl einer Dienstposition (z. B. des Dienstanbieters 130) anpassen kann, um mit verfügbaren Ressourcen übereinzustimmen.
  • Bei einem Schritt 508 von 5, auch unter Benzugnahme auf 1 und 3, wird ein Anbieter einer Dienstart, die an dem Inhaltselement durchgeführt werden soll, ausgewählt (z. B. wird der Dienstanbieter 130 ausgewählt). Ansätze zum Auswählen eines Dienstanbieters wurden vorhergehend hierin beschrieben.
  • Bei einem Schritt 510 von 5 wird bei einem Ausführungsbeispiel eine zweite Nachricht (z. B. die Nachricht 3 von 1 und 3) an das Portal gesendet. Bei einem anderen Ausführungsbeispiel wird die zweite Nachricht an die Clientvorrichtung gesendet, wobei das Portal umgangen wird. Die zweite Nachricht umfasst Informationen, die den ausgewählten Dienstanbieter identifizieren, wobei ermöglicht wird, dass eine Kommunikation zwischen der Clientvorrichtung von dem Portal an den Dienstanbieter übertragen wird (z. B. von dem Portal 140 an den Dienstanbieter 130 von 1 und 3).
  • Bei einem Schritt 512 von 5 wird bei einem Ausführungsbeispiel eine dritte Nachricht (z. B. die Nachricht D von 3A und 3B) an den ausgewählten Dienstanbieter gesendet. Die dritte Nachricht kann die Identität des Inhaltselements und/oder die Identität der Inhaltsquelle umfassen. Die dritte Nachricht kann ferner verwendet werden, um den Dienstanbieter zu warnen, wobei ermöglicht wird, dass der Dienstanbieter ein Einrichten und/oder Ausführen des Dienstes beginnen kann (falls der Dienst nicht bereits ausgeführt wird). Ansprechend auf die dritte Nachricht kann der Dienstanbieter ferner die Inhaltsquelle kontaktieren, um eine Lieferung (z. B. strömungsmäßige Übertragung) des Inhaltselements von der Inhaltsquelle an den Dienstanbieter einzuleiten. Anstelle einer dritten Nachricht können die ebenen beschriebenen Aktivitäten ansprechend darauf beginnen, dass die Clientvorrichtung und der Dienstanbieter eine Kommunikation einrichten. Ein Dienstergebnisinhalt wird dann von dem Dienstanbieter an die Clientvorrichtung gesendet (z. B. strömungsmäßig übertragen).
  • Zusammenfassend gesagt, liefern Ausführungsbeispiele der vorliegenden Erfindung Verfahren und Systeme, die Dienste für eine große Anzahl von diversen Clientvorrichtungen liefern. Eine Vielfalt von Diensten wird geliefert, um die Präferenzen und Erfordernisse der diversen Clients aufzu nehmen. Um eine Verstopfung zu vermeiden, werden die Dienste durch eine Anzahl von Dienstanbietern geliefert, die durch einen Dienstpositionsverwalter verwaltet sind. Inhaltselemente, die durch die Clientvorrichtungen angefordert werden, werden zu einem Bedienen basierend auf einer Dienstanbieterressourcenverfügbarkeit an die Dienstanbieter gerichtet. Die Clientvorrichtungen müssen jedoch lediglich eine gut veröffentlichte Portal-Site kontaktieren, um eine Sitzung zu beginnen und Inhaltselemente anzufordern. Die Clientvorrichtungen werden automatisch und transparent während der Sitzung an den geeigneten Dienstanbieter übertragen. Aus der Perspektive der Clientvorrichtung gibt es einen einzigen Kontaktpunkt. Transparent für die Clientvorrichtung ist der Fluss von Nachrichten und Daten durch das Inhaltsliefersystem, das zu der Lieferung eines Dienstergebnisinhalts an die Clientvorrichtung über einen Dienstanbieter führt, der durch das System ausgewählt ist. Transparent für den Endbenutzer an der Clientvorrichtung ist die nahtlose Übertragung der Sitzung von dem anfänglichen Kontaktpunkt an den ausgewählten Dienstanbieter.
  • Die vorstehenden Beschreibungen spezifischer Ausführungsbeispiele der vorliegenden Erfindung wurden zu Darstellungs- und Beschreibungszwecken vorgelegt. Dieselben sollen nicht erschöpfend sein oder die Erfindung auf die präzisen offenbarten Formen begrenzen, und es ist offensichtlich, dass viele Modifikationen und Variationen angesichts der obigen Lehre möglich sind. Die Ausführungsbeispiele wurden gewählt und beschrieben, um am besten die Prinzipien der Erfindung und die praktische Anwendung derselben zu erläutern, um dadurch zu ermöglichen, dass andere Fachleute auf dem Gebiet die Erfindung und verschiedene Ausführungsbeispiele mit verschiedenen Variationen, die für die spezielle betrachtete Verwendung geeignet sind, am besten nutzen können. Es ist beabsichtigt, dass der Schutzbereich der Erfindung durch die hieran beigefügten Ansprüche und deren Äquivalente definiert sein soll.

Claims (9)

  1. Ein Verfahren zur Dienstpositionsverwaltung für Streaming-Medien, wobei das Verfahren folgende Schritte aufweist: Identifizieren (404) eines Diensttyps, der an einem Element eines Streaming-Inhalts durchgeführt werden soll, wobei das Element eines Streaming-Inhalts während einer Sitzung mit einer Clientvorrichtung (150) identifiziert wird; Empfangen (406) von Ressourcenverfügbarkeitsinformationen von einer Mehrzahl von Dienstanbietern (130, 132), wobei die Informationen aus laufenden Ressourcenmessungen ermittelt werden; Auswählen (408) eines Dienstanbieters aus der Mehrzahl von Dienstanbietern (130, 132), der zum Durchführen des Dienstes in der Lage ist, basierend auf den Ressourcenverfügbarkeitsinformationen; und Liefern (410) von Informationen zum Übertragen der Sitzung auf den Dienstanbieter (130, 132), wobei der Dienstanbieter (130, 132) den Dienst an dem Element eines Streaming-Inhalts durchführt, dadurch gekennzeichnet, dass das Verfahren ferner ein Empfangen von Push-basierten Ressourcenverfügbarkeitsinformationen zusammen mit Sitzungsbeginn-/-beendigungsinformationen und ein regelmäßiges Abfragen von Dienstanbietern (130, 132) aufweist, falls die Ressourcenverfügbarkeitsinformationen nicht in einem vorbestimmten Zeitraum empfangen werden.
  2. Das Verfahren gemäß Anspruch 1, bei dem die Ressourcenverfügbarkeitsinformationen, die empfangen werden, aus einer Gruppe stammen, die Poll-basiert und Push-basiert umfasst.
  3. Das Verfahren gemäß Anspruch 1, bei dem die Ressourcenverfügbarkeitsinformationen eine Kombination von Poll-basierten und Push-basierten Informationen sind.
  4. Das Verfahren gemäß Anspruch 1, bei dem das Empfangen aus einem regelmäßigen Push von Ressourcenverfügbarkeitsinformationen von den Dienstanbietern erfolgt.
  5. Das Verfahren gemäß Anspruch 1, bei dem Push-basierte Ressourcenverfügbarkeitsinformationen empfangen werden, falls in einem vorbestimmten Zeitraum keine Sitzungsbeginn-/-beendigungsinformationen empfangen werden.
  6. Das Verfahren gemäß Anspruch 1, bei dem das Auswählen folgende Schritte aufweist: Beibehalten einer Aufzeichnung von Anbietern, an die Sitzungen übertragen wurden; und Auswählen des Dienstanbieters basierend auf der Aufzeichnung und den Informationen, die empfangen werden.
  7. Das Verfahren gemäß Anspruch 1, bei dem die gegenwärtig verfügbaren Ressourcen die Anzahl von freien Rechenzyklen und die Menge an freiem Speicher aufweisen, die zu einem gegebenen Zeitpunkt verfügbar sind.
  8. Das Verfahren gemäß Anspruch 7, bei dem gegenwärtig verfügbare Ressourcen ferner einen Schätzwert der Menge an freier Netzwerkbandbreite aufweisen, die einem Inhaltsserver und dem Client verfügbar ist.
  9. Das Verfahren gemäß Anspruch 1, bei dem der Streaming-Inhalt bedient wird und an eine Clientvorrichtung geliefert wird, wie derselbe empfangen wird.
DE602004011211T 2003-05-19 2004-05-13 Verfahren zur anpassung der dienstortplazierung auf der basis von aus dienstknoten empfangenen neueren daten und aktionen des dienstortsmanagers Expired - Lifetime DE602004011211T2 (de)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US47185103P 2003-05-19 2003-05-19
US471851P 2003-05-19
US10/698,816 US20040237097A1 (en) 2003-05-19 2003-10-30 Method for adapting service location placement based on recent data received from service nodes and actions of the service location manager
US698816 2003-10-30
PCT/US2004/015361 WO2004105353A2 (en) 2003-05-19 2004-05-13 Method for adapting service location placement based on recent data received from service nodes and actions of the service location manager

Publications (2)

Publication Number Publication Date
DE602004011211D1 DE602004011211D1 (de) 2008-02-21
DE602004011211T2 true DE602004011211T2 (de) 2008-12-24

Family

ID=33457274

Family Applications (1)

Application Number Title Priority Date Filing Date
DE602004011211T Expired - Lifetime DE602004011211T2 (de) 2003-05-19 2004-05-13 Verfahren zur anpassung der dienstortplazierung auf der basis von aus dienstknoten empfangenen neueren daten und aktionen des dienstortsmanagers

Country Status (6)

Country Link
US (1) US20040237097A1 (de)
EP (1) EP1625725B1 (de)
KR (1) KR100755617B1 (de)
AT (1) ATE383708T1 (de)
DE (1) DE602004011211T2 (de)
WO (1) WO2004105353A2 (de)

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100757892B1 (ko) 2005-12-07 2007-09-11 한국전자통신연구원 소프트웨어 스트리밍 서비스 제공 장치 및 그 방법
US8904442B2 (en) 2007-09-06 2014-12-02 At&T Intellectual Property I, Lp Method and system for information querying
KR101665542B1 (ko) * 2007-12-11 2016-10-12 톰슨 라이센싱 사용자들에 의한 콘텐츠로의 액세스를 최적화하기 위한 디바이스 및 방법
JP5006941B2 (ja) * 2007-12-26 2012-08-22 富士通株式会社 通信端末
US8386629B2 (en) * 2007-12-27 2013-02-26 At&T Intellectual Property I, L.P. Network optimized content delivery for high demand non-live contents
US20110196964A1 (en) * 2008-10-14 2011-08-11 Srikanth Natarajan Managing event traffic in a network system
US20130117418A1 (en) * 2011-11-06 2013-05-09 Akamai Technologies Inc. Hybrid platform for content delivery and transcoding
US20130219423A1 (en) * 2012-02-16 2013-08-22 General Instrument Corporation Algorithmic Media Stream Selection
US9769512B2 (en) * 2012-11-08 2017-09-19 Time Warner Cable Enterprises Llc System and method for delivering media based on viewer behavior
US9485456B2 (en) 2013-12-30 2016-11-01 Akamai Technologies, Inc. Frame-rate conversion in a distributed computing system
KR20170065575A (ko) * 2014-09-24 2017-06-13 브이5 시스템즈, 인크. 동적 데이터 관리

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6003030A (en) * 1995-06-07 1999-12-14 Intervu, Inc. System and method for optimized storage and retrieval of data on a distributed computer network
JP3288199B2 (ja) * 1995-06-30 2002-06-04 富士通株式会社 ビデオデータ配信装置
US6055433A (en) * 1996-09-20 2000-04-25 Northern Telecom Limited Data processing system and method for balancing a load in a communications network
US5937388A (en) * 1996-12-05 1999-08-10 Hewlett-Packard Company System and method for performing scalable distribution of process flow activities in a distributed workflow management system
US6442165B1 (en) * 1998-12-02 2002-08-27 Cisco Technology, Inc. Load balancing between service component instances
US6516350B1 (en) * 1999-06-17 2003-02-04 International Business Machines Corporation Self-regulated resource management of distributed computer resources
US6463454B1 (en) * 1999-06-17 2002-10-08 International Business Machines Corporation System and method for integrated load distribution and resource management on internet environment
US20020152305A1 (en) * 2000-03-03 2002-10-17 Jackson Gregory J. Systems and methods for resource utilization analysis in information management environments
US20030046396A1 (en) * 2000-03-03 2003-03-06 Richter Roger K. Systems and methods for managing resource utilization in information management environments
US20020056123A1 (en) * 2000-03-09 2002-05-09 Gad Liwerant Sharing a streaming video
US6658000B1 (en) * 2000-06-01 2003-12-02 Aerocast.Com, Inc. Selective routing
TW532040B (en) * 2000-10-20 2003-05-11 Koninkl Philips Electronics Nv Method and system for transferring a communication session
US20030088686A1 (en) * 2001-01-19 2003-05-08 Jennings Charles A. System and method for streaming media
US20040117427A1 (en) * 2001-03-16 2004-06-17 Anystream, Inc. System and method for distributing streaming media
US20020174247A1 (en) * 2001-04-02 2002-11-21 Bo Shen System and method for dynamic routing to service providers
US6804492B2 (en) * 2001-04-04 2004-10-12 Hughes Electronics Corporation High volume uplink in a broadband satellite communications system
US7457265B2 (en) * 2001-06-13 2008-11-25 Telefonaktiebolaget Lm Ericsson (Publ) Mobility management entity for high data rate wireless communication networks

Also Published As

Publication number Publication date
US20040237097A1 (en) 2004-11-25
ATE383708T1 (de) 2008-01-15
KR20060012633A (ko) 2006-02-08
KR100755617B1 (ko) 2007-09-06
WO2004105353A2 (en) 2004-12-02
EP1625725A2 (de) 2006-02-15
DE602004011211D1 (de) 2008-02-21
WO2004105353A3 (en) 2005-03-24
EP1625725B1 (de) 2008-01-09

Similar Documents

Publication Publication Date Title
DE60216918T2 (de) Verfahren und computersystem zur auswahl eines randservercomputers
CN100484069C (zh) 一种文件数据分发方法及相关设备
DE112012001557B4 (de) Voraussagende Platzierung von Inhalt durch Netzwerkanalyse
JP4972409B2 (ja) ノード及びネットワークの特性を考慮したサービスロケーション管理を行うためのシステム
DE112011104651B4 (de) Content-Sharing zwischen mobilen Terminals
EP0961490A2 (de) Internet Convolution Audio/Videoserver
DE10297645B4 (de) Verfahren und Einrichtung zum Lastteilen und zur Datenverteilung in Servern
CA2743949A1 (en) System and method of local resource delivery
DE10256600A1 (de) Verfahren und Vorrichtung zum Verhandeln von Mobildiensten
DE602004011211T2 (de) Verfahren zur anpassung der dienstortplazierung auf der basis von aus dienstknoten empfangenen neueren daten und aktionen des dienstortsmanagers
CN110545327B (zh) 一种信息推送方法及系统
DE602004009176T2 (de) Dienstverwaltung durch verwendung mehrerer dienstort-manager
CN111193789A (zh) 订阅信息推送方法、装置、计算机设备和可读存储介质
EP1627497B1 (de) System und verfahren zur auswahl eines dienstanbieters zur diensteerbringung bezüglich durch ein client-gerät angeforderter inhalte
EP1625724B1 (de) Verfahren und vorrichtung zur dienstanbieterauswahl
DE102018100526A1 (de) Reduzieren von Umleitungen
KR100727738B1 (ko) 서비스 제공자 간의 미디어 서비스 세션의 핸드오프 관리방법과 장치 및 네트워크 시스템
DE112014000242T5 (de) Skalierbare digitale Videoaufzeichnungen auf Netzwerkbasis über eine Architektur auf Shard-Basis
US20040236847A1 (en) Systems and methods for performing a service on content requested by a client device
JP2025141364A (ja) データ圧縮システム
Buchinger et al. Optimal server bandwidth for mobile video on demand
KR20020038243A (ko) 웹페이지 자동 이동 시스템을 이용한 고객성향분석 방법및 시스템

Legal Events

Date Code Title Description
8364 No opposition during term of opposition