Bisher haben wir immer von Multimedia-Konferenzen im INTERNET gesprochen. Eine wesentliche Frage blieb bisher jedoch unbeantwortet: Welche Konferenzen existieren überhaupt, zu welchen Zeiten finden sie statt, und wie es ist möglich daran teilzunehmen?
Diese, sagen wir "Programmzeitschrift" wird ebenfalls mittels IP-Multicast im INTERNET verbreitet. Eine Konferenz wird dabei mit Hilfe des "Session Description Protocols" (SDP [Hand9611:SDP]) beschrieben. Diese Beschreibung beinhaltet Informationen wie:
Das Format ist dabei fest definiert, so daß entsprechende Programme diese Ankündigungen aussenden und auch empfangen können. "Sdr" ist ein Beispiel für ein solches Programm.
Übermittelt werden diese Ankündigungen mittels IP-Multicast unter Verwendung des Session Announcement Protocols (SAP [Hand9611:SAP]). Die Ankündigungen werden dabei periodisch an eine definierte Multicast-Adresse gesendet, so daß eine globale verteilte Datenbank entsteht.
Wie bereits in Kapitel [mcast] beschrieben, besteht das erste Problem darin, daß SAP mittels IP-Multicast übertragen wird. Um diese Pakete übertragen zu können, gibt es zwei Möglichkeiten:
Bei der zweiten Variante stellt sich die Frage, wie das konfiguriert werden muß. Dieser Tunnel zwischen den beiden Prozessen muß durch irgendeine Konfiguration eingerichtet werden. Besteht die PPP-Verbindung jedoch nur recht selten oder immer für relativ kurze Zeit, so entsteht hierdurch ein zusätzlicher Aufwand.
Die erste Variante ermöglicht die Übertragung der Informationen ohne weitere Konfiguration. Es besteht in diesem Falle sogar die Möglichkeit, daß die PPP-Implementierungen hierzu ein spezielles Protokoll verwenden, mit dem diese Announcements übertragen werden können. Somit lassen sich auch Kompressionsverfahren einsetzen, um die benötigte Bandbreite zu reduzieren.
| Zeitraum | Anzahl Announcements | Anzahl der versch. Announcements | Datenvolumen |
| 6,5h | 1364 | 26 | ca. 800 kbyte |
Die Messungen ergaben, daß im Durchschnitt ca. 270 bit/s für dieses Announcements benötigt werden. Die Announcements waren durchschnittlich 585 Bytes groß und wurden alle 7,5 Minuten erneut verschickt.
Auf dem ersten Blick scheint dies recht wenig zu sein. Es ist jedoch damit zu rechnen, daß in der nahen Zukunft die Benutzung von Mulimediadiensten im INTERNET zunehmen wird. Wichtig ist jedoch zu beachten, daß diese Durchschnittswerte nur die durchschnittliche Belastung zeigen. Da die Announcements jedoch teilweise bis zu 800 Bytes groß waren, entsteht hierdurch ein temporärer Engpaß.
Angenommen, zwei große Announcements mit 800 Bytes folgen dicht aufeinander. Werden diese, insgesamt 1600 Bytes (12,8 kbit), und nehmen wir weiter an, daß wir eine 28,8 kbit/s Modemverbindung benutzen, würde die Verbindung für ca. 0,5 Sekunden vollständig belegt sein. In dieser Zeit können keine Echtzeitdaten mehr übertragen werden, so daß es zu einem kurzen drop-out kommen würde. Natürlich ist es möglich die Daten verzögert abzuspielen, also die End-zu-End Verzögerung zu erhöhen. Dies mindert jedoch die Sprachqualität (bei Audio) bei einer bidirektionalen Verbindung extrem.
Da die uns zur Verfügung stehende Bandbreite ohnehin nicht ausreicht, die Multimedia-Daten in ihrer ursprünglichen Form zu übertragen und wir diese auf jeden Fall komprimieren müssen, sollten auch für andere Dienste kein einziges Byte verschenkt werden. Je mehr Bandbreite für die Übertragung der Multimediadaten zur Verfügung steht, desto besser ist die resultierende Qualität.
Aus diesem Grunde haben wir ein Verfahren entwickelt, mit dem die Session Announcements stark komprimiert werden können. Die Ergebnisse unserer Überlegungen sind in den nächsten Abschnitten aufgeführt.
Die Notwendigkeit, daß die Announcements regelmäßig, in ihrem vollen Umfang verschickt werden müssen, resultiert aus der Tatsache, daß wir eine globale verteilte Datenbank haben. Wird beispielsweise ein Rechner (oder genauer, ein Programm wie sdr) zu irgendeinem Zeitpunkt gestartet, besitzt er keine Informationen über aktuelle Announcements. Nur die Tatsache, daß diese immer wieder neu verschickt werden macht es möglich, daß dieser Rechner nach einigen Minuten dennoch das gesammte Wissen über die aktuellen Announcements erlangt hat.
Wenn wir uns unsere PPP-Verbindung betrachten stellen wir jedoch einen anderen Sachverhalt fest. Die PPP-Verbindung ist von ihrer Natur her immer eine direkte Verbindung zwischen zwei Rechnern. Somit ist es auch möglich, daß jede Seite sich "merkt", was die andere weiß. Es ist also nicht nötig die Session Announcements immer wieder in ihrer vollen Länge zu übertragen. Es reicht aus
Der erste Vorschlag macht eine einfache Form einer Kompression möglich, bei dem A nur feststellen muß, ob B die Ankündigung bereits erhalten hat. Die zweite Variante hat den Vorteil, daß nach einiger Zeit faktisch keine Daten für die Announcements mehr ausgetauscht werden müssen. Dafür ist der Aufwand ein wenig höher, da sichergestellt werden muß, daß B diese erste Ankündigung auch wirklich erhalten hat. Weiterhin muß sich dann B selber um das zeitgerechte Verschicken der Ankündigungen in seinem Teilnetz kümmern.
Wir haben uns der Einfachheit halber für die ersten Variante entschieden, und eine Komprimierung nach diesem Muster realisiert.
Die generelle Idee ist hierbei, daß wir ein Client-Server-Verhältnis zwischen den beiden Stationen haben, die über die PPP-Verbindung gekoppelt sind, haben. Der Server der einen und der Client der anderen Station haben beide eine gemeinsame Liste von Kontexten. Jeder dieser Kontexte enthält die Informationen über exakt eine Ankündigung. Identifiziert werden diese Kontexte durch eine Kontext-ID.
initialisiert. Da wir, wie bereits erwähnt, auch andere Announcement-Protokolle außer SAP/SDP mit diesem Verfahren komprimiert übertragen können, wird noch
im Kontext abgelegt.
Nachdem der Server den Kontext angelegt hat, sendet er (fast) alle Daten aus dem Kontext in einer ASSIGN Nachricht zum Client. Der Client, der diese empfängt durchsucht daraufhin seine eigene Liste der Kontexte nach der ebenfalls übermittelten Kontext-ID. Findet es einen Eintrag mit der gleichen Kontext-ID, so wird dieser Kontext gelöscht.
Der Client erzeugt nun einen neuen Kontext und speichert ebenfalls, analog zum Server, alle Daten in diesem Kontext. Im Anschluß daran, sendet er auf seiner Seite des Netzes dieses Announcement.
Wenn der Client diese Nachricht empfängt, sucht er mit Hilfe der Kontext-ID den richtigen Kontext. Nachdem dieser gefunden wurde, sendet der Client das Announcement, das im Kontext enthalten ist (vgl. Abbildung [cSAP-1]).
Damit dieses Announcement dennoch auf der Seite des Clients bekannt wird, benötigen wir somit einen Mechanismus um diesen Fehler signalisieren zu können. Der Client sendet in diesem Fall eine DELETED Nachricht an den Server zurück.
Sobald dieser diese Nachricht empfängt, sucht er den Kontext anhand der ebenfalls übermittelten Kontext-ID. Wenn er diesen findet, generiert er daraufhin eine neue ASSIGN Nachricht für diesen Kontext, und sendet sie zum Client (Abbildung [cSAP-error1]). Auf diesem Wege wird der Kontext im Client erneut angelegt, und der Fehler ist beseitigt.
Das einzige Problem, was in diesem Fall noch bestünde wäre, wenn nun auch diese DELETED oder die ASSIGN Nachricht verloren geht (vgl. Abbildung [cSAP-error2]). Der Server würde somit nicht über den Fehler informiert, oder der Client erhält nicht die neue Zuweisung, so daß dieses Announcement nicht auf der Seite des Client bekannt wäre. Da die Announcements jedoch periodisch neu verschickt werden, ergibt sich bei dem nächsten Announcement wiederum die gleiche Situation: Der Server sendet eine RETRANSMIT Nachricht, und der Client antwortet mit einer DELETED Nachricht. Die Wahrscheinlichkeit, daß gerade diese Pakete verloren gehen scheint sehr gering zu sein, so daß nach einiger Zeit auch dieses Announcement auf der Client-Seite bekannt wird.
Es gibt jedoch noch einen weitaus komplizierteren Fehlerfall. Angenommen ein Kontext (1) wurde beim Server und Client richtig zugewiesen und benutzt. Wenn der Server nun entschied den Kontext zu löschen, weil seit gewisser Zeit keine weiteren Announcements (a) mehr eingegangen sind, wird somit auch die Kontext-ID frei. Da unser entwickeltes Verfahren keine explizite Nachrichten zum Löschen eines Kontextes beim Server verschickt, existiert der Kontext weiterhin beim Client.
Wenn der Server dieselbe Kontext-ID (1) für ein neues Announcement (b) vergibt, sendet er eine ASSIGN Nachricht zum Client. Wie oben bereits beschrieben, entsteht hierdurch kein Problem, da der Client beim Empfang dieser Nachricht den alten Kontext zuerst löscht.
Sollte jedoch diese ASSIGN Nachricht verloren gehen, entsteht ein Problem. Empfängt der Server das gleiche Announcement (b) erneut, so geht er von einem korrekten Kontext beim Client aus. Er sendet somit nur eine RETRANSMIT Nachricht zum Client. Dieser empfängt diese, durchsucht seine Kontextliste nach der Kontext-ID (1) und findet noch den alten Kontext. Der Client geht nun davon aus, daß das Announcement (a) erneut geschickt werden soll, und sendet somit das falsche, alte Announcement (a) in sein Teil des Netzes (siehe Abbildung [cSAP-error3]). Es gibt keine Möglichkeit für ihn, diesen Fehler zu bemerken.
Aus diesem Grunde bekommt jeder Kontext und jede Nachricht eine sogenannte "Genneration-ID" hinzu. Diese ID wird vom Server verwaltet und jedesmal geändert (im Allgemeinen um eins erhöht), wenn die Kontext-ID neu vergeben wird. Empfängt nun der Client eine RETRANSMIT Nachricht, bei der die Generation-ID (2) nicht mit der im Kontext (1) übereinstimmt, weiß er, daß er mindestens eine ASSIGN Nachricht vom Server nicht erhalten hat. In diesem Fall löscht er den Kontext, und sendet eine DELETED Nachricht an den Server zurück (vgl. Abbildung [cSAP-error4]). Es ergibt sich dann der gleiche Sachverhalt wie zuvor beschrieben.
Damit auch bei unserem Vorschlag ein Kontext nicht unendlich lange erhalten bleibt, sollte der Server zu jedem Kontext eine Timeout-Zeit angeben. Diese wird bei jedem Eintreffen eines Announcements neu aktualisiert. In Zeiten, in denen der Server nicht viel zu tun hat, kann dieser seine Liste mit den Kontexten durchsuchen, und alle Kontexte löschen, bei denen diese Zeit abgelaufen ist. Es gibt keine explizite Benachrichtigung des Clients. Durch die erneute Vergabe einer zuvor benutzten Kontext-ID, wird der alte Kontext beim Client durch den Empfang der ASSIGN Nachricht ohnehin gelöscht.
Dennoch hat auch der Client die Option, Kontexte, die seit einer gewissen Zeit nicht mehr aktualisiert wurden, selbstständig zu löschen. Auch hier gibt es keine Signalisierung zum Server. Sollte nun dennoch ein Announcement für diesen Kontext beim Server eingehen, so bekommt der Client eine RETRANSMIT Nachricht. Da dieser die Kontext-ID nicht in seiner Liste findet, greift die gleiche Fehlerbehandlung wie oben beschrieben. Der Client sendet daraufhin eine DELETED Nachricht zurück, die der Server mit einer neuen ASSIGN Nachricht beantworten wird. Es enstehen auch in diesem Fall keine Fehlinterpretationen, noch gehen irgendwelche Announcements verloren.
Um diese Last zu verringern, können Client und Server die Option benutzen, die Kontexte nicht zu löschen, wenn sie sicher sind, daß der "Partner" der war, mit dem sie gerade zuvor Kontakt hatten. Auf diese Weise würden nur die RETRANSMIT Nachrichten übertragen werden müssen.
Es gibt nun die folgenden vier Konstellationen:
Eine detailierte Beschreibung unseres Protokolls ist in Anhang [cSAP-draft]
enthalten. Diese ist in der Form eines Internet-Drafts aufgebaut, so daß diese recht schnell verbreitet werden könnte. Aus diesem Grunde wurde diese Spezifikation auch in englischer Sprache erstellt.
Wir entwickelten hierfür ebenfalls ein Verfahren, um SDP Nachrichten zu komprimieren. Die Komprimierungsrate ist dabei um Einiges besser, als die einfache, von Mark Handley [Hand9611:SDP] vorgeschlagene Variante durch Benutzung von gzip.
An dieser Stelle wollen wir nicht genauer auf das Verfahren eingehen, da dies eine genaue Betrachtung jedes Feldes eines SDP Paketes voraussetzt. In Anhang [cSDP-draft] ist eine englischschprachige detailierte Spezifikation enthalten. Wie schon zuvor, wurde sie in Form eines Internet-Drafts gehalten, damit sie eine weite Verbreitung erfährt.
Das hier vorgestellte Verfahren ist im Prinzip auch für andere Announcement Protokolle verwendbar, es ist also nicht nur auf SAP und SDP beschränkt. Wir haben es allerdings nur mit SAP und SDP getestet.
In unserer Testumgebung, in der wir ein kleines Teilnetz mit dem INTERNET koppelten, haben wir auch diese Verfahren mit eingebaut und verwendet. Exakte Messungen des Gesamtgewinns, liegen derzeit noch nicht vor.
Der Quellcode für die Implementierungen ist in Anhang [srcTestImpl] enthalten.