Der Zerberus Netcall

Vielleicht haben Sie irgendwann einmal das Bedürfnis gehabt zu wissen wie Zerberus-Systeme ihre Daten untereinander austauschen.

Hier ist sie nun, die entgültige Anleitung zum Netcall. Ich hoffe, daß sich keine Fehler eingeschlichen haben und alle wichtigen Punkte abgehandelt wurden.

Da die Zerberus-Programmierer keine Antwort auf meine Abfrage zur Korrektheit der Dokumentation gegeben habe, nehme ich mal an, daß sie so in Ordnung ist. Wenn Sie ALLE Hinweise in dieser Dokumentation beachten, sollte es nicht sonderlich schwierig sein, ein Zerberus-kompatibles Netcallteil zu schreiben.

Viel Spaß dabei
Patrick Schaaf (BRIAN_O'FISH@MULI.ZER)
MIDGET (Muli Internal Development, Growing Entropy Telecommunications)

Zuerst wird die Verbindung zwischen den beiden Systemen auf irgendeine Art und Weise hergestellt (zum Beispiel über Modem).

Nach erfolgtem Connect läuft aus Sicht des Anrufers folgendes ab:

• a) Die andere Seite sendet den Mailbox-Begrüßungsbildschirm Dieser kann durch wiederholtes Senden von Ctrl-X abgebrochen werden.

• b) Die Mailbox sendet als Prompt den String "Username:". Nun sollte der Anrufer den String "ZERBERUS", gefolgt von CR/LF, senden.

• c) Wenn b) funktioniert hat und die Mailbox das "ZERBERUS" verstanden hat, sendet sie den String "Systemname:", andern- falls vermutet sie wahrscheinlich einen normalen Usernamen, sie sollten in dem Fall einige CR/LF - Paare senden, damit die Verbindung sich wieder synchronisiert, und bei b) weiter- machen.

  Wenn "Systemname:" empfangen wurde, sollte der Anrufer seinen System- (oder Terminal-/Point-) Namen senden, in Großschrift und wiederum mit CR/LF beendet.

• d) War dies nicht erfolgreich, geht's wieder zu b), ansonsten sendet die Mailbox "Passwort:". Nun wird das vereinbarte Netzpaßwort gesendet, ebenfalls in Großschrift und durch CR/LF beendet.

• e) Wenn die Paßworteingabe fehlgeschlagen ist, wird entweder wieder bei b) weitergemacht, oder die andere Seite sendet bei zuvielen Fehlversuchen den String "Netzzugriff verweigert" und legt auf.

  Wurde das Paßwort korrekt erkannt, sendet die Mailbox erst einmal mehrere Zeilen, die den String "running ARC" enthalten. Sie ist nun die Daten für Sie am vorbereiten, was einige Zeit in Anspruch nehmen kann (Sie sollten an dieser Stelle ruhig sichergehen und mit einem Timeout von 10 Minuten arbeiten).

• f) Ist der Partner fertig mit Arcen, so sendet er ein einzelnes NAK-Zeichen (Ascii Hex 15, Dezimal 21) und erwartet nun Ihre Seriennummer. Diese Seriennummer besteht im Prinzip aus fünf Zeichen, wobei das fünfte die Summe der ersten vier ist (modulo 256), also (in C): char s[5]; s[4]=(char)(((int)s[0]+(int)s[1]+(int)s[2]+(int)s[3])&0xFF); Was Sie als Seriennummer nehmen, ist im Prinzip egal, Sie können zum Bleistift der Einfachkeit halber fünf mal ein Nullbyte senden.
  Wenn die Seriennummer korrekt erkannt wurde, sendet die Gegenseite ein ACK (Ascii 6), wenn nicht, wieder ein NAK. Sollte die Seriennummer mehrmals nicht erkannt werden, legt die Gegenseite auf.

