Netzwerkanwendungen, Teil 2

Neben der im ersten Teil der Serie beschriebenen direkten Kommunikation über E-Mail besteht auch die Möglichkeit, Informationen in Diskussionsforen auszutauschen:

• Die Teilnehmer können Beiträge (Artikel; Englisch: news) schreiben und in dem Forum veröffentlichen.

• Andere Teilnehmer können auf diese Artikel antworten. Diese Antworten werden als neue Beiträge veröffentlicht, auf die die Forumsteilnehmer wiederum reagieren können. Zur besseren Übersicht stellt die Anwendung alle Antworten auf einen Beitrag als gemeinsamen Baum dar. Man spricht dann von Threads - dem englischen Wort für Faden oder Zwirn. Dementsprechend markiert der Newsreader von Mozzila solche Diskussionen mit dem Symbol einer Zwirnrolle.

Diese Diskussionsforen (Newsgroups) sind auf speziellen News-Servern abgelegt. Einen Verbund vieler News-Server bildet das USENET (ursprünglich Unix User Network). Die daran beteiligten Server tauschen untereinander ständig die neuen Artikel aus (Replikation), so dass ein einheitlicher Stand gewährleistet ist. Allerdings kann ein Server nicht alle Newsgroups bereitstellen, sondern immer nur einen Teilbereich abdecken. Daneben ist es auch möglich, mit der gleichen Technologie private oder interne News-Server zu betreiben.

Die Vielzahl von Diskussionsgruppen ist hierarchisch unterteilt. Die einzelnen Namensbestandteile sind durch Punkte getrennt, und es gilt die Regel "Vom Allgemeinen zum Speziellen". Die ersten Kürzel spezifiziert das Hauptthema oder ein Land. Einige Beispiele sind:

• comp.speech.research - Ein Forum zur Erforschung der Sprachverarbeitung mit Computern.

• de.sci.informatik.ki - Eine deutsche Gruppe zum Thema "Künstliche Intelligenz".

• rec.games.majong - Alles über das Spiel Majong (Das Kürzel rec steht für recreation; Erholung).

Teilnahme an Newsgroups

Newsgroups findet man über spezielle Suchdienste wie etwa findolin. Die allermeisten Newsgroups sind unmoderiert. Allerdings wird an die Teilnehmer appelliert, bestimmte Regeln einzuhalten. Man sollte sich klar machen, dass ein eigener Beitrag von Millionen von Menschen gelesen werden könnte. Daher sind Klarheit und Sorgfalt notwendig, um eventuellen Missverständnissen vorzubeugen. Allzu schnell wird ein Beitrag falsch verstanden und führt dann zu einem erbitterten Austausch von News. In der RFC 1855 "Netiquette Guidelines" sind allgemeine Regeln für Newsgroups und andere Kommunikationsdienste zusammengestellt.

Um an Newsgroups teilzunehmen, benötigt man einen entsprechenden Newsreader. Dazu stehen spezielle Programme zur Verfügung. Alternativ bieten die meisten E-Mail-Programme die entsprechende Funktionalität. Man muss nur noch einen passenden News-Server auswählen. Das kann der Server eines Netzanbieters sein (etwa news.t-online.de bei T-Online). Daneben gibt es kommerzielle oder frei verfügbare Server wie den www.individual.de der Freien Universität Berlin. Der komplette Verweis auf eine Gruppe hat dann die Form

news://news.t-online.de/de.comm.internet.misc

Der Austausch von Artikeln erfolgt über das Network News Transfer Protocol (NNTP). Dieses Protokoll spezifiziert eine Anzahl von Befehlen, um über eine strom-orientierte Verbindung Informationen und die Beiträge zu übertragen. Es umfasst sowohl die Kommunikation zwischen News-Server und Newsreader als auch den Abgleich zwischen zwei News-Servern. Für die Nachrichten wird die gleiche Formatierung wie für E-Mails verwendet. Entsprechende Kopfeinträge übermitteln die erforderlichen Informationen. So wird im Eintrag Newsgroups: festgelegt, zu welcher Gruppe oder zu welchen Gruppen ein Beitrag gehört. Der Rumpf der Nachricht wird mittels MIME kodiert.

Netzwerk-Management mit SNMP

