Fido-Programme

[Editor] [Tosser] [Mailer] [Nodelist-Compiler] [Ticker]

 

Um am FidoNet teilnehmen zu können, benötigt man diverse Programme. Die wichtigsten sind Editor, Tosser und Mailer.

 

Editor

Mit dem Editor kann man neue Mails verfassen und die Mails von anderen lesen. Im Grunde ist sein Funktionsprinzip überall identisch: Die Mails in einem Echo werden in einer übersichtlichen Liste angeordnet, aus der man eine auswählen kann, um sie zu lesen und evtl. zu beantworten.

Je nach verwendetem Programm beinhaltet der Editor mehr oder weniger Funktionen, mit denen das Fido-Leben etwas einfacher wird.

Bei der Anzeige einer Mail zeigen beispielsweise viele Programme den Quote in einer anderen Farbe oder Schriftart an, um ihn vom Rest des Textes abzutrennen. Auch gibt es häufig Unterschiede in der Art, wie der Header einer Mail dargestellt wird.

Bei den Zusatzfunktionen (die über das Tippen allein hinausgehen) gibt es auch viele Unterschiede. So beherrschen manche Editoren Makros, um Abläufe zu automatisieren oder sie bieten Funktionen, um sich komfortabel anhand der Bezugsverkettung durch einen Thread zu bewegen.

Der verwendete Editor ist oft eine Charakterfrage :) Viele bevorzugen Programme, die Millionen Funktionen bieten, die über Milliarden komplizierter Tastenkombinationen aufgerufen werden können, und andere gehen lieber den "einfachen" Weg und verzichten dafür auf einige "Profi"-Features.

Hat man bei sich eine modulare Lösung im Einsatz (d.h. kein integriertes Pointpaket), ist man relativ frei in der Wahl seines Lieblingseditors. Man muss nur darauf achten, dass der Editor das bei sich verwendete Format der Message Base unterstützt (s.u.).

Der bekannteste und wohl am meisten genutzte Editor ist GoldED in seinen zahlreichen Varianten.

 

Tosser

Der Tosser ist ein weiteres sehr wichtiges Element. Er ist für die Verbindung der eigenen Messagebase (Dateien, in denen die Nachrichten abgelegt werden) mit der "Welt" verantwortlich. Der Tosser entpackt hereinkommende Mailpakete und sortiert die enthaltenen Mails in die korrekten Dateien ein, wobei er (je nach Messagebase-Format) deren Format leicht verändert. Ausserdem ist er dafür verantwortlich, dass die vom Editor produzierten Nachrichten in ein korrektes FidoNet-kompatibles Format gebracht, gepackt und damit für den Versand vorbereitet werden.

Aber der Tosser macht noch mehr. Auf einem Nodesystem packt er die Pakete für alle Points und Nodes und schiebt sie in die korrekten Verzeichnisse für den Versand durch den Mailer. Ausserdem verarbeitet der Tosser die gesamten Areafix-Requests der angeschlossenen Systeme (z.B. Echobestellungen oder Rescans).

Der Tosser hat am meisten mit der sog. Messagebase zu tun. Sie ist quasi das "Ablagebrett" für die ganzen Mails, die der Tosser durch die Gegend sortiert. Es gibt zahlreiche gebräuchliche Messagebase-Formate wie z.B. JAM und Squish. Bei beiden Formaten wird jedes Echo in einer eigenen Datei (und/oder in einem eigenen Verzeichnis) abgelegt. Besser gesagt gibt es mehrere Dateien pro Echo:

Bei Squish sind es jeweils zwei (Die Nachrichten selbst und der Index für dieses Echo, der den Zugriff beschleunigt) und bei JAM ganze vier (Ein File mit den Message-Bodys [Nachrichtentext], eines mit den Headern, ein Indexfile und ein File für sonstige Informationen). Bei der Hudson-Base liegen alle Daten für alle Echos in nur 5 Dateien (Mailtext, Mailheader, Index, etc.), die deshalb sehr gross werden können (besonders die Header- und Mailtext-Files). Auch kann eine Hudson-Base nur höchstens 16000 Mails verwalten (zum Vergleich: Bei einer JAM-Base gibt es keine Limits, ausser bei den maximalen Nachrichten je Echo; und diese Zahl liegt bei 2 Milliarden). Das älteste Format ist das MSG-Format, bei dem für jede einzelne Nachricht eine eigene Datei angelegt wird (verbraucht einen
Haufen Speicherplatz und ist sehr langsam).

