Mögliche weitere Entwicklungen

  In diesem Abschnitt sollen noch einige mögliche weitere Entwicklungen vorgestellt werden.

Reliable Multicast

Falls in Zukunft ein funktionierendes zuverlässiges Multicastprotokoll entwickelt wird, sollte Mcntp umgeschrieben werden, damit dieses genutzt werden kann. Im Prinzip beschränkt sich das Umschreiben dabei auf die Funktionen der Bibliothek libmc , die mit der Multicastkommunikation zu tun haben. Durch Verwendung von Reliable Multicast kann dann auch das Nachsenden via NNTP  entfallen.

Verbesserung der Gruppenauswahl

Programme, wie   (Session Directory) dienen im MBone  dazu, Übertragungen von Ereignissen anzukündigen und die entsprechenden Multicastkanäle zu belegen.   könnte diese Ankündigungen in seiner eigenen Gruppenauswahl berücksichtigen, um Kollisionen mit bereits belegten Gruppen zu vermeiden. Dies kann jedoch nicht komplett gegen Überschneidungen schützen, sondern die Wahrscheinlichkeit dazu nur verringern. Im Gegenzug sollte   die für den Newstransport gewählten Gruppen dann auch über das Protokoll von SDR verteilen.

Backup Funktionalität

Das normale Verhalten von   ist es, Gruppen, die schon belegt sind, zu meiden. D.h. für jede neue Newsgruppe wird auch eine neue Multicastgruppe aus dem angegebenen Bereich genommen. Teilweise könnte auch ein anderes Verhalten richtig sein, um z.B. auf diese Weise den in 5.3 beschriebenen MBone  Betrieb zu realisieren. Dazu müßte eine weitere Konfigurationsoption für   in .conf  hinzugefügt werden:

use

Falls für die angegebene Newsgruppe bereits eine Multicastgruppe existiert, soll diese benutzt werden (siehe 5.3). Wird diese Newsgruppe noch nicht verteilt, wird eine neue Multicastadresse dafür verwendet.

new

Für jede Anfrage eine eigene, neue Multicastgruppe verwenden. Dies ist das aktuelle Verhalten von  .

stop

Wenn eine Anfrage kommt,   mitteilen, daß in dieser (News-)Gruppe nicht gesendet werden darf. Dazu muß   ebenfalls modifiziert werden.

standby

Wird die angegebene Gruppe bereits verteilt, wird   mitgeteilt, daß nicht gesendet werden soll.   beobachtet weiter die Ankündigungen. Wird die angegebene Gruppe nicht mehr verteilt, gibt   ein Zeichen an  , daß nun gesendet werden soll. Dazu muß   ebenfalls modifiziert werden. Dieser Betriebsmodus könnte genutzt werden, um auf diese Weise ein automatisches Backup zu realisieren.

Ein Beispiel für eine modifizierte Konfigurationsdatei .conf  könnte wie folgt aussehen:

   ME:8:blackbush
   # de.* in vorhandenen Gruppen verteilen
   de.*:228.1.1.1:250:16:use
   # comp.* nur dann verteilen, wenn es niemand anders tut
   comp.*:228.1.1.1:250:16:standby
   # fuer die ka.* Gruppen immer eine neue MC-Gruppe nehmen
   ka.*:239.1.1.0:16:4:new
   # Alle anderen Gruppen nicht versenden
   *:228.1.1.1:250:16:stop

Cancel Nachrichten verteilen

Im Usenet  wird versucht, möglichst viele der Massenwerbepostings zu löschen. Dies geschieht mittels der Cancel Kontrollnachricht  (siehe auch Abschnitt 2.3). Wenn die Cancel Kontrollnachricht  auf einem System eintrifft, nachdem der Artikel bereits eingetroffen ist, wird er Artikel aus dem lokalen SpoolSpool entfernt. Trifft die Cancel Nachricht jedoch schon vorher ein, wird der Artikel, der gelöscht werden soll, nicht erst vom Zielsystem akzeptiert. Es ist also gut, wenn die Cancel Nachrichten schneller verteilt werden, als die zugehörigen Artikel. Im Protokollkopf (siehe Abbildung 31 in Abschnitt 4.4.1 auf Seite ) sind acht Bit bisher nicht genutzt und als ``Reserviert'' gekennzeichnet. Ein Bit könnte als ``Cancel'' Bit definiert werden. Ist dieses Bit gesetzt, ändert sich das Paketformat wie folgt:

[IMAGE ]

 Abbildung 37: Paketformat für Cancel Nachrichten

Der Unterschied zum normalen Artikelformat, wie in Abbildung 31 definiert, liegt darin, daß die Message-ID fehlt. Dafür enthält der Datenteil eine Reihe von Message-IDs , die durch Leerzeichen getrennt sind und die, wie in Abschnitt 4.4.2 beschrieben, digital signiert sind.

Ein solches Paket kann eine oder mehrere Message-IDs  enthalten, um damit das Löschen von einem oder mehreren Artikeln veranlassen. Die Sender-ID  sollte von der normalen Sender-ID  des Hosts abweichen und in der Form ``Sender-ID-cancel'' sein. Also z.B. ``blackbush-cancel'' oder ``news.xlink.net-cancel''. Dies ist ist nötig, um das Akzeptieren von Cancel Nachrichten besser zu regulieren.

Daten gleichmässiger versenden

Mcntp versendet die Daten so schnell es geht. Dies kann unter Umständen sehr unregelmäßig sein wenn z.B. zwei große Artikel nacheinander kommen, dann ein paar Sekunden Pause sind, und dann ein kleiner Artikel kommt.   müßte in der Lage sein, herauszufinden, wie groß die durchschnittliche Datenrate ist, um dann nach Artikeln, die diese Rate überschreiten, eine kleine Pause einzulegen, um die Rate zu ``glätten''.