In der Diskussion der verschiedenen Protokollebenen hat sich bereits gezeigt, dass deren Designer Wert auf ein weit gehend selbstständiges, unüberwachtes Funktionieren des Netzes gelegt haben. Die Protokolle enthalten Mechanismen, um mit auftretenden Fehlern umgehen zu können. Die Knoten passen teilweise ihr Verhalten an die aktuelle Situation an. Trotzdem benötigt man Möglichkeiten, das Verhalten eines Netzes im Detail untersuchen zu können, um Fehler oder Schwachstellen aufzuspüren.

Ein dazu häufig verwendetes Protokoll ist das Simple Network Management Protocol (SNMP). SNMP erlaubt es, zahlreiche Parameter von Knoten im Netz abzufragen. Jeder Knoten, der an diesem System teilnimmt, stellt dazu einen SNMP-Server bereit. Von anderen Systemen aus kann man dann mit einem Client die Statusinformationen abfragen. SNMP realisiert dazu ein Abfrage-Antwort-Protokoll auf der Basis von UDP. Die beiden wesentlichen Operationen sind GET, um Werte zu lesen, und SET, um Werte zu setzen.

Der Netzwerkknoten sammelt im laufenden Betrieb ständig Informationen und legt sie in einer internen Datenbank, der Management Information Base (MIB), ab. Über ein spezielles Identifizierungssystem kann man per SMTP jede dieser Variablen im MIB abfragen. SNMP verwendet dazu eine standardisierte Darstellung zur Übermittlung von Datentypen wie Integer-Zahlen oder Gleitkommazahlen.

Multimedia-Kommunikation

Mit seiner ständig wachsenden Ausdehnung und Verfügbarkeit ist das Internet auch als Plattform für Multimedia-Anwendungen interessant. Unter Multimedia im eigentlichen Sinne versteht man die Integration verschiedener Medien in einer Anwendung oder in einem Dokument. Dabei können die Medien zeitunabhängig (Text, Grafik, Bild) oder zeitabhängig (Audio, Video) sein. Weiterhin lassen sich die Anwendungen in zwei Klassen aufteilen:

• Anwendungen zwischen zwei oder mehr Benutzern (Konferenz-Anwendungen)

• Anwendungen zwischen einem Server und einem Client (Streaming-Anwendungen)

Zeitabhängige Multimedia-Anwendungen stellen hohe Anforderungen an die Übertragung. So benötigt etwa eine Video-Konferenz eine große Bandbreite bei gleichzeitig geringer Latenz. Die Synchronisation verschiedener Datenströme (etwa bei getrennten Audio- und Video-Kanälen) erfordert zusätzliche Maßnahmen zur Zusammenführung.

Real-Time Transport Protocol

Ein universelles Transportprotokoll für Multimedia-Daten ist das Real-Time Transport Protocol (RTP). Es soll die notwendigen Eigenschaften für eine Echtzeitkommunikation bereitstellen, dabei aber so wenige Festlegungen wie möglich enthalten. So bleibt es etwa der Anwendung selbst überlassen, wie sie mit Paketverlusten umgeht.

RTP setzt auf UDP auf. UDP bietet die notwendige Grundfunktionalität - Zustellung von Paketen ohne großen Overhead. RTP ergänzt diesen Paketdienst um einige für die Echtzeitkommunikation notwendige Elemente.

Der Header für RTP-Pakete ist mindestens 12 Byte lang. Er enthält eine 16 Bit große Sequenznummer für das Paket. Diese Nummer wird bei jedem Paket um Eins erhöht. Anhand dieser Nummern kann der Empfänger erkennen, ob er alle Pakete in der richtigen Reihenfolge erhält. Die zeitliche Beziehung stellt ein Feld mit einem Zeitstempel her. Dabei ist das exakte Format des Zeitstempels anwendungsabhängig.

Die Quelle des Datenstroms wird über eine 32-Bit-Zahl im Feld "Synchronization Source" (SSRC) mitgeteilt. Über ein 7 Bit großes Feld wird der Typ der Nutzdaten angegeben. Damit könnte beispielsweise ein Wechsel der Kodierungsmethode angezeigt werden. Schließlich kann ein RTP-Strom Beiträge von mehreren Quellen enthalten (zum Beispiel mehrere Mikrofonkanäle).

Die Bedeutung der einzelnen Datenfelder im RTP-Header erläutert folgende Tabelle.

RDP: Nur die Geschwindigkeit zählt

RTP ist optimiert für die schnelle Übertragung. Das Protokoll enthält keinerlei Elemente zum Umgang mit verlorenen Paketen oder etwa zur Überlastkontrolle. Allerdings ist es durchaus wünschenswert, dass der Empfänger über den aktuellen Zustand der Verbindung informiert wird. Beispielsweise könnte ein Sender bei einem Bandbreitenengpass zu einer Kodierung mit niedriger Datenrate wechseln.