Hudson und MSG sind kaum mehr gebräuchlich (kein Wunder eigentlich). Die meisten Systeme benutzen daher Squish oder JAM, weil diese Formate sehr wartungsfreundlich, dynamisch erweiterbar und auch recht schnell sind.

Wenn ein Tosser mehrere Messagebase-Formate unterstützt, ist es jedoch auch kein Problem, mehrere Formate einzusetzen. So kann ein Sysop für einige wenige Echos das Hudson- oder sogar MSG-Format verwenden, wogegen er alle anderen in JAM oder Squish ablegt. Warum Hudson verwenden? Es ist trotz seiner Limitationen das schnellste Format und dies kann ein Grund für viele Sysops sein, einige Areas im Hudson-Format abzulegen. Wenn bei Hudson allerdings eine Datei, womöglich noch die mit den Mailtexten, über den Jordan hopst (Plattencrash etc.), ist alles verloren. Hier bringt eine Aufteilung auf viele Dateien (wie bei Jam oder Squish) eindeutige Vorteile.

Der gebräuchlichste Vertreter für die Squish-Messagebase ist natürlich Squish selbst, ein freier und für die meisten OS verfügbarer Tosser.

Das (kostenpflichtige) Fastecho ist komfortabel zu bedienen (ASCII-GUI), unterstützt MSG, Hudson, JAM und Squish-Messagebases, ist jedoch nur für DOS und OS/2 zu haben.

Es gibt noch dutzende anderer Tosser, z.B. hpt für Linux, um nur einen aus vielen zu nennen.

Die integrierten Pointpakete wie WinPoint oder CrossPoint benutzen ihr eigenes Messagebase-Format. So legt XP alle Nachrichten wild verteilt in zehn sog. "Puffern" ab, die durch Indexdateien indiziert werden. Dieses Format wird zwar von vielen belächelt (weil langsam, chaotisch und schlecht zu warten), doch es erfüllt seinen Zweck und ist auf die Entstehungsgeschichte von XP zurückzuführen (das in seinen Anfängen gar nicht auf FidoNet ausgelegt war). Auf diese speziellen Formate kann normalerweise nur ein Programm, das Pointprogramm selbst, zugreifen. Es sei denn natürlich, es schreibt irgendwer einen Tosser, der dasselbe Format unterstützt :-)

 

Mailer

Der Mailer ist der Botschafter, der Kontaktbeauftragte innerhalb eines funktionierenden FidoNet-Systems. Er ruft die Aussenwelt an oder beantwortet deren Anrufe. Dabei schickt er dem anderen System jeweils die für es bestimmten Dateien und nimmt neü Mailpakete entgegen (die er im sog. Inbound speichert, wo sie der Tosser findet, um sie auszuwerten).

Der Mailer kann durch sog. Events so konfiguriert werden, dass er selbsttätig zu bestimmten Zeiten andere Systeme anruft und mit diesen Mail austauscht. Ansonsten wartet er brav auf evtl. hereinkommende Anrufe.

Aber auch der Mailer kann noch mehr als das. So ist er für die Auswertung von File Requests zuständig. Diese Funktion können viele Mailer aber auch an externe Request-Prozessoren "übertragen".

Der sog. "Outbound" ist das Verzeichnis oder die Verzeichnisse, in dem/denen der Mailer die Mailpakete findet, die er verschicken soll. Dort hineinbefördert werden sie vom Tosser. Da dieser Outbound je nach Mailer wieder unterschiedliche Formate haben kann, muss der Tosser natürlich auch den eingesetzten Mailer unterstützen.

Die Funktion des gebräuchlichsten Mailers möchte ich hier im Groben kurz vorstellen: Binkley. Er ist kostenlos, relativ einfach über ASCII-Dateien zu konfigurieren und verfügt über einen grossen Funktionsumfang. Weiterhin ist er für alle gängigen Betriebssysteme erhältlich und wird ständig weiterentwickelt. So gibt es inzwischen dutzende Versionen, die jedoch alle mehr oder weniger kompatibel zueinander sind.

Da Binkley, kurz "Bink", als Mailer so weit verbreitet ist, unterstützen auch viele andere Mailer und eigentlich alle Tosser den sog. Binkley-Style-Outbound.

Dieser soll im folgenden (als Beispiel) beschrieben werden. Obwohl andere Mailer den Mailaustausch völlig anders handhaben können, bekommt man dadurch vielleicht einen kleinen Einblick in die Technik, die hinter so einem Node- (oder Point-)System steckt.