• g) Ist der Seriennummerncheck erfolgreich gelaufen (ACK empfangen), beginnt umgehend der eigentliche Netztransfer:
  • Beim Netztransfer wird immer in je einer Richtung ein File gesendet.

  • Bei Unidirektionalem Transfer (Xmodem, Zmodem) sendet zuerst der Anrufer, dann der Angerufene.

  • Bei Bidirektionalem Transfer (Bimodem) werden beide Dateien gleichzeitig versandt.

  • Der Anrufer sendet eine Datei namens CALLER, der Angerufene eine Namens CALLED. Es muß damit gerechnet werden, daß moeglicherweise der Dateiname der zu empfangenden Datei ein anderer als der erwartete ist.

  • Die Datei ist ein Archiv, gepackt mit ARC (bei manchen Systemen ist eventuell auch ZIP, ZOO oder LHARC als Archivformat möglich). Die oben angesprochenen Dateien CALLER und CALLED sollten als Extension die jeweilige Arcer-Extension tragen.

  • Im Archiv befindet sich eine Datei namens PUFFER und sonst nix. Diese Datei ist das eigentliche Netcallfile (Format s.u.).

  • Wenn ein Partner nichts zu versenden hat, sollte er entweder eine Datei senden, die nur aus einem CR/LF-Paar besteht, oder aber ein Archiv, das ein PUFFER-File mit CR/LF enthält, beide Formen sollten erwartet werden.

• h) Direkt nach dem Versand der beiden Files wird die Verbindung getrennt.

Das PUFFER-File enthält nacheinander ohne Lücke alle Nachrichten, die versandt werden sollen.

Eine Nachricht besteht dabei aus Kopf und Message.
Der Kopf enthält 8 Zeilen, die jeweils durch CR/LF beendet werden.
Ein Kopf sieht folgendermaßen aus:

----------- Start o'Kopf ------------
[Empfänger]
[Betreff]
[Absender]
[Datum]
[Pfad]
[MsgId)
[Typ]
[Länge]
----------- End o'Kopf --------------

Die einzelnen Felder haben folgende Bedeutung:

• [Empfänger] :
  Eine Zeichenkette ohne Leerzeichen und in Grosßchrift. Maximallänge: 40 Zeichen (hmm, unsicher, vielleicht mehr) Es gibt drei mögliche Erscheinungsformen:
  • [Username] Empfänger ist ein User, der in der Mailbox eingetragen ist, die das Netcallfile erhalten wird. Username darf keinen Klammeraffen (@) enthalten. Beispiel: BRIAN_O'FISH
  • [Brettname] Empfänger ist ein Brett in der Box, die das Netcallfile erhalten wird. Damit die Nachricht ankommen kann, muß das Brett dort natürlich vorhanden sein. Beispiel: /T-NETZ/BESCHEUERT
  • [Username]@[Systemname].ZER Empfänger ist der User [Username] im Netzsystem [Systemname] Beispiel: WOLFGANG@SOLARIS.ZER

  Es ist wichtig, daß für Nachrichten an User im Serversystem der Systemname NICHT im Empfängerteil auftaucht, also die erste Erscheinungsform genommen wird !

• [Betreff]:
  Der Nachrichtentitel. Eine beliebige Zeichenkette mit einer Maximallänge von 40 Zeichen (wieder geschätzt...)

• [Absender]:
  Der Absender der Nachricht. Eine Zeichenkette ohne Leerzeichen und in Grosßchrift. Maximallänge sind wiederum 40 Zeichen. Der Absender sollte immer die Form [eigener_username]@[eigener_systemname].ZER haben.
  Bei einem Terminal (Point) sollte der Pointname für den eigenen Systemnamen eingesetzt werden, das Serversystem wird das Feld entsprechend anpassen.

• [Datum]:
  Das Erstellungsdatum der Nachricht. Eine Zeichenkette nur aus Ziffern mit exakt 10 Zeichen Länge ohne Leerzeichen dazwischen.

  Format:
  jjmmtthhmm
  jj = Jahr (00-99, gezählt seit 1900;ich weiß, 2000 ist nicht :-)
  mm = Monat (01-12)
  tt = Tag im Monat (01-31)
  hh = Stunde (00-23)
  mm = Minute (00-59)
  Es ist SEHR wichtig, daß das Format dieses Feldes stimmt, insbesondere die Länge, da es sonst zu großen Problemen auf dem Netz kommen kann.

• [Pfad]:
  Der Nachrichtenpfad, den die Nachricht bereits gelaufen ist.
  Eine Zeichenkette ohne Leerzeichen, Maximallänge 80 Zeichen, wenn es mehr werden, sollte abgeschnitten werden !

  Format:

  [System1]![System2]![...]![unser_System]

  Die Systemnamen sind jeweils OHNE die Endung .ZER zu schreiben. Das eigene System wird immer am Ende angehängt (umgekehrt wie bei UUCP!). Usernamen sollten im Pfad nicht auftauchen!
  Wird eine Nachricht neu generiert, sollte der Pfad leergelassen werden (Leerzeile, keine Blanks!), der Server wird sich dann als erstes System eintragen.