Zur Überwachung und Steuerung einer RTP-Sitzung dient das Protokoll RTP Control Protocol (RTCP). Eine RTP-Sitzung besteht aus einem RTP- und einem RTCP-Kanal. Für eine Sitzung wird für RTP eine gerade Portnummer und für RTCP die darauf folgende ungerade Portnummer vergeben. Über RTCP tauschen die Kommunikationspartner parallel zu RTP Pakete aus. Dabei kommen in der Regel ebenfalls UDP-Pakete zum Einsatz. Diese Pakete beinhalten Sende- oder Empfangsberichte mit Übertragungsstatistiken. Die Statusberichte tauschen die Partner in periodischen Abständen aus.

Informationen über den Sender werden mit Quellenbeschreibungspaketen übermittelt. Als Kennung dient der so genannte kanonische Name (CNAME). Das übliche Format dafür ist user@host. Die Quellenbeschreibungspakete enthalten die Zuordnung zwischen SSRC und CNAME. Mit dieser Information kann der Empfänger die Daten dem Absender zuordnen. Damit kann er auch mehrere Quellen (etwa Audio, Video, Grafik) von einem gemeinsamen Sender unterscheiden.

Schließlich bietet RTCP die Möglichkeit, ergänzende Informationen parallel zu dem Datenstrom über RTP zu senden. Ein Beispiel hierzu sind Untertitel für einen Video-Strom. Trotz all dieser Funktionen streben beide Kommunikationspartner an, den Verkehr über RTCP auf etwa fünf Prozent des Datenaufkommens für den RTP-Verkehr zu beschränken.

RTP-Verbindungsaufbau

Vor einer Kommunikation über RTP muss eine Sitzung eingeleitet werden. Je nach Anwendung reicht diese Aufgabe von der einfachen Ankündigung einer Übertragung bis hin zum aufwendigen Aufbau einer Video-Konferenz. Dabei muss der Initiator zunächst die Gesprächspartner suchen und dann ein gemeinsames Kodierungsverfahren aushandeln.

Eine Arbeitsgruppe der Internet Engineering Task Force (IETF) hat dafür eine Reihe von Protokollen entwickelt. Um beispielsweise eine Telefonverbindung über Internet herzustellen, sind die Protokolle Session Initiation Protocol (SIP) und Session Description Protocol (SDP) gebräuchlich. Alternativ entwickelte ITU (International Telecommunication Union) die Empfehlung H.323 für den Gesprächsaufbau. Die Eigenschaften des Gesprächs werden dabei über das Call-Control-Protokoll H.245 bestimmt. Geräte, die über H.323 Verbindungen aufbauen, werden auch als H.323-Terminals bezeichnet.

Während der ITU-Standard H.323 vor allem im Umfeld professioneller TK-Anlagen zum Einsatz kommt, gewinnt das von der IETF festgelegte SIP in öffentlichen Netzen und bei Privathaushalten zunehmend an Bedeutung.

VoIP - Sprachübertragung über IP

Eine Anwendung von großer kommerzieller Bedeutung ist die Sprachübertragung für Telefongespräche. Daher begannen verschiedene Firmen frühzeitig, Lösungen zur Sprachübertragung über IP (Voice over IP, VoIP) zu entwickeln. Die paketorientierte Technik verspricht einen deutlichen Kostenvorteil gegenüber dem leitungsorientierten herkömmlichen Telefonsystem. Zum einen entfällt die Installation eines eigenen Netzwerks, und zum anderen ist die Übertragung innerhalb des Internets zumindest bei Fernverbindungen wesentlich preisgünstiger. Allerdings erwartet der Kunde einen vergleichbaren Stand bezüglich

• einfacher Bedienung

• guter Sprachqualität

• hoher Zuverlässigkeit

Im Folgenden werden die Grundprinzipien als Beispiel für eine Echtzeitkommunikation über das Internet beschrieben.

Das analoge Telefonnetz überträgt die Sprachsignale in dem Frequenzbereich von 300 bis 3300 Hz (Telefonbandbreite). Ausgehend von diesem Frequenzband wurde bei der Digitalisierung eine Abtastrate von 8000 Hz gewählt. Gemäß dem Nyquist-Kriterium (Maximalfrequenz = halbe Abtastrate) sind so Frequenzen bis 4000 Hz enthalten. Die Pulscodemodulation (PCM) kodiert dabei jeden Abtastwert als Zahlen. Der Wertebereich dieser Zahlen bestimmt den Signal-Rauschabstand der Übertragung und damit deren Qualität.