Das Binkley-Outbound-Format sieht ein eigenes Verzeichnis für jede Zone vor. Wird Bink nur in einem Netz (z.B. dem FidoNet) eingesetzt, so heisst dieses Verzeichnis schlicht "OUTBOUND". Für andere Zonen wird dem Verzeichnisnamen noch eine dreistellige Hex-Nummer beigefügt, die die Zonennummer angibt.

Dieses Outbound-Verzeichnis wird von Bink ständig überwacht. In ihm sind  die sog. Flow-Files enthalten. Diese geben an, welche Files und Mailpakete für ein bestimmtes System bereit liegen und aufgrund des Dateinamens dieses Files wird auch bestimmt, wie diese Files behandelt werden sollen.

Beispiel: Im Outbound-Verzeichnis liegt die Datei

09ac032c.hlo

09AC ist 2476 dezimal und gibt das Netz an. 032C ist 812 und gibt die Nodenummer an. Mit der Zone 2 (für das deutsche FidoNet) ergibt dies also die Adresse 2:2476/812.

Für dieses System liegen nun Daten auf Hold, d.h. das andere System muss "uns" anrufen, um sie sich abzuholen. Dies erkennt man an der Dateiendung HLO (Hold). Hätte die Datei die Endung DLO (Direct), dann müssten "wir" das andere System anrufen, um unsere Daten dort abzuliefern. Und wäre die Endung CLO (Crash), dann erkennt dies der Mailer und baut automatisch eine Verbindung zum jeweiligen System auf (sobald er dieses File entdeckt).

Letztere Eigenschaft ist daher auch die gebräuchlichste Methode bei Binkley-style-Mailern, eventgesteuerte Anrufe durchzuführen. Zu einer bestimmten Uhrzeit (konfigurierbar) steigt der Mailer mit einem bestimmten Errorlevel aus, welcher in einer Batchdatei abgefragt wird. Dort wird dann z.B. eine (leere) CLO-Datei für ein bestimmtes System erstellt, welches von Binkley dann angerufen wird. Danach wird das File automatisch gelöscht.

Was enthalten nun diese Flowfiles?

In ihnen steht pro Zeile die Pfadangabe einer Datei, die an das im Dateinamen beschriebene System verschickt werden soll, z.B.:

#D:\FIDO\OUTBOUND\0AEFBF8E.SU0

