Angestrebte Protokolleigenschaften

Nachfolgend wird nun eine Liste der Eigenschaften aufgezählt, die das zu entwickelnde Transportprotokoll erfüllen sollte.

Plattformunabhängig:

Das Protokoll sollte nach Möglichkeit breit einsetzbar sein: Es soll nicht nur auf die Unix-Plattform beschränkt sein oder nur mit einem bestimmten Newstransportprogramm benutzbar sein.

8-Bit clean:

RFC  1036 [HA87] spezifiziert in Bezug auf RFC 822 [Cro82], daß die in Newsartikeln gültigen Zeichen nur die des 7-Bit ASCII Zeichensatzes sind. Diese Beschränkung wurde bis heute nicht aufgehoben, gilt aber im (nicht amerikanischen) Usenet als veraltet und überholt. Zwar steht mit MIME[FM96,NF97] eine Möglichkeit zur Verfügung nationale Sonderzeichen wie die deutschen Umlaute, so zu kodieren, daß RFC  822 befolgt wird. Dies wird von den Artikelschreibern meist nicht angewandt, da noch nicht genügend Newsuseragents zur Verfügung stehen, die MIME unterstützen. Hier in Deutschland ist der ISO-8859-1 Zeichensatz sehr populär und wird auch entsprechend oft verwendet. Damit gelangen aber Zeichen in Umlauf, die alle 8-Bits eines Bytes ausnutzen.

Das Transportprotokoll darf keine Verstümmelung dieser Zeichen zulassen, auch wenn es aktuell ein Verstoß gegen RFC  822 ist. Der Nachfolger von RFC1036, den Henry Spencer derzeit vorbereitet, hebt die Beschränkung auf 7 Bit auf, so daß das Vorgehen dann legal und auch heute schon praktisch ist. Nebenbei: bei vielen anderen Anwendungsprotokollen gibt es die Beschränkung auf 7 Bit nicht, so daß die Vorgehensweise auch hinsichtlich der möglichen Wiederverwendung des Protokolls oder von Modulen in anderen Projekten sinnvoll ist.

Sparsam bezüglich Bandbreite:

Das Volumen der Netnews ist relativ hoch. Bei einer durschnittlichen Größe der Artikel von ca. 4kByte (siehe auch 2.3.1) und ca. 350.000 Artikeln am Tag müssen mindestens 1500 MB am Tag transportiert werden (bei manchen Rechnern, die auch noch einige lokale Hierarchien transportieren, kann das Volumen deutlich höher sein); dies entspricht einer konstanten Datenrate von mehr als 142 kBit/Sekunde (zum Vergleich: Ein ISDN-B-Kanal hat eine Bandbreite von 64kBit/s). Um die Datenrate niedriger zu halten, empfiehlt es sich die Daten vor dem Transport zu komprimieren, um damit Leitungsbandbreite zu sparen. Dabei ist zu beachten, daß die benötigte Rechenzeit für das (De-)Komprimieren möglichst gering ist, da sonst zu viel Zeit hierfür verwendet wird und der Gesamtdurchsatz zu stark sinkt.

Ausfalltolerant:

Sowohl Netzausfälle, als auch Ausfälle der Serverrechner sind an der Tagesordnung. Das Usenet Usenet ist weitgehend gegen Ausfälle immun, da Artikel dann über Umwege zu den nächsten Servern gelangen. Wenn allerdings ein Endsystem oder die Strecke zum Endsystem ausfällt, müssen Vorkehrungen getroffen werden, daß die Artikel, die nicht am Ziel angekommen sind, nach Behebung der Fehlersituation nachträglich zugestellt werden. Es sind die folgenden Fälle zu unterscheiden:

• Leitungsausfall: Da der Router  vom nächsten Router keine Informationen mehr erhält, wird der Zweig hinter der Störungsstelle aus der Forwardingtabelle genommen. Die Datagramme , die zu dem Zeitpunkt verschickt werden, können nicht beim Empfänger ankommen.
• Ausfall Endsystem: Hier gilt im Prinzip dasselbe wie bei Leitungsausfall. Wenn jedoch in der ``Nähe'' des Endsystems ein zweiter Empfänger ist, kann dieser die Daten entgegennehmen und sie dem ausgefallenen Endsystem nach dessen Wiederinbetriebnahme zustellen.
• Ausfall Empfänger NTA : Wenn nur der Empfänger NTANTA ausfällt, können trotzdem weiterhin Datagramme  empfangen werden. Diese Datagramme  sollten der Effizienz wegen, zwischengespeichert und dem NTA  später übergeben werden.
• Paketverlust auf der Leitung: Wird kein ``Zuverlässiges Multicast Protokoll'' (siehe 2.2.1) gewählt, können durch Paketverluste auf der Leitung Datagramme  und auch Artikel verloren gehen.

In allen vier Fällen kann es also passieren, daß Datagramme  nicht beim Empfänger NTA  ankommen und deswegen Artikel verloren gehen.

Transportsicherheit:

Da Router im allgemeinen nicht mitprotokollieren, welche Pakete von wo nach wo geflossen sind, ist es relativ einfach, einen Artikel in das System zu bringen, ohne daß nachvollziehbar ist, von wem er stammt. Somit können, wenn keine Vorkehrungen getroffen werden, relativ einfach gefälschte Artikel oder Werbeartikel in dem Umlauf gebracht werden, ohne daß der Sender ermittelbar ist. Es sollten deshalb Maßnahmen entwickelt werden, dies zu verhindern.

Geschwindigkeit des Versands:

Neben der Bandbreitenersparnis ist die Geschwindigkeit, mit der die Artikel verteilt werden ein weiteres wichtiges Kriterium. Ein Vergleich aus dem Strassenverkehr zeigt dies deutlich: das Zwei-Liter Auto wird nicht akzeptiert, wenn man damit nur 30 km/h schnell fahren kann.

Es sollte also versucht werden, an die in Abschnitt 2.3.3 auf Seite ermittelten Artikellaufzeiten heranzukommen, damit die Software wirkungsvoll eingesetzt werden kann - andernfalls sind die Artikel bereits via NNTP auf dem Zielsystem angelangt und der Nutzen von Mcntp wird in das Gegenteil gekehrt.

Da die Benutzer sich daran gewöhnt haben, daß ihre Postings in sekundenschnelle über den Erdball verteilt werden, und sie schon wenige Minuten später eine Antwort auf ihre Fragen erhalten, ist es nicht praktikabel, die Verteilung zu verzögern. Diese bedeutet, daß die Verteilung via Mcntp genau so schnell sein sollte, wie über andere Transportmechanismen.

Benötigte Rechenzeit:

Datenkompression und -verschlüsselung benötigen Rechenzeit. Von dieser Zeit ist direkt die Rate abhängig, mit der Artikel versandt werden können. Bei 300.000 Artikel am Tag darf die Verarbeitung eines Artikels höchstens eine viertel Sekunde benötigen, um mit der Artikelanzahl mithalten zu können.