Empfänger : /Z-NETZ/TELECOM/NETZWERKE Absender : BRIAN_O'FISH@MULI.ZER Betreff : Hitchikers Guide to Zerberus Netcalls Routweg : MIDGET!MULI!HHN!GCS!INFINET!TTB!LINK-K Datum/Zeit: 19.07.90 09:10 Länge : 13043 Bytes Per Anhalter durch das Zerberus-Netz oder Wie verdammt nochmal machen die das eigentlich ? Sehr geehrte Programmierer: Vielleicht haben Sie irgendwann einmal das Beduerfnis gehabt zu wissen wie Zerberus-Systeme ihre Daten untereinander austauschen. Hier ist sie nun, die entgueltige Anleitung zum Netcall. Ich hoffe, dass 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, dass 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 Spass dabei Patrick Schaaf (BRIAN_O'FISH@MULI.ZER) MIDGET (Muli Internal Development, Growing Entropy Telecommunications) Der Zerberus-Netcall: ------------------------------------------ Zuerst wird die Verbindung zwischen den beiden Systemen auf irgendeine Art und Weise hergestellt (zum Beispiel ueber Modem). Nach erfolgtem Connect laeuft aus Sicht des Anrufers folgendes ab: a) Die andere Seite sendet den Mailbox-Begruessungsbildschirm 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 Grossschrift 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 Netzpasswort gesendet, ebenfalls in Grossschrift und durch CR/LF beendet. e) Wenn die Passworteingabe 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 Passwort korrekt erkannt, sendet die Mailbox erst einmal mehrere Zeilen, die den String "running ARC" enthalten. Sie ist nun die Daten fuer 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 fuenf Zeichen, wobei das fuenfte 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 koennen zum Bleistift der Einfachkeit halber fuenf 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 muss damit gerechnet werden, dass 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 moeglich). 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 enthaelt, beide Formen sollten erwartet werden. h) Direkt nach dem Versand der beiden Files wird die Verbindung getrennt. Format des Netcallfiles (PUFFER) ------------------------------------------ Das PUFFER-File enthaelt nacheinander ohne Luecke alle Nachrichten, die versandt werden sollen. Eine Nachricht besteht dabei aus Kopf und Message. Der Kopf enthaelt 8 Zeilen, die jeweils durch CR/LF beendet werden. Ein Kopf sieht folgendermassen aus: ----------- Start o'Kopf ------------ ----------- End o'Kopf -------------- Die einzelnen Felder haben folgende Bedeutung: : Eine Zeichenkette ohne Leerzeichen und in Grossschrift. Maximallaenge: 40 Zeichen (hmm, unsicher, vielleicht mehr) Es gibt drei moegliche Erscheinungsformen: Empfaenger ist ein User, der in der Mailbox eingetragen ist, die das Netcallfile erhalten wird. Username darf keinen Klammeraffen (@) enthalten. Beispiel: BRIAN_O'FISH Empfaenger ist ein Brett in der Box, die das Netcallfile erhalten wird. Damit die Nachricht ankommen kann, muss das Brett dort natuerlich vorhanden sein. Beispiel: /T-NETZ/BESCHEUERT @.ZER Empfaenger ist der User im Netzsystem Beispiel: WOLFGANG@SOLARIS.ZER Es ist wichtig, dass fuer Nachrichten an User im Serversystem der Systemname NICHT im Empfaengerteil auftaucht, also die erste Erscheinungsform genommen wird ! Der Nachrichtentitel. Eine beliebige Zeichenkette mit einer Maximallaenge von 40 Zeichen (wieder geschaetzt...) Der Absender der Nachricht. Eine Zeichenkette ohne Leerzeichen und in Grossschrift. Maximallaenge sind wiederum 40 Zeichen. Der Absender sollte immer die Form @.ZER haben. Bei einem Terminal (Point) sollte der Pointname fuer den eigenen Systemnamen eingesetzt werden, das Serversystem wird das Feld entsprechend anpassen. Das Erstellungsdatum der Nachricht. Eine Zeichenkette nur aus Ziffern mit exakt 10 Zeichen Laenge ohne Leerzeichen dazwischen. Format: jjmmtthhmm jj = Jahr (00-99, gezaehlt seit 1900, ich weiss, 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, dass das Format dieses Feldes stimmt, insbesondere die Laenge, da es sonst zu grossen Problemen auf dem Netz kommen kann. Der Nachrichtenpfad, den die Nachricht bereits gelaufen ist. Eine Zeichenkette ohne Leerzeichen, Maximallaenge 80 Zeichen, wenn es mehr werden, sollte abgeschnitten werden ! Format: !![...]! Die Systemnamen sind jeweils OHNE die Endung .ZER zu schreiben. Das eigene System wird immer am Ende angehaengt (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. 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: .@ wobei xx eine zweistellige Zufallszahl und yyyyy ein bei jeder Nachricht erhoehter Zaehler ist. Beispiel: 08.15@MIDGET Der Nachrichtentyp, gibt die Weiterverarbeitung der Nachricht an. Ein einzelnes Zeichen, und zwar: T fuer Textnachrichten B fuer Binaernachrichten Alle anderen Zeichen fuehren bei Zerberus- und Kompatiblen Systemen zu erheblichen Problemen, also bitte keine eigenen Formate definieren, sonst koennen Sie ihr Netcallfile gleich loeschen (Einlesen wird an der Stelle mit Fehler abgebrochen). Das Format von Binaerdateien ist frei, bei Textdateien sollten Sie darauf achten (mit Ihrer Software bei der Erstellung der Message sicherstellen), dass Zeilen mit CR/LF beendet werden und moeglichst IBM-Umlaute verwenden (wenn ueberhaupt). Die Laenge 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, dass persoenliche Netzmails, also Mails mit dem Empfaengerformat @.ZER, nicht laenger 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 weiss nicht, ob das in irgendeiner Implementation bereits korrekt gehandhabt wird). Am Wahrscheinlichsten ist dabei das erste Verhalten (Nirwana), aber ziehen Sie daraus nicht den Schluss, dass sie das nicht beachten sollten ! Bei Brettnachrichten sollte auch die Laengenbeschraenkung beachtet werden, hier ist sie aber Sache des Serversysops, so dass wenn ueberhaupt diese Einstellung parametrisiert werden sollte. Beispiel eines Kopfes: ----------- 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 -Zeile. Die Message ist genau bytes gross, danach folgt sofort im naechsten Byte der naechste Kopf. Austesten von neuer Software: Zur Aufrechterhaltung des Netzbetriebes sollte bei neugeschriebener Netzsoftware unbedingt folgendes beachtet werden: - Testen Sie die Software ausfuehrlich 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 ueberzeugt sind - Fehler passieren immer mal und koennen fatal sein. Dieser lokale Test sollte mindestens einen Monat laufen. - Arbeiten Sie mit ihrer Software und einem UEBERSCHAUBAREN Kreis von Beta-Testern. Eine zu schnelle Verbreitung von fehlerhafter Netzsoftware koennte zu erheblichen Rueckrufproblemen fuehren. - Wenn Sie eine Mailboxsoftware schreiben, die als Netzsystem (und nicht als Point/Terminal) an's Netz gehen soll, muessen sie die Software vor dem Netzanschluss 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. Nachwort: Keines. Ich wollte die Mail nur nicht aprupt enden lassen. Viel Spass beim Programmieren. | GEP - Growing Entropy Pointwhere \ "I feel fine today, modulo a slight headache." The Hacker's Dictionary << ZAPF >> Private Eye - der Punkt aus dem Kölner Norden