Diese Datei (0aefbf8e.su0) ist ein vom Tosser erstelltes und gepacktes Mailpaket. Die Endung SU0 bedeutet "Sonntag, erstes Paket". Die Raute (#) vor dem Dateinamen gibt an, dass dieses File auf 0 Byte Länge gekürzt werden soll, nachdem es verschickt wurde. Das ist die übliche Methode, damit der Tosser erkennen kann, welche Pakete schon verschickt wurden. So wird, falls an diesem Tag noch weitere Mails für dieses System gepackt werden, das nächste mit der Endung SU1 versehen. Für andere Dateien, die verschickt werden, wird üblicherweise ein "^"-Zeichen vorangestellt. Dieses bedeutet, dass die bezeichnete Datei nach dem versenden gelöscht wird. Steht weder # noch ^ vor dem Namen, dann wird die angegebene Datei nach dem Versenden nicht verändert.

Für Mailpakete an Points gibt es im Outbound-Verzeichnis ein weiteres Unterverzeichnis. Zum Beispiel:

09AC034F.PNT

09AC ist wieder 2476 und 034F ist 847, d.h. in diesem Verzeichnis liegen die Mailpakete für alle Points des Systems 2:2476/847.

Innerhalb dieses PNT-Verzeichnis liegen nun wieder Flowfiles. Deren Dateiname besteht nun aber nur noch aus der in Hex kodierten Pointnummer und den oben beschriebenen Endungen. Beispiel:

0000000A.HLO

In diesem Flowfile sind alle Dateien vermerkt, die an Point "A" (dezimal 10, also 2:2476/847.10) versandt werden sollen, sobald dieser anruft. Hold (HLO) ist hierbei die übliche Form.

Dies alles, die gesamte Erstellung dieser Dateien und Verzeichnisse, übernimmt der Tosser. Der Mailer "findet" sie dort nur und verschickt sie.

Wie immer benutzen die integrierten Pointpakete (wie XP oder WP) ihre eigenen Mailer und wickeln die ganze Sache auf ihre eigene Weise ab. Obiges ist daher nur für Leute interessant, die sich ein Pointsystem aus "Komponenten" selbst zusammenstellen wollen. Für angehende Nodes ist die Kenntnis darüber natürlich unerlässlich.

Weitere gebräuchliche Mailer sind z.B. FrontDoor, Xenia und McMail.

 

Nodelist-Compiler

Jetzt geht es zu den "Hilfsprogrammen", die für ein reibungslos funktionierendes System zwar auch wichtig sind, jedoch nur eine "kleinere" Randrolle spielen. Ein wichtiges "Hilfsprogramm" ist der Nodelist-Compiler.

Die Nodeliste ist im Prinzip eine grosse Textdatei, die pro Zeile ein Nodesytem beschreibt. Da in dieser Datei alle Nodes weltweit gelistet sind, ist diese sehr gross.

Der Mailer muss jedoch ständig in diese Nodeliste schauen, um die Telefonnummern der anzurufenden Systeme ausfindig zu machen. Es wäre sehr langsam, müsste der Mailer dazu jedes Mal eine 1,5 MB grosse Textdatei Zeile für Zeile durchsuchen. Stattdessen benutzt er also ein "compiliertes" Dateiformat.

Für deren Erstellung ist der Nodelist-Compiler zuständig. Eine solche Indexdatei (die aus mehreren Dateien bestehen kann) kann vom Mailer sehr schnell durchsucht werden. Ausserdem kann sie mehrere Nodelisten unterschiedlicher Netze enthalten. Wie immer gibt es auch hier mehrere Formate, die im Laufe der Zeit von diversen Mailern oder Editoren (die auch auf die Nodeliste zugreifen können/müssen) eingeführt wurden. So gibt es spezielle Formate für McMail, GoldED, Xenia, FrontDoor etc. Auch gibt es Formate, die von mehreren Programmen "universell" benutzt werden, wie z.B. das V7 (Version 7) Format, das auch Binkley verwenden
kann.

Doch der Nodeliste-Compiler macht noch mehr als bloss die Nodeliste zu "compilieren".

Da die Nodeliste wöchentlich aktualisiert wird, wäre es umständlich, jedes Mal die komplette Liste an die ganzen FidoNet-Systeme zu übertragen. Stattdessen wir die Nodeliste durch sog. Nodediffs, die nur die Änderungen an der Liste enthalten, aktualisiert.

Aus alter Nodeliste und aktuellem Nodediff kann der Nodelist-Compiler dann die jeweils aktuelle Nodeliste erstellen.

Auch kann das Programm in die compilierten Nodelist-Files zusätzliche Informationen einfügen oder bestehende Informationen verändern, ohne dass die Nodeliste dazu angetastet werden müsste (z.B. Telefonnummern oder bestimmte Flags). Auch können Passwörter für bestimmte Systeme eingefügt werden, die dann beim Verbindungsaufbau vom Mailer ausgewertet werden.

Bekannte Nodelist-Compiler sind z.B. Fastlist oder FastV7.

Wie immer benutzen die meisten integrierten Pointpakete ihre ganz eigenen Formate.

 

Fileecho-Prozessor / Ticker

Dieses Programm macht im Grunde dasselbe mit File-Areas, was der Tosser mit (Message)-Areas macht.

Das bekanntest File-Echo, das auf allen Systemen aufliegen dürfte, ist NODEDIFF, d.h. das Echo, durch das alle Nodediffs geschickt werden.

Der Fileecho-Prozessor ist für verschiedene Dinge zuständig:

Je nach eingesetztem Programm hat ein Fileecho-Prozessor natürlich mehr oder weniger nützliche Zusatzfunktionen, auf die hier nicht näher eingegangen werden soll.

Kleinere Ticker sind auch für Point-Systeme verfügbar. Diese Programme helfen dem Point dabei, erhaltene Files automatisch in bestimmte Verzeichnisse einzusortieren und Filelisten zu erstellen.

Der bekannteste Fileecho-Prozessor ist wahrscheinlich Allfix. Doch gibt es (wie immer) noch viele andere.


[jh]

[Einführung] [Details] [Software] [Fido-over-IP] [Mitmachen!] [Erfahrungen] [Echos] [Dokumente] [FidoNews] [Links] [News] [WIF] [Interaktiv]

[Drei Frames] [Zwei Frames] [Keine Frames]