• [MsgId]:
  Dies ist eine eindeutige Kennung der Nachricht. Der Theorie nach sollte sie NETZWEIT NIEMALS doppelt vorkommen. Eine Zeichenkette ohne Leerzeichen mit maximal 20 Zeichen (sehr wichtig!).

  Das "Standard"-Format ist folgendes:
  [xx].[yyyyy]@[unser_System]
  wobei xx eine zweistellige Zufallszahl und yyyyy ein bei jeder Nachricht erhöhter Zähler ist.

  Beispiel:
  08.15@MIDGET

• [Typ]:
  Der Nachrichtentyp, gibt die Weiterverarbeitung der Nachricht an.
  Ein einzelnes Zeichen, und zwar:
  T für Textnachrichten
  B für Binärnachrichten
  Alle anderen Zeichen führen bei Zerberus- und Kompatiblen Systemen zu erheblichen Problemen, also bitte keine eigenen Formate definieren, sonst können Sie ihr Netcallfile gleich löschen (Einlesen wird an der Stelle mit Fehler abgebrochen).

  Das Format von Binärdateien ist frei, bei Textdateien sollten Sie darauf achten (mit Ihrer Software bei der Erstellung der Message sicherstellen), daß Zeilen mit CR/LF beendet werden und möglichst IBM-Umlaute verwenden (wenn überhaupt).

• [Länge]
  Die Länge der Message (der eigentlichen Nachricht) in Bytes.
  Wichtig bei empfangenen Netcallfiles: Vor der Zahl kann ein Leerzeichen stehen !

  Nach den Vorgaben von Zerberus sollte UNBEDINGT beachtet werden, daß persönliche Netzmails, also Mails mit dem Empfängerformat [Username]@[Systemname].ZER, nicht länger als 4000 Zeichen werden. Andernfalls kann ihnen dreierlei passieren:

  • - Die Nachricht verschwindet im Nirwana
  • - Die Nachricht wird weitergeroutet. In diesem Fall machen Sie sich SEHR unbeliebt bei vielen Leuten
  • - Die Nachricht wird korrekt als Eilmail versand (ich weiß nicht, ob das in irgendeiner Implementation bereits korrekt gehandhabt wird).

  Am Wahrscheinlichsten ist dabei das erste Verhalten (Nirwana), aber ziehen Sie daraus nicht den Schluß, daß sie das nicht beachten sollten !

  Bei Brettnachrichten sollte auch die Längenbeschränkung beachtet werden, hier ist sie aber Sache des Serversysops, so daß wenn überhaupt diese Einstellung parametrisiert werden sollte.

----------- Start o'Kopf ------------
/T-NETZ/BESCHEUERT
Info: Das Zerberus-Netcallformat
BRIAN_O'FISH@MIDGET.ZER
9009071123

08.15@MIDGET
T
4223
----------- End o'Kopf --------------

Nach dem Kopf kommt dann im Netcallfile direkt die Message (beginnend mit dem ersten Byte nach dem CR/LF der [Länge]-Zeile. Die Message ist genau [Länge] bytes groß, danach folgt sofort im nächsten Byte der nächste Kopf.

Austesten von neuer Software:

Zur Aufrechterhaltung des Netzbetriebes sollte bei neugeschriebener Netzsoftware unbedingt folgendes beachtet werden:

• - Testen Sie die Software ausführlich mit ihrem Server, senden Sie in dieser Testphase KEINE Nachrichten an Netzbretter oder Netzuser. Halten Sie sich daran auch, wenn Sie von sich als gutem Programmierer überzeugt sind - Fehler passieren immer mal und können fatal sein. Dieser lokale Test sollte mindestens einen Monat laufen.

• - Arbeiten Sie mit ihrer Software und einem ÜBERSCHAUBAREN Kreis von Beta-Testern. Eine zu schnelle Verbreitung von fehlerhafter Netzsoftware könnte zu erheblichen Rückrufproblemen führen.

• - Wenn Sie eine Mailboxsoftware schreiben, die als Netzsystem (und nicht als Point/Terminal) an's Netz gehen soll, müssen sie die Software vor dem Netzanschluß von der technischen Netzkoordination (SYSOP@INFINET) testen lassen.

  Bei Pointsoftware ist dieser Test derzeit nicht obligatorisch, aber trotzdem sehr zu empfehlen.
  Genauere Informationen bitte bei Sysop@Infinet anfordern.