_________________________________________________________________________ BiPoint v3.47 Zerberus(tm)-Netcall mit Telix(tm) v3.12 _________________________________________________________________________ Aufruf: _______ CallD("BiPoint", Tel_Nr, Ext, Pass_Name, Protokoll); _________________________________ <:-) ___________________________________ Die 'Features' des Programm-Pakets: ----------------------------------- * Sie koennen alternativ X-, Y-, Z- und Bi-Modem(tm) zur Daten- Uebertragung waehrend des Netcalls verwenden. * Steuerung ueber eine einfache Konfigurationsdatei (BiPoint.CNF) im Telix-Upload-Directory, deren Inhalt =vor= der Anwahl Ihrer Server-Box ausgewertet wird. * automatische Pruefung der in der Konfigurationsdatei von Ihnen angegebenen Datei-Namen auf Gueltigkeit und Vorhandensein. * Die unter Telix(tm) eingestellten Werte fuer Baud und COM-Port werden selbstaendig an BiModem(tm) weitergegeben, so dass Sie waehrend des Netcalls unabhaengig von der BiModem-Konfiguration sind. * Von frueheren Netcalls eventuell uebriggebliebene Dateien 'CALLER.xxx' und 'CALLED.xxx' werden automatisch geloescht, um einen fehlerfreien Netcall zu gewaehrleisten. * Bevor ein PUFFER versandt wird, fragt das Programm nach, ob Sie die Datei versenden wollen, damit Sie nicht versehentlich frueher aus Ihrer Box empfangene PUFFER neu aufs Netz schicken. * Haben Sie keine Daten zu versenden (PUFFER nicht vorhanden), wird selbstaendig eine (leere) 'Dummy'-Datei angelegt. * Die von Ihnen zu versendende 'PUFFER'-Datei wird Ihren Angaben in der Konfigurationsdatei entsprechend selbstaendig komprimiert. * Die Verbindung zu Ihrer Zerberus(tm)-Box wird mit Ihrem Modem automatisch hergestellt. * Die Login-Prozedur der Box und der Datentransfer werden automatisch abgewickelt - mit dem Uebertragunsprotokoll Ihrer Wahl. * Das aufrufende Telix-Script erhaelt Ergebnis-Codes von 'BiPoint'. * Nach erfolgreich abgewickeltem Netcall wird - der empfangene Netcall-PUFFER automatisch extrahiert, - die eingegangene Datei 'CALLED.xxx' geloescht, - die Protokoll-Datei (capture) geloescht, - die eingegangenen Nachrichten nach Wunsch angezeigt. * Sie koennen die empfangenen Daten gleich bearbeiten, ohne Telix verlassen zu muessen. _________________________________ <:-) ___________________________________ im Paket enthaltene Dateien: ---------------------------- * BIPOINT.NEW: Geschichte der Erweiterungen/Veraenderungen des Programmes * BIREGIST.FRM: Bezugsmoeglichkeiten und 'Registrierung' * BICHECK.SLC: Script zum Einlesen und Pruefen der Konfigurations-Datei * BIPOINT.CNF: Datei mit Ihrer Konfiguration * BIPOINT.DOC: diese Datei <:-)) * BIPOINT.SLC: das eigentliche Netcall-Script * BIPREP.BAT: BATch-Programm zum Herstellen Ihres Netcall-PUFFERs * BIVIEW.SLC: Script zum Ansehen und Bearbeiten der eingegangenen Nachrichten * ZERBERUS.SLT: Script zum Einloggen in einer Zerberus-Mailbox * ZERBERUS.SLC: kompiliertes Mailbox-Script * BIMODEM.CFG: Beispiel-Konfiguration fuer BiModem _________________________________ <:-) ___________________________________ Hard- und Software-Voraussetzungen: ----------------------------------- * XT (-kompatibler) Rechner; * ein beliebiges (von Telix ansteuerbares) Modem; * Betriebssystem MS-DOS v3.xx; * Das Shareware-DFUe-Programm 'Telix'(tm), mindestens v3.12, lauffaehig installiert; * Wollen Sie die Moeglichkeit der Netcalls mit dem Bimodem-Protokoll nutzen, so benoetigen Sie das Shareware-DFUe-Programm 'BiModem'(tm), v1.2x, lauffaehig installiert; * Ein Account in einer Zerberus(tm)-Mailbox als 'normaler' User UND ein Eintrag dort als sog. 'Point'/'Terminal' (den Sie mit dem/der Sysop absprechen muessen); * Ein Tool zum Bereitstellen der Zerberus(tm)-kompatiblen Netcall-Datei 'PUFFER', z.B. die "Zimmermann Message Preparation Utility v1.30"; _________________________________ <:-) ___________________________________ Installations-Hinweise: ----------------------- Im Betriebssystem sind fuer die korrekte Funktionsweise der 'BiPoint'- Software keine besonderen Einstellungen vorzunehmen. Achten Sie jedoch generell darauf, dass Ihre COMSPEC-Umgebungsvariable den korrekten Wert (Pfad und Name Ihres Kommando-Prozessors, i.d.R. "C:\COMMAND.COM") enthaelt. (Ueberpruefen koennen Sie dies, indem Sie am DOS- Bereitschaftszeichen (Prompt) den DOS-Befehl 'SET' eingeben, worauf Ihnen u.a. der aktuelle Wert der COMSPEC-Umgebungsvariablen angezeigt wird.) In Telix muessen insbesondere das Up- und Download-Verzeichnis sowie der zu benutzende COM-Port und die Uebertragungs-Parameter richtig installiert sein, auch da 'BiPoint' diese Einstellungen verwendet. Auch jener Befehl, der Ihr Modem zum Waehlen veranlasst ("Dialing prefix", i.d.R. "ATDP"), und jener, der eine Befehlszeile abschliesst ("Dialing suffix", i.d.R. ",,,^M"), muessen in Telix eingestellt sein. Auch der zu verwendende Editor (in Telix mit ALT-A aufzurufen) muss korrekt angegeben sein, damit Sie die eingegangene Post auch bearbeiten koennen. Installieren Sie schliesslich die Telix-Puffer moeglichst klein. z.B.: - "Scroll Back buffer size ... 4 (KBytes)" - "Capture file buffer size ... 4 (KBytes)" - "File xfer disk buf. size (Kb) ... 4" Da das Programm-Paket recht umfangreich ist, koennten andernfalls bei grossen Telix-Puffern eventuell Speicherplatzprobleme auftreten ("Not enough memory"). Aus dem gleichen Grund sollten Sie auch vermeiden, waehrend Ihrer DFUe-Sitzungen speicher-renitente Programme geladen zu haben. Denn zum einen benoetigen diese bekanntlich ja (u.U. wertvollen) Speicherplatz, und zum anderen haben einige von ihnen (zumal, wenn sie geballt auftreten) die unangenehme Eigenschaft, Interrupts und Zeichen zu 'verschlucken', was dann beinahe notwendig zu Uebertragungsfehlern fuehrt. Uebrigens: Da nach und nach immer mehr Mailboxen mit schnellen Modems (9600 und 19200 Bits/Sek.) arbeiten, muessen Sie ggf. mehrere Kommata hinter die Telefonnummer schreiben, damit Ihr Modem etwas laenger wartet (i.d.R. 1/2 Sek. pro Komma), bevor es auflegt bzw. das Box-Modem auf Ihre Geschwindigkeit heruntergeschaltet hat. (In der LINK-H und der OLN haben sich 6 - 7 Kommata bewaehrt, was einer Wartezeit von etwa 3 Sekunden entspricht, in der das Box-Modem auf 2400 herunterschalten kann.) In Telix sollten Sie die selbstaendige Geschwindigkeits-Erkennung abschalten: - "Auto baud detect .... Off" (im Menu "Modem and dialing parameter setup"), da es andernfalls zu Koordinationsproblemen zwischen den beiden beteiligten Modems kommen kann, die letzlich eine Verbindung nicht zustande kommen lassen koennen. 'BiPoint' schaltet fuer die Dauer seiner Arbeit daher diese Option selbsttaetig aus. Die Programme 'Bixxx.SLC' kopieren Sie bitte in das Verzeichnis, in dem Sie Ihre Telix-Scripts abgelegt haben ("Script directory"). Die Konfigurations- Datei 'BiPoint.CNF' kopieren Sie in das Verzeichnis, von dem aus Sie Ihre Daten versenden ("Upload directory"). Einzustellen sind diese Verzeichnisse im Telix-Untermenu "Filenames and paths" im Menu "Configure Telix", das Sie mit 'ALT-O' aufrufen koennen. Fuer die Einzelheiten der Telix-Installation verweisen wir auf die zu Telix gehoerende ausfuehrliche Dokumentation. Die Datei 'BiPrep.BAT' kopieren Sie mit Marc Zimmermanns 'MsgPrep' (entsprechende Dokumentation lesen!) in Ihr Point-Verzeichnis (das auch in 'BiPoint.CNF' anzugebende Verzeichnis, aus dem der PUFFER kommt) und passen es an den darinnen angegebenen Stellen an Ihre Installation (Pfade etc.) an. Bei BiModem achten Sie bitte darauf, KEINE BiModem-Transfer-Liste (BIMODEM.PTH) anzulegen, da es hiermit - wie sich im praktischen Betrieb gezeigt hat - zu Koordinierungs-Problemen mit der 'BiNet'-Software ihrer Box kommen kann. Ausserdem installieren Sie BiModem bitte so, dass von Ihnen KEINE Ueberpruefung nach dem Transfer stattfindet - "Always verify when done N" sowie - "Verify files when done transferring N" Allerdings muessen Sie der 'BiNet'-Boxsoftware Zugriff von aussen gestatten: - "Allow remote file requests Y", da die gegenwaertige BiNet-Software Ihrer Mailbox zur korrekten Funktion das Ergebnis der Upload-Verifizierung benoetigt. Bekommt sie dies nicht, erhalten Sie bei Ihrem naechsten Anruf alle alten Daten nocheinmal, weil die Box davon ausging, dass die Uebertragung nicht geklappt hat und daher die dort fuer Sie angelegte Point-PUFFER-Datei nicht loescht. Die Mailbox-Software loescht auch CALLER.* und CALLED.* nicht einzeln, sondern ueberschreibt sie erst bei einem naechsten Netcall. Weil 'BiPoint' zur Auswertung des Netcalls in der Datei 'BiPoint.LOG' die Angaben der verschickten Dateien benoetigt, hindern Sie BiModem auch daran, diese Dateien zu loeschen: - "Delete source file when done (Y/N) N", dies erledigt 'BiPoint' nach einem ordnungsgemaess abgewickelten Netcall ohnehin. Als Hilfestellung fuer Ihre BiModem-Installation haben wir diesem Software- Paket eine BIMODEM.CFG beigefuegt, die Sie in Ihr BiModem-Verzeichnis kopieren und Ihren Wuenschen entsprechend anpassen (v.a. Dateinamen und Pfade) koennen. - Generell sollten Sie die BiModem-Dokumentation aufmerksam lesen, bevor Sie mit diesem leistungsfaehigen Protokoll arbeiten. Wir empfehlen Ihnen darueberhinaus, in der Anfangszeit (bis BiModem auf Ihrem Rechner und der Box korrekt arbeitet) Ihren Vertreter (SYSOP@IHR_POINT) zu loeschen, damit keine persoenlichen Nachrichten verlorengehen koennen, und Ihre Post 'zu Fuss' abzuholen. Hierfuer fuegen wir ein kurzes Script im Quellcode bei ("ZERBERUS.SLT"), das Sie Ihren Beduerfnissen entsprechend anpassen koennen. Die korrekte Funktionsweise von 'BiPoint' koennen Sie bei BiModem-Uebertragungen waehrend des Transfers beobachten und anhand der uebermittelten Daten pruefen. _ Sollten Sie bisher noch keinen Point-Account in Ihrer Heimatbox haben, besprechen Sie alle diesbezueglichen Einzelheiten (Name, Passwort, Komprimierungs-Programm, Protokoll, Poll-Zeiten) mit dem/der Sysop Ihrer Box. Falls trotz korrekter Installation aller beteiligten Programme einmal Probleme auftreten sollten, die Sie auch mit dem/der Sysop Ihrer Box nicht loesen koennen, schicken Sie uns mit per e-mail die Bildschirmdump-Datei 'BiPoint.IMG' (unter Telix "Screen Image ... Alt-I" erzeugbar), aus dem die Fehler-Meldungen zu ersehen sind, oder eine (moeglichst genaue) Problembeschreibung. Wir versprechen Ihnen, soweit es in unseren Moeglichkeiten liegt, bei der Behebung von Problemen im Zusammenhang mit der 'BiPoint'-Software behilflich zu sein. _________________________________ <:-) ___________________________________ Die Arbeitsweise der Scripts: ----------------------------- Nachdem Sie Telix gestartet haben, rufen Sie 'BiPoint' auf, indem Sie Ihr selbstgeschriebenes Script (mit ALT-G) starten. Als Muster dafuer koennen Sie bspw. das unten abgedruckte Script (zum Netcall mit der OLN) verwenden. Haben Sie als Protokoll-Parameter darin keinen gueltigen Kennbuchstaben ('B', 'X', 'Y' oder 'Z') angegeben, werden Sie in einem Bildschirmfenster aufgefordert, das gewuenschte Uebertragungsprotokoll auszuwaehlen: ____________________________________________________________ _ _____ [B]iModem [X]Modem [Y]Modem [Z]Modem ____ _ _ _ _ Welches Uebertragungs-Protokoll soll verwendet werden?_ _ ____________________________________________________________ Dies ist die einzige Stelle im Programm, an der KEIN automatischer Abbruch stattfindet, falls Sie nichts eingeben. Achten Sie daher bitte darauf, dass Sie in Ihrem aufrufenden Script einen gueltigen Kenn-Buchstaben angeben, da in diesem Fall das Protokoll-Menu gar nicht erst erscheint. Zur Sicherheit unterbricht das Programm nun eine eventuell noch bestehende Verbindung ("Hanging up"). Ausserdem werden eventuell (von frueheren Netcalls) noch vorhandene CALLER.xxx und CALLED.xxx geloescht. Da Bi- und Z-Modem bekanntlich einen (z.B. aufgrund eines Leitungszusammenbruchs) unterbrochenen Dateitransfer wiederaufnehmen kann, fragt 'BiPoint', falls Sie fuer Ihren Netcall das Bi- oder ZModem-Protokoll verwenden, jedoch zuerst nach, ob die Download-Datei geloescht werden soll: ____________________________________________________________________ _ CALLED.ARC 22089 Bytes vom 29.11.90 um 23:48:00 loeschen (J/N)? __ ____________________________________________________________________ Dann wird Ihre Konfigurations-Datei 'BiPoint.CNF' eingelesen und die Eintraege darin ueberprueft. Sollten die dort von Ihnen angegebenen Programme ('Packer' und BiModem) nicht vorhanden sein, oder waehrend des Einlesens Fehler auftreten, wird das Programm (mit einem entsprechenden Ergebnis-Code, s.u.) abgebrochen. Das gleiche gilt, wenn die Datei im Telix-Upload-Verzeichnis nicht gefunden werden konnte, wobei Ihnen dieser Umstand zusaetzlich ausdruecklich mitgeteilt wird: ________________________________ _ _ _ BiPoint.CNF nicht gefunden _ _ _ ________________________________ Sofern es in dem angegebenen Verzeichnis eine PUFFER-Datei gibt, werden Sie als naechstes gefragt, ob Sie diese versenden wollen, etwa in dieser Art: __________________________________________________________________ _ PUFFER 46180 Bytes vom 29.11.90 um 23:30:16 versenden (J/N)? __ __________________________________________________________________ Reagieren Sie innerhalb von 30 Sekunden darauf nicht, wird 'NEIN' angenommen und nichts verschickt. Auf diese Weise ist es einerseits moeglich, die 'BiPoint'-Software auch unbeaufsichtigt laufen zu lassen, ohne dabei versehentlich Daten aufs Netz zu schicken, die nicht dorthin sollen. Andererseits soll so vermieden werden, dass Sie frueher aus dem Netz geholte Daten erneut versenden (was wegen des gleichen Namens PUFFER fuer sowohl empfangene als auch zu versendende Daten ein beinahe 'klassischer' Fehler ist). Das in der Konfigurationsdatei angegebene Programm zum Packen der Daten wird aufgerufen und der PUFFER versandfertig komprimiert, was Ihnen durch einen entsprechenden Hinweis gemeldet wird: ______________________________________________________ _ _ _ Die Datei PUFFER wurde zum Versand komprimiert _ _ _ ______________________________________________________ Sollten waehrend des Komprimierens Fehler aufgetreten sein, die Ihr 'Packer' meldet (z.B. falsche Aufrufparameter), so werden Sie auf den Effekt hingewiesen: ____________________________________________ _ _ _ PUFFER konnte nicht komprimiert werden _ _ _ ____________________________________________ Falls keine PUFFER-Datei vorhanden war oder Sie die vorhandene nicht versenden wollten, erscheint stattdessen folgender Hinweis: ___________________________________________________ _ _ _ Dummy-PUFFER wurde zum Versand fertig gemacht _ _ _ ___________________________________________________ Praktisch bedeutet dies folgendes: Da Ihre Box bei einem Netcall ja erwartet, auch Daten uebermittelt zu bekommen, muessen Sie auch welche versenden. Haben Sie nun keine, so wird eine Datei versandt, die lediglich eine Leerzeile (CR/LF) enthaelt - und die Box ist's zufrieden. Wenn bis hier alles ordnungsgemaess abgewickelt wurde, erscheint ein weiterer, kurzer Hinweis, aus dem Sie das verwendete Protokoll sowie Ihren Point-Namen ersehen koennen: _____________________________________________________ _ _ _ Bi-Modem-Netcall [EVALUATION COPY fuer MY_POINT] _ _ _ _____________________________________________________ Jetzt wird das 'Protokoll' (capture-file) angelegt. Sollten hierbei irgendwelche Probleme auftreten (wofuer es eigentlich nur zwei (unwahrscheinliche) Gruende geben kann: 1. Ihre Platte ist voll bzw. kein Platz mehr im Directory; 2. es existiert unter dem Namen eine schreibgeschuetzte Datei), wird Ihnen dieser Umstand angezeigt: _______________________________________ _ _ _ Fehler beim Oeffnen der Log-Datei _ _ _ _______________________________________ Erst jetzt startet Telix die Anwahl Ihrer Mailbox und stellt die Verbindung her, was Ihnen im Erfolgsfalle durch einen entsprechenden Hinweis angezeigt wird: ________________________________________________________ _ _ _ Verbindung hergestellt - NetCall hat begonnen ... _ _ _ ________________________________________________________ Sollte sich die Box jedoch innerhalb von sechs Minuten nicht korrekt melden, so erscheint der folgende Hinweis auf Ihrem Bildschirm: ___________________________ _ _ _ Box meldet sich nicht _ _ _ ___________________________ Falls waehrend der Phase des Einloggens und der Identifikation aus irgendwelchen Gruenden (bspw. schlechte Leitungsqualitaet) die Verbindung unterbrochen worden sein sollte, werden Sie auch hierauf hingewiesen: _______________________________ _ _ _ Traegersignal verloren! _ _ _ _______________________________ Bei all diesen (seltenen, aber nicht unmoeglichen) Fehlern werden alle folgenden Schritte nicht ausgefuehrt, das Script stattdessen abgeschlossen und die entsprechende Fehlerursache in der Datei 'BiPoint.LOG' vermerkt. Dann identifiziert sich Ihr 'BiPoint' gegenueber der Box und tauscht die Daten (mit dem Protokoll Ihrer Wahl) aus. Sobald die wechselseitige Identifikation abgeschlossen ist, komprimiert die Mailbox die fuer Sie bereitliegenden Daten. 'BiPoint' macht Sie hierauf entsprechend aufmerksam: ___________________________________ _ _ _ Box komprimiert Netcall-Datei _ _ _ ___________________________________ Nach Ende des Netcalls wird die Leitung unterbrochen ("Hangup") und Sie werden entsprechend informiert: __________________________________________________ _ _ _ NetCall wurde beendet - Leitung unterbrochen _ _ _ __________________________________________________ Sollte unterdessen ein Fehler aufgetreten sein, werden Sie auch am Monitor darauf hingewiesen, z.B. so: ________________________________________ _ _ _ NetCall beendet mit Fehlercode -5 _ _ _ ________________________________________ Die Bedeutung der einzelnen Ergebnis-Codes ist im folgenden erklaert und geht auch aus dem Beispiel-Script unten (zum Netcall mit der OLN) hervor: _ 0 = Netcall erfolgreich abgewickelt -1 = BiModem-Verbindung konnte nicht hergestellt werden (abhaengig von BiModem-Installation: "Number of seconds to wait for connect") -2 = PUFFER konnte nicht extrahiert werden (wg. falschem Parameter fuer das Dekomprimierungs-Programm oder schlechtem Sektor(en) im Bereich der empfangenen Datei CALLED.xxx) -3 = CALLED.xxx nicht angekommen (duerfte eigentlich nie auftreten, laesst auf eine defekte FAT schliessen - Virus im System?) -4 = Login in Mailbox fehlgeschlagen (entweder hat sich die Box innerhalb von 3 Minuten nicht korrekt gemeldet, oder die Leitungsverbindung wurde zwischendurch unterbrochen) -5 = Anwahl erfolglos (entweder war waehrend der in der Konfigurations- Datei 'BiPoint.CNF' angegeben Anzahl von Anwahlversuchen staendig besetzt, das Traegersignal (CARRIER) ist verlorengegangen oder Sie haben das 'BiPoint'-Script beim Waehlen mit ESC abgebrochen) -6 = Konfigurations-Datei fehlerhaft (Falsche Reihenfolge? Ungueltige Eintraege? - Ueberpruefen Sie 'BiPoint.CNF'!) -7 = Carrier beim Upload (mit XYZ-Modem) verloren -8 = Uebertragung beim Upload (mit XYZ-Modem) abgebrochen -9 = Carrier beim Download (mit XYZ-Modem) verloren -10 = Uebertragung beim Download (mit XYZ-Modem) abgebrochen -11 = waehrend BiModem-Transfer Carrier verloren -12 = veraenderte BiModem-Version auf der anderen Seite (gepatcht oder Viren-infiziert) -13 = CTS ist ausgeschaltet (abhaengig von BiModem-Installation: "CTS/RTS hardware flow control (Y/N)") -14 = zu viele Fehler waehrend Uebertragung (abhaengig von BiModem- Installation: "Max # of errors before disconnect") -15 = unbekannter BiModem-Fehler (fuehrt nicht zum Programm-Abbruch) -20 = Text-Anzeige-Programm nicht gefunden -21 = (Telix-)Editor nicht gefunden (wenn Sie in Telix den mit ALT-A aufzurufenden Editor nicht korrekt angegeben haben) -22 = PUFFER nicht gefunden (sollte nur passieren, wenn Sie weder einen PUFFER verschickt noch einen empfangen haben) -23 = PUFFER bis zum Ende gelesen (sic!) -24 = PUFFER-Bearbeitung beendet (durch entsprechende Menu-Auswahl) Schliesslich wird die empfangene PUFFER-Datei auch gleich 'ausgepackt', was Ihnen ebenfalls mitgeteilt wird: ___________________________________________ _ _ _ Die Datei PUFFER wurde dekomprimiert _ _ _ ___________________________________________ Wurden saemtliche Schritte bis hierher fehlerlos abgewickelt, so wird das eigene 'Logbuch' (capture-file) geloescht, die Datei 'BiPoint.LOG' auf den neuesten Stand gebracht, die Dateien CALLER.xxx sowie CALLED.xxx geloescht. Nach einem ZModem-Netcall finden Sie in der Datei 'BiPoint.LOG' einen Eintrag nach folgendem Muster: 90.12.01 18:42:13 __ Z-Modem-Netcall _ 90.12.01 19:09:12 Connected with : Manually entered number. 90.12.01 19:09:12 ++ At phone # : 0202473086 90.12.01 19:09:12 ++ Settings : 9600,N,8,1 90.12.01 19:09:16 Elapsed time until Connection : 00:27:01 90.12.01 19:09:31 Upload using Zmodem protocol. 90.12.01 19:09:31 ++ File : \UPLOAD\CALLER.ARC 90.12.01 19:09:35 ++ Chars per second : 639 90.12.01 19:09:40 Download using Zmodem protocol. 90.12.01 19:09:40 ++ File : \Download\called.arc 90.12.01 19:10:50 ++ Chars per second : 658 90.12.01 19:11:04 __ Netcall erfolgreich abgewickelt _ _ Nach einem Netcall mit BiModem sieht der Eintrag aehnlich aus: 90.12.03 23:35:58 __ Bi-Modem-Netcall _ 90.12.03 23:39:03 Connected with : Manually entered number. 90.12.03 23:39:03 ++ At phone # : 05113505604 90.12.03 23:39:03 Elapsed time until Connection : 00:03:02 90.12.03 23:39:03 ++ Settings : 2400,N,8,1 90.12.03 23:39:47 Upload using BiModem protocol. 90.12.03 23:39:47 ++ File : CALLER.ARC 90.12.03 23:39:47 ++ Transfer : Successfull (5176 bytes) 90.12.03 23:39:47 ++ Chars per second : 272 90.12.03 23:39:47 ++ Remote-ID : OekolineMailbox SYSOP@OLN.ZER v1.23 -350 5604 90.12.03 23:44:16 Download using BiModem protocol. 90.12.03 23:44:16 ++ File : CALLED.ARC 90.12.03 23:44:16 ++ Transfer : Successfull (65217 bytes) 90.12.03 23:44:16 ++ Chars per second : 225 90.12.03 23:44:16 ++ Remote-ID : OekolineMailbox SYSOP@OLN.ZER v1.23 -350 5604 90.12.03 23:44:37 __ Netcall erfolgreich abgewickelt _ 90.12.03 23:44:37 Elapsed time online 00:05:21 Beachten Sie bitte, dass die Datei 'BiPoint.LOG' dann nicht ordnungsgemaess geschlossen werden koennte, wenn Sie das Script zwischendurch (mit ESC) abbrechen wuerden. Daher wird diese Moeglichkeit des Programm-Abbruchs unterbunden - lediglich in dem Fenster, mit dem Telix Ihnen anzeigt, dass gerade gewaehlt wird, koennen Sie (mit ESC) 'BiPoint' abbrechen. In diesem Fall erscheint in der Datei 'BiPoint.LOG' die Meldung "Anwahl erfolglos". Noch ein Hinweis zu BiModem: Aeltere BiModem-Versionen als v1.22 koennen die Telefon-Nummer des Gegenuebers NICHT korrekt darstellen: Auf dem Bildschirm waehrend des Datentransfers sehen Sie eine praktisch willkuerliche Nummer. Achten Sie zumindest darauf, bei BiModem Ihre eigene Nummer richtig zu formatieren ("Phone number edit mask"). Nachdem Sie nun also einen neuen PUFFER empfangen haben, koennen Sie sich die einzelnen Nachrichten gleich ansehen. Dabei erscheint ein Bildschirm-Fenster etwa dieser Art: _______________________________________________________________________ _ _ _ Datei :\POINT\PUFFER 13043 Byte von 34323 gelesen _ _ _ _ Empfaenger :/Z-NETZ/TELECOM/NETZWERKE _ _ Nachricht von:BRIAN_O'FISH@MULI.ZER _ _ Betreff :Hitchikers Guide to Zerberus Netcalls _ _ Datum :19.07.1990 - 09:10 _ _ Route :MIDGET!MULI!HHN!GCS!INFINET!LINK-H!OLN _ _ ID :49.222@MIDGET _ _ Typ :Text _ _ Groesse :13043 Bytes _ _ _ _______________________________________________________________________ Sie koennen nun entscheiden, wie Sie weiter verfahren wollen, indem Sie aus dem folgenden Menu die gewuenschte Option durch die entsprechende Taste auswaehlen: ____________________________ _ _ _ [L]esen _ _ [W]eiter Blaettern _ _ [S]peichern als Datei _ _ [A]ntwort ins Brett _ _ [P]ersoenliche Antwort _ _ [B]eenden _ _ _ _ ____________________________ Wenn Sie innerhalb von 5 Minuten (300 Sekunden) keinen Menu-Punkt waehlen, so gibt 'BiView' den Code -24 (Arbeit beendet) an das aufrufende 'BiPoint'- Programm zurueck. Durch diese Schleife soll zwei einander widersprechenden Anspruechen Rechnung getragen werden: Zum einen koennen Sie auf diese Weise 'in aller Ruhe' ueberlegen und auswaehlen; zum anderen aber koennen Sie 'BiPoint' auch unbeaufsichtigt im Batch-Betrieb laufen lassen. Wenn Sie am Ende Ihres Telix-Scripts, mit dem Sie 'BiPoint' aufrufen, den "ExitTelix"- Befehl verwenden, wird das DFUe-Programm auch gleich verlassen, und Sie koennen irgendeines Ihrer DOS-BATch-Programme weiterarbeiten lassen. Wollen Sie die Nachricht [L]esen, so wird das in Ihrer Konfigurations-Datei angegebene Anzeigeprogramm gestartet (empfehlenswert: 'LIST' bzw. 'FV' von Vernon D. Buerg). Handelt es sich um eine Text-Datei, wird der Textlister aufgerufen, andernfalls das Programm zum Anzeigen von Binaerdateien. Selbstverstaendlich koennen Sie auf die Nachricht auch antworten: entweder (privat) an den Absender oder (oeffentlich) in das Brett, in dem die Nachricht steht. Dazu wird ein neuer Nachrichtenkopf generiert und Ihr Editor gestartet, dem die Antwortdatei uebergeben wird. Diese sieht bei einer [P]ersoenlichen Antwort ungefaehr so aus: ------------------------------schnipp------------------------------------- BRIAN_O'FISH@MULI.ZER A. auf: Hitchikers Guide to Zerberus Netcalls T In seiner Nachricht vom 19.07.1990 schreibt BRIAN_O'FISH@MULI.ZER: ------------------------------schnapp------------------------------------- [A]ntworten Sie oeffentlich im Brett, so sieht es etwas anders aus: ------------------------------schnipp------------------------------------- /Z-NETZ/TELECOM/NETZWERKE A. auf: Hitchikers Guide to Zerberus Netcalls T In seiner Nachricht vom 19.07.1990 schreibt BRIAN_O'FISH@MULI.ZER: ------------------------------schnapp------------------------------------- Nachdem Sie Ihren Text geschrieben und mit Ihrem Editor gespeichert haben, werden Sie nocheinmal gefragt, ob Sie die Antwortdatei tatsaechlich verschicken moechten: _______________________________________________________________________ _ 64876089.MSG 987 Bytes vom 29.08.90 um 22:59:38 verschicken (J/N)? __ _______________________________________________________________________ Auch hier gilt wieder, dass Sie innert 30 Sekunden antworten sollten, da sonst Nein angenommen wird. Beantworten Sie die Frage (so oder so) mit Nein, wird die Antwortdatei geloescht, so dass Sie sich Ihre Platte nicht 'zumuellen'. Der Dateiname wird uebrigens aus der jeweils aktuellen Systemzeit und -datum generiert, so dass doppelte Dateinamen mit hoher Wahrscheinlichkeit vermieden werden. Beachten Sie bitte, dass Sie zum Versenden (bzw. dem Generieren eines Versand- PUFFERs) derzeit noch auf ein seperates Programm angewiesen sind (z.B. die "Zimmermann Message Preparation Utility"). Unser Modul 'BiPrep.SLC' befindet sich noch in der Entwicklung und kann daher derzeit noch nicht mitgeliefert werden. Stattdessen fuegen wir diesem Paket die Datei 'BiPrep.BAT' bei, die in Zusammenarbeit mit Marc Zimmermanns 'MsgPrep' einen Netcall-PUFFER bereitstellt. Falls Sie die Nachricht (seperat von der PUFFER-Datei) [S]peichern wollen, wird eine entsprechende Datei angelegt und dies am Bildschirm angezeigt: ___________________________________________________________ _ _ _ Nachricht wurde gespeichert als: \POINT\64876190.TxT _ _ _ ___________________________________________________________ Fuer die Generierung des Dateinamens gilt das gleiche wie oben erwaehnt: die Systemzeit und -datum werden verwendet. Wenn Sie [W]eiterblaettern, wird Ihnen der naechste Nachrichtenkopf w.o. angezeigt. Auf diese Weise koennen Sie den gesamten eingegangenen PUFFER lesen und verarbeiten. Schliesslich werden Sie dann darauf hingewiesen, dass die Datei vollstaendig gelesen wurde: ___________________________ _ _ _ PUFFER zuende gelesen _ _ _ ___________________________ Sie koennen das Lesen jedoch auch zwischendurch [B]eenden, was Ihnen dann ebenfalls auf dem Bildschirm quittiert wird: ____________________ _ _ _ Arbeit beendet _ _ _ ____________________ Abschliessend wird die Kontrolle an das aufrufende Script (das Sie nach dem unten abgedruckten Muster selbst erstellen koennen) zurueckgegeben. Dort koennen Sie nach Bedarf den zurueckgegebenen Ergebnis-Code auswerten. _________________________________ <:-) ___________________________________ Was ist ein Point: ------------------ Es ist recht zeitraubend, wie ueblich 'online' in eine Box zu gehen, um dort die neuesten Nachrichten zu lesen: Zunaechst muss man warten, bis die Box frei ist und man sich einloggen kann - nicht selten (zumal am fruehen Abend) sind dazu Dutzende von Anrufen noetig. Bis man dann jene Bretter angewaehlt hat, in welchen man nachsehen moechte, und die interessanten Artikel rausgepickt hat, die man lesen moechte, vergeht wieder kostbare Zeit (und entstehen Teflon-Kosten). Ist man dagegen als sog. 'Point' an eine Zerberus-Mailbox angeschlossen, erhaelt man alle neuen Nachrichten in den bestellten Brettern automatisch. Dazu ruft der Point regelmaessig bei seiner Mailbox an. Die gesamte Uebertrageung laeuft automatisch ab. Da die Daten komprimiert uebertragen werden (z.B. "geARCt"), wird zusaetzlich die Telefonrechnung geschont. Damit kann man zumindest Boxen im Nahbereich auch tagsueber im 8-Minuten-Takt anrufen, zumal dann die Box auch eher frei ist. Anschliessend kann man in Ruhe ('offline') die Nachrichten lesen sowie ggf. beantworten. Und weil dabei auch kein Gebuehrenzaehler mit-tickt, kann man genauer lesen oder zum Beantworten auch mal in der Literatur (Buecher/Zeitschriften) nachschlagen. _________________________________ <:-) ___________________________________ Das 'Abonnieren' von Brettern: ------------------------------ Mailbox-Bretter, deren Inhalt Sie regelmaessig beziehen moechten, koennen Sie bei Ihrer Box gewissermassen 'abonnieren'. Dazu gibt es zwei Wege, die Sie mit dem/der Sysop Ihrer Box absprechen muessen. Der eine Weg besteht darin, dass Sie dem/der Sysop mitteilen, welche Bretter Sie beziehen moechten. Alles weitere wird dann in der Box veranlasst. Da dies fuer alle Beteiligten ein recht aufwendiger Weg ist, wurde von den 'Muli labs' (Brian O'Fish) ein Hilfsprogramm entwickelt, das Ihnen die Moeglichkeit bietet, je nach Bedarf Bretter zu abonnieren oder auch wieder abzubestellen. Das geschieht einfach dadurch, dass Sie dem Pseudo-User "MAPS" eine Nachricht mit ihren Wuenschen schicken. BEVOR Sie dies aber tun, senden Sie bitte zunaechst nur eine Nachricht an MAPS mit dem Betreff HILFE * Einen Text braucht Ihre Nachricht nicht zu enthalten - er wuerde ohnehin ignoriert - eine Leerzeile reicht. Mit Ihrem naechsten Netcall erhalten Sie dann von der Box ausfuehrliche Hinweise dazu, auf welche Weise mit MAPS im Detail umzugehen ist. Erst nachdem Sie diese Hilfetexte aufmerksam gelesen (und bei Bedarf mit dem/der Sysop besprochen) haben, sollten Sie tatsaechlich mit MAPS arbeiten. _________________________________ <:-) ___________________________________ Das Weiterleiten persoenlicher Nachrichten: ------------------------------------------- Sofern Sie persoenliche Nachrichten an andere UserInnen versenden wollen, aendert sich fuer Sie durch die Benutzung eines 'Points' zunaechst einmal gar nichts - abgesehen davon, dass Sie erhebliche Telefongebuehren sparen koennen, weil Sie nun ja nicht mehr 'online' arbeiten, sondern in Ruhe zuhause. Die Adressierung (V.NACHNAME@BOX.ZER) an UserInnen anderer Boxen bleibt die gleiche. Beachten Sie bitte nur, dass Sie bei Nachrichten an NutzerInnen Ihrer Heimatbox lediglich den Namen der Empfaenger (ohne: @BOX.ZER) angeben. Damit auch jene Nachrichten, die in Ihr persoenliches Postfach gesendet werden, an Ihren Point (via Netcall) weitergeleitet werden, muessen Sie in Ihrer Box einen STELLVERTRETER benennen: SYSOP@MY_POINT. Nachdem Sie in Ihrer Heimatbox diesen Befehl eingegeben haben, werden automatisch alle persoenlichen Nachrichten in Ihre Netcall-Datei einsortiert und Ihnen beim naechsten Anruf uebermittelt. _________________________________ <:-) ___________________________________ Das Netcall-Script: ------------------- Ihr eigenes Script zum Netcall in der OLN koennte bspw. so aussehen: --------------------------------- schnipp --------------------------------- /////////////////////////// CallOLN.SLT //////////////////////// // // // Telix-Salt-Script zum automatisierten Einloggen bei OekoLine // // // // Kontaktadresse oekoline // // ----------------------- // // Udo Schacht-Wiegand // // Moorkamp 46, 3000 Hannover 1 // // Tel: 0511-350 30 81 (privat, bis 22 Uhr) // // OLN-Mailbox: 0511-350 56 04 (300 bis 9600 Baud, 8N1) // // // // In der Mailbox: SYSOP oder U.SCHACHT-WIEGAND // // // /////////////////// (C) 1989,90 DFG/M.Watermann /////////////// Main() { Int Erfolg; Erfolg = CallD("BiPoint", "05113505604,,,", "OLN", "PASSWORT", "B"); // ^ ^ ^ ^ ^ // | | | | |_ Protokoll // | | | | // | | | |_ Point-Passwort // | | | // | | |__ Endung der Capture-Datei // | | // | |___ Telefonnummer der Mailbox // | // |___ Name des Telix-BiModem-Scipts // PrintS(); // Leerzeile if (Erfolg == 0) { PrintS(" Netcall erfolgreich"); } else { Tone(523, 10); Tone(659, 10); Tone(523, 10); Tone(659, 10); if (Erfolg == -1) PrintS(" BiModem-Verbindung kann nicht hergestellt werden"); else if (Erfolg == -2) PrintS(" PUFFER konnte nicht extrahiert werden"); else if (Erfolg == -3) PrintS(" CALLED.xxx nicht angekommen"); else if (Erfolg == -4) PrintS(" Login in Mailbox fehlgeschlagen"); else if (Erfolg == -5) PrintS(" Anwahl erfolglos"); else if (Erfolg == -6) PrintS(" Konfigurations-Datei fehlerhaft"); else if (Erfolg == -7) PrintS(" Carrier beim Upload verloren"); else if (Erfolg == -8) PrintS(" Uebertragung beim Upload abgebrochen"); else if (Erfolg == -9) PrintS(" Carrier beim Download verloren"); else if (Erfolg == -10) PrintS(" Uebertragung beim Download abgebrochen"); else if (Erfolg == -11) PrintS(" BiModem hat Carrier verloren"); else if (Erfolg == -12) PrintS(" veraenderte BiModem-Version auf der anderen Seite"); else if (Erfolg == -13) PrintS(" CTS ausgeschaltet"); else if (Erfolg == -14) PrintS(" zu viele Fehler waehrend BiModem-Uebertragung"); else if (Erfolg == -20) PrintS(" Text-Anzeige-Programm nicht gefunden"); else if (Erfolg == -21) PrintS(" (Telix-)Editor nicht gefunden"); else if (Erfolg == -22) PrintS(" PUFFER im angegebenen Verzeichnis nicht gefunden"); else if (Erfolg == -23) PrintS(" PUFFER bis zum Ende gelesen"); else if (Erfolg == -24) PrintS(" PUFFER-Bearbeitung beendet"); } PrintS(); // Leerzeile } // end of Main() ------------------------------- schnapp ----------------------------------- Die Protokoll-Datei (capture-file) bekommt ihren Namen automatisch zugewiesen. Er besteht aus dem aktuellen Datum in der Form JJMMTT sowie der 'BiPoint' als Parameter 'Ext' uebergebenen Endung. Auf diese Weise laesst sich mit einem Blick ins Inhaltsverzeichnis leicht das Wann und Wo der einzelnen fehlgeschlagenen Anrufe erkennen. Die Protokoll-Datei eines Anrufs in der Oekoline-Box am 2. Nov. 1990 wuerde dann bspw. heissen: '901102.OLN'. Bei einem fehlerlos abgewickelten Netcall wird diese Protokoll-Datei allerdings am Programmende automatisch geloescht, so dass im Normalfall keine Dateien 'uebrigbleiben'. _________________________________ <:-) ___________________________________ Die Konfigurations-Datei: ------------------------- Aus der Konfigurations-Datei 'BiPoint.CNF', die in Ihrem Telix-Upload- Verzeichnis liegt, werden die folgenden Angaben eingelesen: 1. Name Ihres Points 2. die Extension des verwendten Komprimierungs-Programms (i.d.R. "ARC"); 3. Suchpfad und Name des Komprimierungs-Programm (i.d.R. "PKARC"); 4. die Komprimierungs-Parameter (i.d.R. "-oc -u"); 5. das Verzeichnis, AUS dem die 'PUFFER'-Datei kommt; 6. Suchpfad und Name des Dekomprimierungs-Programm (i.d.R. "PKXARC"); 7. die Dekomprimierungs-Parameter (i.d.R. "-r"); 8. das Verzeichnis, IN das die 'PUFFER'-Datei kommt; 9. der Suchpfad und Name des BiModem-Programmes; hier muss in jedem Fall ein gueltiger Dateiname stehen: Wenn Sie also nicht mit BiModem arbeiten wollen oder koennen, so tragen Sie hier z.B. den Suchpfad und Namen Ihres Kommandoprozessors ein (i.d.R. "C:\COMMAND.COM"); 10. die Zahl der gewuenschten Anwahl-Versuche bei Ihrer Server-Box; steht hier eine 0 (Null), so wird 'endlos' angewaehlt; 11. Suchpfad und Name des Textanzeige-Programms (i.d.R. "LIST"); 12. Suchpfad und Name des Binaerdatei-Anzeigeprogramms (i.d.R. "FV"); _ Alle Zeilen, die entweder leer sind oder mit einem Semikolon (';') beginnen, werden als Kommentare angesehen und ignoriert. Sie koennen also beliebige Bemerkungen in die Konfigurations-Datei schreiben. Fuehrende Leerzeichen werden ebenfalls ignoriert. Lediglich die korrekte Reihenfolge der genannten Angaben muss sichergestellt sein. Ihre Datei 'BiPoint.CNF' koennte demnach etwa so aussehen: ------------------------------ schnipp ------------------------------------ ; Konfigurations-Datei zum Telix-BiPoint-Script ; fuer Point-Netcalls in Zerberus-Boxen ; --------------------------------------------- MY_POINT ; 1. Der Name Ihres Points ; ------------------------ ARC ; 2. die Extension des Quetschers ; ------------------------------- Q:\PkArc ; 3. Pfad und Name des Quetschers ; ------------------------------- -oc -u ; 4. Parameter zum Quetschen ; -------------------------- \Point ; 5. da kommt der PUFFER her ; -------------------------- Q:\PkXArc ; 6. Pfad und Name des Entquetschers ; ---------------------------------- -r ; 7. Parameter zum Dekomprimieren ; ------------------------------- \Point ; 8. da soll der neue PUFFER hin ; ------------------------------ \DFUe\BiModem ; 9. Pfad und Name des externen BiModem-Protokolls ; ------------------------------------------------ 0 ; 10. Anzahl der Waehlversuche (0 = unendlich) ; -------------------------------------------- U:\List ; 11. Textanzeige-Programm ; ------------------------ U:\FV ; 12. Binaerdatei-Anzeigeprogramm ; ------------------------------- ------------------------------ schnapp ------------------------------------ _________________________________ <:-) ___________________________________ Die beiden wichtigsten Protokolle: ---------------------------------- Das ZModem Datenuebertragungs-Protokoll sorgt fuer zuverlaessige Datei- und Befehls-Uebertragung mit vollstaendiger END-TO-END Daten-Integritaet zwischen verschiedenen Anwendungsprogrammen. ZModem's 32-Bit-CRC schuetzt auch vor den Fehlern sog. "error free" Modems und solchen, die selbst in den weitest entwickelten Netzen auftreten. Es sichert alle Daten und Ueberwachungs-Information mit einer effektiven Fehlererkennung. Seine Datenfluss-Behandlung eliminiert Verzoegerungen, wie sie durch die Datenblock-Behandlung von Kermit/XModem/YModem/JModem entstehen. Dabei verzichtet es auf die klassischen Kompromisse zwischen Uebertragungs- Effizienz und Fehler-Korrektur der XModem/YModem/JModem-Paketlaengen. ZModem's Paketlaenge ist die gesamte Datei. Benutzer-Freundlichkeit ist ein wichtiges ZModem-Feature. Der AutoDownload(tm) (automatischer Datei-Download, initiiert ohne Eingriff des Anwenders) vereinfacht, verglichen mit traditionellen Protokollen, den Datei-Transfer betraechtlich. BiModem(tm) ist ein neues Kommunikations-Protokoll, das es gestattet, GLEICHZEITIG in beiden Richtungen Daten zu uebertragen. BiModem kann Daten versenden (Upload) waehrend es zugleich empfaengt (Download). Stellen Sie sich die zeitlichen Einsparungen vor, wenn Sie mit der Leistungs- faehigkeit von Zmodem(tm)- und YmodemG Ihre Daten versenden koennen, waehrend Sie zur gleichen Zeit und mit derselben Leistungsfaehigkeit andere Daten empfangen. Zudem koennen Sie sich waehrend der Datenuebertragung auch noch mit dem/der Sysop Ihrer Mailbox via Bildschirm unterhalten (Chat) ... Aehnlich wie ZModem, benoetigt auch BiModem keine weiteren Eingaben, um sowohl Up- als auch Download selbsttaetig abzuwickeln. Wenn Sie sich als BiModem-Anwender haben registrieren lassen, koennen Sie zudem u.a. noch waehrend der Uebertragung (!) weitere Dateien zum Up- oder Download angeben. _________________________________ <:-) ___________________________________ Interna: -------- Zur Orientierung hier die Prozedur-Koepfe der einzelnen Scripts sowie (leicht gekuerzt mit freundl. Genehmigung von BRIAN_O'FISH@MULI.ZER) als Hintergrund-Information einige Hinweise zum eigentlichen Netcall. 'BiCheck.SLC': Main(Str Konfig_Datei, Str Pointname, Str UpFile, Str DownFile, Str BiMoDirPrg, Str BiPointLog, Str CmdLine, Str DeKompriPrg, Str DeKompParm, Int AnwahlVersuche, Str TextViewer, Str BinViewer) 'BiPoint.SLC': Main(Str Tel_Nr, Str Extension, Str Pass_Name, Str Protokoll) 'BiView.SLC': Main(Str ZielVerzeichnis, Str Version, Str Pointname, Str TextViewer, Str BinViewer) 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:", andernfalls 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) weitermachen. 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) -------------------------------- Die PUFFER-Datei 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 ------------ <Empfaenger> <Betreff> <Absender> <Datum> <Pfad> <MsgId> <Typ> <Laenge> ----------- End o'Kopf -------------- Die einzelnen Felder haben folgende Bedeutung: <Empfaenger> : Eine Zeichenkette ohne Leerzeichen und in Grossschrift. Maximallaenge: 40 Zeichen (hmm, unsicher, vielleicht mehr) Es gibt drei moegliche Erscheinungsformen: <Username> Empfaenger ist ein User, der in der Mailbox eingetragen ist, die das Netcallfile erhalten wird. Username darf keinen Klammeraffen (@) enthalten. Beispiel: BRIAN_O'FISH <Brettname> 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 <Username>@<Systemname>.ZER Empfaenger ist der User <Username> im Netzsystem <Systemname> 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 ! <Betreff> Der Nachrichtentitel. Eine beliebige Zeichenkette mit einer Maximallaenge von 40 Zeichen (wieder geschaetzt...) <Absender> Der Absender der Nachricht. Eine Zeichenkette ohne Leerzeichen und in Grossschrift. Maximallaenge sind wiederum 40 Zeichen. Der Absender sollte immer die Form <eigener_username>@<eigener_systemname>.ZER haben. Bei einem Terminal (Point) sollte der Pointname fuer 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 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. <Pfad> Der Nachrichtenpfad, den die Nachricht bereits gelaufen ist. Eine Zeichenkette ohne Leerzeichen, Maximallaenge 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 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. <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 erhoehter Zaehler ist. Beispiel: 08.15@MIDGET <Typ> 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). <Laenge> 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 <Username>@<Systemname>.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 <Laenge>-Zeile. Die Message ist genau <Laenge> Bytes gross, danach folgt sofort im naechsten Byte der naechste Kopf. _________________________________ <:-) ___________________________________ Die 'BiPoint'-Quelltexte: ------------------------- Von einigen NutzerInnen kam die Bitte, ihnen den Source-Code fuer eigene Modifikationen zur Verfuegung zu stellen. Diesen Wunsch koennen wir leider nicht nachkommen: Zum einen ist das Programm-Paket derzeit schon rund 112 KByte (ca. 3.300 Zeilen) gross, was vermutlich ziemlich viel Arbeit bedeuten wuerde, es zu verstehen und zu veraendern. Zum zweiten arbeiten wir noch immer daran (z.B. soll auch das Herstellen der Zerberus-PUFFER-Datei ins Script integriert werden), und wir moechten vermeiden, dass von dem Programm voneinander unabhaengig und unterschiedlich modifizierte Varianten entstehen; neue Versionen werden von uns erst freigegeben, wenn sie im 'Echtbetrieb' ausfuehrlich getestet wurden. - Wir hoffen, Sie koennen diese Gruende verstehen, zumal sie nicht zuletzt auch der Sicherheit im Netz dienen sollen. - Im Uebrigen koennen Sie anhand der 'History' (in 'BiPoint.NEW') sehen, dass wir bemueht sind, auf Anregungen moeglichst schnell zu reagieren. _________________________________ <:-) ___________________________________ Credits: -------- BiModem v1.24 ------------- Copyright (C) 1989 by ERIK LABS Erik Labs, 3431 W. Thunderbird Rd., Suite 13-311, Phoenix, AZ 85023 (602)942-5403 Voice, (602) 866 9229 Data (2400) _________________________________________________________________________ FV v1.33 - Verbose Archive Directory Lister ------------------------------------------- (c) Copyright by Vernon D. Buerg 1989-90. ALL RIGHTS RESERVED. _________________________________________________________________________ LIST v7.5b ---------- Copyright (C) 1983-1990 by Vernon D. Buerg 139 White Oak Circle, Petaluma, CA 94952 Data: (707) 778-8944 VOR 24-hour bulletin board - or - (707) 778-8841 MB 24-hour bulletin board Compuserve: 70007,1212 _________________________________________________________________________ MsgPrep v1.30 ------------- Copyright (C) Marc Zimmermann, 1989-1990. Marc Zimmermann, Hochstrasse 167, 6600 Saarbruecken 5, Tel.: 0681-791993 _________________________________________________________________________ 'maps v1.13 ----------- (c) 1990 brian o'fish, muli lab's Patrick Schaaf, Alter Stadtweg 69, D-6607 Dudweiler/Saar, Tel.: 06897 763816 _________________________________________________________________________ Telix v3.12 ----------- Copyright (C) 1986 - 1989 by Exis Inc. EXIS Inc., Post Office Box 130, West Hill, ON, Canada M1E 4R4 (416)-289-4641 voice, (416)-289-4645 FAX, (416)-439-8293 BBS _________________________________________________________________________ Zerberus(r) ----------- Copyright (C) 1987 - 1990 by H.Schroeder & W.Mexner _________________________________________________________________________ Einen herzlichen Dank an Udo Schacht-Wiegand (SYSOP@OLN.ZER) fuer seine Geduld und Unterstuetzung bei der Entwicklung und dem Testen der Software. _________________________________________________________________________ BiPoint v3.47 _____________ Copyright (C) 1989, 90 DFG/M.Watermann, D-3000 Hannover 1 Hinweise & Anregungen sind immer willkommen. Sie koennen Ihre Mitteilungen richten an (e-mail:) Zerberus : M.WATERMANN@OLN.ZER FidoNet : Matthias Watermann of 2:247/205.9751 (snail-mail:) Die Freie Gesellschaft Verlagsbuchhandlung M. Watermann Richard-Wagner-Str. 27, D-3000 Hannover 1 _________________________________________________________________