Um einen Blick auf Alternativen zu werfen, werden im nächsten Kapitel weitere Möglichkeiten für Streaming vorgestellt. Eine Übertragungslösung bei Proton, die Pull und UDP verwendet, wäre gegenüber der momentanen Anwendung von Vorteil.

4.4 Unterschiedliche Streaming-Methoden für den Vergleich

4.4.1 Historisches zu Streaming

Bei der Veröffentlichung des 'world wide web' vor über 20 Jahren machte der Wissenschaftler Tim Berners-Lee von 'Cern' Dokumente in Schriftform remote über das Internet abrufbar¹. Audio über Internet gab es auch schon erstaunlich früh. So gibt Prof. Hußmann von der Ludwig-Maximilians-Universität München in seiner Vorlesung zu 'Multimedia im Netz' an:

„1991: The World Wide Web makes its debut on the Internet.

1992: World's first MBone audio cast (vat), 23rd IETF, San Diego

1995: RealAudio brings streaming audio to Web users. Streaming video soon follows.“²

Bernd Girod von der Stanford University gibt in seinem handout auch noch an:

„1994: Rolling Stones concert on MBone“³

Trotz dieser frühen Pionierleistungen von Audioübertragungen im Internet brauchte es noch einige Entwicklung, um Audio- und Video-Streaming zu etablieren.

4.4.2 Push-Server und Pull-Clients

Bei Streaming-Servern wird auch zwischen „Pull“ und „Push“ unterschieden - je nachdem, wie die Daten ausgeliefert werden.

Push-Server

Für Media-Streaming-Server können auch Push-Server zum Einsatz kommen. Der Server liefert kontinuierlich Daten, ohne eine Bestätigung oder eine Abfrage abzuwarten. Der Push-Server kontrolliert den Sendeprozess.⁴ „Oftmals wird ein Push Server auch als Data Pump bezeichnet“.⁵ Diese Server verwenden ein UDP basierendes Anwendungsprotokoll wie RTP für die Video- und/oder Audio-Datenübertragung. Im Push-Modus gibt es keinen Stopp. Der Server bemerkt nicht, ob ein Client verbunden ist oder nicht.⁶

Es bedarf einer zusätzlichen Kommunikationsebene, um den Datenfluss zu kontrollieren oder auch von der Client-Seite anzufragen/ initiieren. Ansonsten schickt der Push-Server die Daten nur ins Netzwerk, z.B. an eine Multicast-Adresse, unidirektional, ohne Feedback zu erwarten. Für die Kontrolle von Servern im 'Data Pump'-Betrieb kann RTSP für Kontroll-Anweisungen verwendet werden; typischerweise über TCP-Verbindungen.⁷

Pull-Clients

BRTP, Barix RTP

Um die Vorzüge von UDP und RTP zu nutzen, aber trotzdem den Pull-Modus vom Client zu verwenden, hat Barix BRTP entwickelt. BRTP steht für Barix RTP. Der Server sendet den Stream nur, wenn er angefragt wurde.⁸ Der Streaming-Client be“zieht“ (Pull), in dem er alle 1, 2 Sekunden eine Anfrage an den Streaming-Server schickt und so den Port in einer Firewall beim Client offen hält.

TCP und http

Auf der anderen Seite gibt es das typische Client-Pull-Modell, wie es bei jedem Web-Server zum Einsatz kommt. Der Client fragt die Informationen an, der Server stellt sie bereit und übermittelt sie; der Client bestätigt den Erhalt. Wenn der Client dann noch mehr Daten will, liefert der Server diese.⁹ Das ist typisch für einen Http-Stream (und damit auch TCP).

Dieses Verhalten der Pull-Clients löst aber sogenannte „bursts“ aus. Sobald der Client Daten anfordert - der Client kontrolliert den Prozess - soll der Server ausliefern. (Noch mehr ins Gewicht fällt das bei On-Demand-Streaming.) Dabei wäre ein „hinreichend großer und nahezu konstanter Datendurchsatz für die gesamte Netzauslastung wesentlich günstiger“¹⁰, wie das ein Push-Server propagiert und Quality of Service (QoS) im Netzwerk versucht, sicher zu stellen. (Manche Firmware für Router stellt QoS zur Verfügung.¹¹) „In großen Netzen wie dem Internet ist diese Forderung jedoch unrealistisch. Das Netz hat sich aus Burstanwendungen heraus entwickelt.“¹² Die Realisierung von Push-Streaming-Servern ist aufwändiger zu realisieren und nicht so gängig wie das Pull-Client-Modell, das bei jeder http-Web-Page Anwendung findet.

>>> Mehr zu TCP, UDP und RTP im nächsten Kapitel