Kodierung spart Bandbreite

Für Gespräche im Telefonnetz nutzt man physiologische Schwächen des menschlichen Gehörs aus. Daher ist nicht über den gesamten Amplitudenbereich eine gleichmäßige Quantisierung notwendig. Für große Amplituden kann man eine gröbere Rasterung verwenden, ohne dass dadurch eine hörbare Verschlechterung der Sprachqualität auftritt. Auf diese Weise ist es möglich, mit nur 8 Bit Auflösung eine gute Qualität zu erreichen. Die Kombination aus 8 kHz Abtastrate und 8 Bit Auflösung ergibt eine nötige Bandbreite von 64 Kbit/s - den Standard in ISDN.

Die Datenrate lässt sich weiter verringern, wenn man spezielle Eigenschaften der Sprachsignale ausnutzt. Ein Ansatz dazu beruht auf der Annahme, dass die Amplituden aufeinander folgender Abtastwerte in der Regel nicht beliebig weit auseinander liegen. Überträgt man anstelle der Abtastwerte nur die Differenzen benachbarter Werte, so kann man den dann auftretenden kleineren Wertebereich mit weniger Bit quantisieren.

Bei adaptiven Verfahren wird der Wertebereich zusätzlich an die aktuelle Lautstärke angepasst. Dadurch erreicht man eine möglichst gute Übereinstimmung zwischen Wertebereich und auftretenden Amplituden. Ein Standard nach diesem Prinzip ist der "Adaptive Differenzielle PCM" (ADPCM) mit 32 Kbit/s gemäß ITU G.726. Gegenüber dem PCM-Standard wird bei nahezu gleicher Sprachqualität nur noch die halbe Datenrate benötigt. Ein Beispiel für den Einsatz dieses Standards ist DECT (Digital European Cordless Telephony) für schnurlose Telefone.

Kompression durch CELP

Sprachsignale enthalten noch sehr viel mehr Strukturen. Eine Reihe von Verfahren, die diese Strukturen weit gehend ausnutzen, beruhen auf dem Basisprinzip von Code Excited Linear Predictive Coding (CELP). Diese Verfahren benutzen spezielle adaptive Filter - so genannte lineare Prädiktoren - zur Vorhersage der nächsten Abtastwerte. Das Anregungssignal wird durch systematisches Probieren von Codes aus einem Vorrat ermittelt. Vertreter dieser Coder-Familie setzen die GSM-Netze für Handytelefonate ein.

Der so genannte CELP Full Rate Coder arbeitet mit 12,2 Kbit/s. Die neue Nachfolgetechnik Half Rate benötigt bei annähernd gleicher Sprachqualität nur noch 5,6 Kbit/s. Für VoIP weit verbreitet sind die Standards G.729A (CompuServe ACELP) mit 8 Kbit/s und G.723.1 Multi Rate Coder mit 5,3 und 6,3 Kbit/s. Ein neuerer Standard speziell für das Internet ist der Internet Low Bit Rate Codec (iLBC). Dieser Coder arbeitet bei 13,3 oder 15,2 Kbit/s. Er wurde speziell für Situationen, in denen Pakete verloren gehen, ausgelegt. In solchen Fällen wird mittels einer so genannten Packet-Loss-Concealment-Einheit für eine Überbrückung der fehlenden Blöcke ohne Störgeräusche gesorgt.

Dialoge enthalten einen Anteil von bis zu 50 Prozent Pausen. Eine weitere Datenreduktion ist daher möglich, wenn der Coder Sprachpausen nicht mit überträgt. Erkennt er, dass ein Teilnehmer im Moment nicht spricht, überträgt er keine Blöcke, die nur Hintergrundgeräusche enthalten. Um den Eindruck einer "toten Leitung" zu vermeiden, kann die Gegenseite ein künstliches Rauschen einspielen. Damit ist eine deutliche Reduktion der Datenkommunikation möglich. Allerdings können Fehlentscheidungen in der Pause-Detektion oder ein zu spätes Ansprechen auf eine beginnende Sprachaktivität zu einem sehr unnatürlichen Spracheindruck führen.

Massiver Overhead durch Header

Bei allen Codecs muss man zur Berechnung der Bandbreite zu den Sprachdaten noch die Paket-Header hinzuaddieren. Die Tabelle zeigt die entsprechenden Werte bei einem Coder mit 6 Kbit/s und einer Dauer von 30 ms für einen Sprachblock.

Bei der Übertragung über Ethernet kommen weitere 29 Byte (inklusive 3 Byte LLC-Header) pro Paket hinzu. Insgesamt ergeben sich somit 92 Byte pro Paket, in dem 23 Bytes Sprachinformationen enthalten sind. Mit 33,3 Paketen pro Sekunde resultiert daraus eine Bandbreite im Netzwerk von 24,5 Kbit/s pro Richtung und 49 Kbit/s für die Telefonverbindung.

Die Zusammenstellung zeigt, dass die verschiedenen Header in Summe gegenüber der Nutzlast dominieren. Daher wurden Protokollerweiterungen entwickelt, um die Länge der Header zu reduzieren. Ein Ansatzpunkt ist, einen Teil der Header-Informationen nur zu Beginn der Verbindung zu übertragen. Während der eigentlichen Datenübertragung ändern sich diese Informationen entweder gar nicht mehr oder nur geringfügig. Indem das Protokoll nur noch die Veränderungen überträgt, kann es die Länge der Header deutlich reduzieren.

Header Compression mit ROHC

Ein Problem besteht allerdings darin, dass einzelne Pakete verloren gehen können. Ohne weitere Maßnahmen würde dann unter Umständen ein Teil der Veränderungen fehlen, so dass der Empfänger fehlerhafte Werte rekonstruiert. Speziell für dieses Einsatzgebiet ist das Protokoll RObust Header Compression (ROHC), RFC 3095, definiert. Mit ROHC lässt sich eine Reduktion der Header von RTP, UDP und IP mit zusammen 20 Byte auf durchschnittlich 6 Byte erzielen, ohne die Sprachqualität zu beeinträchtigen.

Ein zweites wichtiges Kriterium für die Verbindungsqualität ist die Verzögerungszeit. Ab etwa 100 ms machen sich Verzögerungen im Gespräch störend bemerkbar. Laut ITU-T-Empfehlung gelten Verzögerungen bis 200 ms noch als gut und bis 400 ms gerade noch als akzeptabel. Die Sprachkodierung führt durch die Blockbildung bei den niedrigen Datenraten zu etwa 10 bis 30 ms Verzögerung. Hinzu kommt die Latenz der Verbindung.

Innerhalb eines Firmennetzes ist die resultierende Gesamtverzögerung in der Regel unterhalb der kritischen Grenzen. Bei einer Übertragung im Internet können sich allerdings durch die zahlreichen Zwischenstationen und Paketverluste deutliche Qualitätseinbußen ergeben.

Telefonanwendungen

Mit den beschriebenen Mitteln kann ein Rechner die Funktion eines Telefons übernehmen. Dazu genügen ein PC, eine handelsübliche Sound-Karte, ein Mikrofon und ein Lautsprecher sowie eine entsprechende Software. Eine einfache Anwendung ist das Telefonieren von Rechner zu Rechner.

Die entsprechenden Programme ähneln Chat-Programmen. Über einen Server kann man Verbindung zu den angemeldeten Personen aufnehmen. In der Regel können sich weitere Personen an dem Gespräch beteiligen, so dass eine Konferenz entsteht. Viele Programme unterstützen dabei die parallele Kommunikation über mehrere Medien. So sind in das Programm NetMeeting von Microsoft neben Audio auch Video und Whiteboard - ein gemeinsam genutztes Zeichentablett - integriert.

Neben der Kommunikation zwischen Rechnern ist auch die Verbindung zum öffentlichen Telefonnetz möglich. So bieten diverse Anbieter Gateways zwischen Internet und Telefonnetz an. Eine kostengünstige Verbindung besteht dann aus einer Internet-Verbindung bis zu einem Gateway in der Nähe des Ziels und einer Telefonverbindung vom Gateway bis zum Endteilnehmer. Das Gateway übernimmt die Umsetzung der Daten sowie der Signalisierungsinformationen. Bei H.323 ist ein so genannter Gatekeeper bei der Suche nach dem günstigsten Gateway behilflich.

Das Konzept lässt sich leicht zum Telefonieren zwischen zwei konventionellen Telefonen erweitern. Ein Teilnehmer ruft bei seinem lokalen Gateway an. Von dort wird eine RTP-Sitzung zu dem passenden Gateway in der Nähe des Ziels aufgebaut. Dieses leitet das Gespräch dann wieder an das konventionelle Telefon des Gesprächspartners weiter. (ala)