Hier geht es rund um das MausNet, Aufrufparameter, Zeiten usw.
ohne Parameter | Nächtliches MausNet |
/1 | Der erste Teil des nächtlichen MausNet. Danach kann man, wenn genug Zeit bis zum Anruf von oben ist, z.B. den Mausputz, das Backup etc laufen lassen. |
/2 | Zweite Teil des MausNet. Warten auf den Anruf von oben und ruft danach die Boxen unter einem an. |
/c | Verbindungsübernahme von der MAUS, wenn das MausNet der anrufenden Box auf der eigenen MAUS landet, z.B. bei einem manuellen Netz mit mausnet /m. Ist defaultmäßig in der Maus auf Event70 definiert. Sollte also auch so in MAUS.BAT drin stehen. |
/e | Erwarte einen Anruf |
/e:HB | Erwarte Anruf aus HB (packt nur für HB) |
/m | Mache Anruf nach oben |
/p:2 | Es wird nur auf den angegebenen Port gehört |
AC | Mache Anruf bei MAUS AC |
Export? | Erlaubt die Eingabe, ab welcher Msg-ID die lokalen! Allg-/Pers-Msgs exportiert werden sollen. Sinn z.B.: mnac-hb-.* kaputtgegangen; jetzt noch einmal ab gestern exportieren. Bitte VORSICHT! Es wird auf eine Tastatureingabe gewartet. Also nicht per Batch aufrufen. |
K2,MS | Mache Anruf bei K2 und MS (Anruffolge nach Maus-Nr) |
Zusatzparameter (immer als 2./3. Parameter nach /e oder K2):
.. /x | Nicht exportieren MausNet |
.. /t:21:00 | TimeOut um 21:00 (Default jetzt +30 Min.) Beispiel: MausNet HB /t:20:13 MausNet AC3 /x /t:20:20 MausNet K2,MS /x /t:20:38 |
Bei MausNet /1 oder /2 werden keine weiteren Parameter ausgewertet.
ACHTUNG Der ProgFix kommt nicht oder nur schlecht mit langen Gruppennamen zurecht. Es können diverse Fehler auftreten (von garkeiner Aktion bis zum kompletten löschen der Maus!!! Besser ist es JAZZ von Fritz zu benutzen.
ProgFix-Parameter:
P | persönlichen Programmteil selektieren Default: aus |
O | öffentlichen Programmteil selektieren Default: aus |
G | alle Gruppenprogrammteile selektieren Default: aus |
? | ausführliche Hilfe |
U | UserdatenCheck |
C | Sicherheitscheck und Statusmeldungen am Anfang Default: aus |
X | CD-Gruppenprogrammteil selektieren (wenn vorhanden) Default: an |
R | Renumber (Gelöschte Files aus Liste löschen) Default: aus |
S | Resort (Beschreibungen bearbeiten) Default: an |
F | Filetest (Filedaten überprüfen/anpassen) Default: an |
K | Filekill (überflüssige Files entsorgen) Default: an |
A | Archivcheck (überprüft alle veränderten und neuen) Default: aus |
Z | Zuordnung der Uploader neu |
D | DupeCheck ö <-> ö, ö <-> Gruppen |
+ | Einschalten oder |
- | Ausschalten ohne (+/-) = Toggeln Also z.B.: /QTOSFK ist das gleiche wie /Q+T+O+S-F-K- |
Das CNF enthält die Daten, die das MausNet über eine Box wissen muß. Das Format ist an das Infofile ITB angelehnt.
Beschreibung der Zeilen:
; | Ein Kommentar ; CNF der AC4 |
* | Dem Stern folgt das Boxkürzel. Diese Zeile muß die erste Zeile im .CNF sein, die kein Kommentar ist! *AC4 Diese Zeile tritt genau ein mal auf. |
# | Die Netznummer der Box (dezimal). Eine Fremdbox bekommt ein - vorangestellt (der Nummer, nicht etwa dem Doppelkreuz). Beispiel, MAUS: #112 Beispiel, Fremdbox: #-22 Diese Zeile tritt genau ein mal auf. |
N | Der Name der Box, maximal 30 Zeichen lang. Beispiel: NQUARK Duisburg 3 NQUARK Köln 6 Diese Zeile tritt genau ein mal auf. |
T |
|
t | Telefonnummer der Box im internationalen Format. Fehlt diese Zeile, so soll die Box während des Netzes nicht angerufen werden (Fremdboxen werden sowieso nicht angerufen). Ist das t klein geschrieben, ist die Telefonnummer geheim und nicht zur Weitegabe an die User bestimmt. T+49-30-1181 Diese Zeile kann mehrfach auftreten (Multiportbox). |
- | Das Kürzel der Serverbox. Entfällt, wenn die Box keine Serverbox hat. Diese Zeile tritt maximal einmal auf. -AC4 |
D |
|
Z | Primäre und zusätzliche Domains der Box. D tritt genau null oder einmal auf, Z kann mehrfach auftreten. Die primäre Domain ist die Domain, unter der Nachrichten aus der Box exportiert werden, sekundäre Domains sind alternative Adressen. Für die Domains gibt es zwei Schreibweisen, einmal die mit Punkt am Anfang (dann muß das Boxkürzel noch vor die Domain gesetzt werden, um einen gültigen Domainpart zu erzeugen), und alternativ kann man auch einen vollständigen Domainpart angeben (das sollte man aber nur tun, wenn sich der gültige Domainpart nicht aus .irgendwas und Boxkürzel zusammensetzen läßt). Beispiel: Dmausdu3.gun.de Z.maus.de Z.maus.sub.org |
G | Hier werden netzweit bekannte Gateways eingetragen. Diese Zeile kann vielfach auftreten. Das Format ist:
kiste_oder_domain gibt an, was über das Gateway zu erreichen ist. Das Format ist wie bei den Domains, siehe oben. Gatenummer ist die Nummer des Gatewayusers in der MAUS (negativ, zwischen -9 und -999 oder ähnlich). Fremdboxen können eintragen, was sie wollen, vorausgesetzt, die Nummer bleibt in dem Zahlenbereich (was passiert, wenn nicht?). (IMO ist diese Information zweckfrei). erlaubt_fuer ist eine mit Kommas getrennt Liste von Boxen und Domains, für die die Benutzung dieses Gates erlaubt ist. Ein * bedeutet, daß die Benutzung des Gates für alle erlaubt ist, ein - bedeutet, die Benutzung des Gates ist generell verboten. Im folgenden Beispiel sind drei Gates angegeben, die Benutzung des ersten ist für alle erlaubt, die des zweiten für Niemanden, und die des dritten für alle Boxen, die Mitglied der Domain .maus.de sind oder DU3 heißen: ; Gates. Format: Name,Nummer,Transport ; Name: .* ist dasselbe wie alle Top-Level-Domains ; Transport: "*"=alle, "-"=keiner, ; oder "MS,.maus.de" = MS und alle .maus.de-Mäuse G.gun.de,-11,* G.rhein.de,-11,- G.de,-12,.maus.de,DU3 |
% | Informationen im PMK2-Format, siehe PMK-Token-Format. Mehrere bis viele Zeilen. Technisch zu behandeln wie s. |
s | Informationen nur für Sysops. Mehrere Zeilen möglich. |
U | Informationen für User (der Text, der z.B. im INL steht). Mehrere Zeilen möglich. |
Ein Beispiel-CNF:
; Boxkürzel - dies muß die erste Angabe sein: *DU3 ; Netznummer (Fremdbox mit "-" davor): #-110 ; Boxname [max. 30]: NQUARK Duisburg 3 ; Telefonnummer (Muster: +49-251-77262; fehlt=nicht anrufen): T+49-203-735844 ; Kürzel der Serverbox (fehlt für Baumwurzel): -DU ; Primäre (D) und sekundäre (Z) Domains: Dmausdu3.gun.de Z.maus.de Z.maus.sub.org ; Gates. Format: Name,Nummer,Transport ; Name: .* ist dasselbe wie alle Top-Level-Domains ; Transport: "*"=alle, "-"=keiner, ; oder "MS,.maus.de" = MS und alle .maus.de-Mäuse G.gun.de,-4711,.maus.de ; SysOp-Infos: %B1 Uwe Ohse %a1 Straße Nr, PLZ Stadt, Land (Germany) %t1 Telefonnummer des Betreibers %E1 uwe@tirka.gun.de, uwe_ohse@du3.maus.de %S2 weiterer Sysop %S3 und noch ein Sysop %m1 ZyXEL-16K8 V.32bis V.32 V.22bis V.22 V.21 %f1 V42.bis %u1N Usenet %u1B Uwe Ohse %u1E uwe@tirka.gun.de %u1M uwe@tirka.gun.de %u1R das ist ein wirklich lokales Gate :-) %N QUARK Duisburg 3 %HW i486/66, 20 MB, 1-2GB %OS Linux %L 51 26 N / 06 45 E city %$ 40 DM sblahblah und wichtige sonstige Informationen. ; User-Infos: U Benutzerinformation, Zeile 1 U Benutzerinformation, Zeile 2
User werden nicht automatisch benachrichtigt, wenn PM-Massen gefiltert und nicht weitergeleitet werden?
Der Hinweis vom MausNet an den Sysop wegen der gefilterten PM-Massen bekommt generell nur der WoSysop der entsprechenden MausBox. Kein anderer wird automatisch informiert. Wenn allerdings später auf dem Transportweg nochmal PM-Massen gefiltert werden, weil sie beim ersten mal durch den MausNet-Check kamen, dann bekommt natürlich auch der entsprechende Sysop eine Mail.
Außerdem gehen gefilterte PM-Massen weiter an den Wochensysop, bekommen aber schon den Gelesen-Status, landen also nicht im Tausch. Der WoSys muß die also nicht saugen.
Im Moment gelten allen PM-Mengen über 64 KB pro User und Tag als PM-Masse. Eingestellt wird dieser Wert im MAUSNET.REQ mit der Variable PMMassenFilter. Mit der Variable PMMassenHinweis kann man auch einstellen, ab wann der Sysop einen Hinweis auf große PM-Mengen bekommen soll.
Dazu mal den Text von Jörg:
Wie bekomme ich ISDN im MausNet ans Laufen?
===========================================
Hinweise zu MausNet V.2.00, 17.08.94, js@ac
1. Installation der Kartentreiber mit CAPI und cFos
ELink-Besitzer können diesen Abschnitt überlesen.
cFos ist ein Interface zwischen Fossil-Treiber und CAPI. Für MAUS und MausNet sieht dann ISDN wie ein Modem aus. Ich gehe im folgenden von einem Modem auf COM1 aus und einem ISDN, daß wir als COM2 einbinden. Ob eine zweite serielle Schnittstelle installiert ist, interessiert nicht.
Installation im AUTOEXEC.BAT nach den kartenspezifischen Treibern mit:
lh \util\cfos i -c1 -jc
i = Installation, -c1 heißt als Fossil-Port 1 (das ist der 2. Fossilport = COM2, da Fossil die Ports von 0 an zählt), -jc macht aus der Scrollock-LED eine ISDN-CARRIER-LED. Man kann mit dem cFos auch eine existierende serielle Schnittstelle "überschreiben". Wichtig ist nur, daß erst der X00 und dann der cFos eingebunden wird.
Sinnvoll kann auch der Zusatzparameter -dd sein, der den cFos ein File CTRACE in seinem Verzeichnis anlegen läßt. Dieses File enthält den gesamten CAPI-Msg-Austausch. Aber Achtung: das File wird locker etliche 100 KB groß und ist nur nach eingehendem Studium von CAPIDOC verständlich. Wenn man also massive Probleme beim Verbindungsaufbau hat, sollte man hier reinschauen.
2. MausNet.CFG:
Dem MausNet muß gesagt werden, daß es 2 Ports unterstützen soll, wo diese liegen, wie das zweite Modem bedient wird, und welche Mäuse über welchen Port angesprochen werden sollen.
Erstmal die Modem-Konfigurationen:
; ; Modem-Parameter ; ModemPorts := 2; ; Modem1.X00Port := 0; Worldblazer Modem1.ComPort := 1 ; Modem2.X00Port := 1; ISDN Modem2.ComPort := 2
Damit sind dem MausNet 2 Modems bekannt, die auch initialisiert werden. Wenn ModemPorts nicht gesetzt ist (Default), dann gelten die alten Config-Vars ModemPort und ComPort weiter. Jetzt geht's an die modemspezifischen Kommandos. Default ist jeweils ModemBla, umkonfiguriert werden kann pro Modem Modem1.Bla und Modem2.Bla.
Modem1.Init1 := 'E0'; Modem2.Init1 := '&D1 S11=2 X1'; Statuszeile an und in Zeile 2 ; Modem1.Auflegen := 'M0 H'; Modem2.Auflegen := 'H0 &L*'; höre wieder auf alle EAZ Modem2.DialPre := 'D' Modem2.Annehmen := '&L A';nicht mehr auf die Leitung hören u. annehmen Modem2.Abheben := '&L' Modem2.Status := 'I2'; protokolliert einen Verbindungsreport ins Log Modem2.Exit := '&L'
Ohne Änderung der Inits (X1) liefert cFos einfach ein 'CONNECT' zurück. Das sollte also auch bei den Connect-Strings gesetzt sein. Und nicht 'CONNECT *' - da kommt kein Blank.
Was soll die &L-Mimik? cFos scheint ein Problem zu haben, wenn ein Anruf auf dem ISDN-Port reinkommt, aber nicht direkt beantwortet wird, da ein Modemanruf anliegt. Hinterher klappt es dann auch nicht mehr. Als Abhilfe scheint sich zu bewähren, nur dann auf ISDN-Anrufe zu hören, wenn sie wirklich angenommen werden können. Sonst wird mit &L dem CAPI gesagt, auf keine EAZ zu horchen. Auf der anderen Seite kommt dann ein NO ANSWER/CAUSE=34ba.
So, und jetzt muß noch gesagt werden, welche MAUS auf welchem Port läuft und welche Nummer sie hat:
Modem.AC := 2
Modem2.Nummer.AC := '9019020'
Default ist also jeweils Modem.XY := 1. Wenn nun eine MAUS ISDN-mäßig erreicht werden soll, dann setzt man diese Config-Var und die ISDN-Telefonnummer! Default für die Nummer ist die Angabe aus dem .EXP. Ein altes, box-spezifisches ModemDialPreAC muß in Modem1.DialPre.AC (mit 2 Punkten!) umgetauft werden. Nur so kann das MausNet, je nach Aufrufparameter entweder mit dem Modem auf Port 1 oder ISDN auf Port 2 anrufen. Kontrolliert das am besten in den ersten Dial-Angaben, die das MausNet in das Log schreibt und im MAUSNET.REQ. Diese Angaben sind sehr fehleranfällig!
Besser als mit X1 kann man mit X7 fahren. Es gibt dann ausführliche Resultcodes vom cFos, die das MausNet auch im Logfile mitprotokolliert. Dazu sollte ein Connect-String CONNECT 64000* definiert werden.
Mit X7 enthalten die NO ANSWER, NO CARRIER und BUSY Responses noch den Zusatz /CAUSE=xxxx, was alles brav im Logfile vermerkt wird. Die genaue Erklärung des Wertes xxxx liefert CFOS.DOC.
DSZ ist nicht Fossil-fähig. Deshalb brauchen wir bei der Lösung mit ISDN-CAPI und cFos ein Protokoll, daß über den Fossil läuft. Ein vernünftiges ZModem gibt es noch nicht, weswegen wir zu HS/Link gewechselt sind. HS/Link hat auch den Riesenvorteil, daß es bidirektionale Übertragung erlaubt. Dieses HS/Link sollte für jeden MausNet-ISDN-Partner im MAUSNET.CFG eingestellt werden. Dies geht über die Variable
Protokoll.AC3 := 'H' im MAUSNET.CFG @ AC und
Protokoll.AC := 'H' im MAUSNET.CFG @ AC3
Default ist hier 'Z' wie ZModem. Man kann in Zukunft auch andere Protokolle definieren. Wichtig ist, daß sie auf beiden Seiten gleich eingestellt sein müssen. Der Buchstabe wird als 5. Parameter dem ZMODEM.BAT übergeben.
3. ZMODEM.BAT:
rem %1 = Port rem %2 = sz/rz/bi rem %3 = Filename rem %4 = Output in Datei (DSZ.OUT im Nachtnet, con im man. Netz) rem %5 = Protokoll-Art (Z, H) rem %6 = Baudrate set DSZLOG=DSZ.LOG if %5==H goto HSLink rem Aus Kompatibilität zu 1.99-ISDN-Versionen noch rem diese Abfrage: if %1==2 goto HSLINK :ZMODEM dsz port %1 handshake cts %2 -m -rr %3 goto Ende :HSLINK set hsl=fhslink rem Wenn auf Modemport, dann besser HSLINK.EXE benutzen rem Im Normalfall sollte das Modem auf rem COM1 sein (bitte ggf. ändern) if %1==1 set hsl=hslink if "%2"=="bi" %hsl% -! -P%1 -E%6 -HX -S2048 %3 if "%2"=="sz" %hsl% -! -P%1 -E%6 -HX -S2048 %3 if "%2"=="rz" %hsl% -! -P%1 -E%6 -HX -S2048 :Ende if errorlevel 1 quit :Ok echo Ok > ZModem.ok
Was bedeutet es, wenn der MNConfig jeden Tag sowas meldet:
Box 101 ÖRK MAUS Örks neu im Netz
(statt Box 101 BÄH MAUS Leipzig/Taucha-1)
Man hat einfach vergessen, das EXP-File einer Maus, die aus dem MausNet ausgeschieden ist, zu löschen. Irgendwann wurde die Maus-Nummer neu vergeben und nun hast man zwei EXP auf der Platte, die beide für eine Maus Nummer 101 gelten sollen. Und so meldet dir der MNCONFIG jeden Tag die andere Maus als neu. Also einfach des EXP-File der ausgeschiedenen Maus BÄH löschen und gut is.
Ja. ZIP.BAT und ZIPX.BAT müssen die heißen, und im Net-Directory liegen. Die Parameter sind bei ZIP: %1=-a, %2=Archiv-Name, %3=Filename, bei ZIPX: %1=-o, %2=Archivname.
Beispiele:
Einfachversion
ZIP.BAT: -------- if "%2"=="F:\MAUS\NET\MNAC-AC3.ZIP" goto PKZIP c:\util\zip %1 %2 %3 goto Ende :PKZIP c:\util\pkzip %1 %2 %3 :Ende
Mit Fehlerabfragen
Einfach einen \NET\ZIP.BAT anlegen. Der wird dann genommen, da MAUSNET nur 'ZIP' exect und \NET\ ja das aktuelle Verzeichnis ist.
Minimalversion
pkzip %1 %2 %3
- Version wenn es mal Probleme beim Packen gibt (mit Test und Log)- @echo off rem 4dos! echo -------- ZIPZAP Logfile %_DATE um %_TIME -------- >>ziperr.txt echo ZIP-File: %2 >>ziperr.txt pk193 %1 %2 %3 zipx -t %2 if errorlevel 1 goto fehler echo Alles klar! >>ziperr.txt goto Ende :fehler rem Packen war nix! Dann halt mit altem ZIP versuchen ... echo Fehler beim ersten Einpacken! >>ziperr.txt dir %2 >>ziperr.txt erase %2 zipalt %1 %2 %3 zipx -t %2 if errorlevel 1 goto garnix echo Zweiter Versuch erfolgreich! >>ziperr.txt goto Ende :garnix erase %2 echo Auch das zweite Einpacken war nix! >>ziperr.txt :Ende
Wenn man für verschiedene Mäuse verschieden packen will
@echo off rem 4DOS! if "%@NAME[%2]"=="MNS3-BB-" goto ZIPNEU if "%@NAME[%2]"=="MNS3-S2-" goto ZIPALT if "%@NAME[%2]"=="MNS3-S--" goto ZIPNEU if "%@NAME[%2]"=="MNS3-BL-" goto ZIPALT :ZIPNEU pk204 %1 %2 %3 goto Ende :ZIPALT zipalt %1 %2 %3 :Ende
Problem. Man will im Nachtnetz, das eine bestimmte Box immer zuerst angerufen wird. Wie geht das?
Dazu gibt es die Variable CallOrder im MausNet.cfg. Dort kann man die optionale Anrufreihenfolge eingetragen.
Beim MausNet tritt folgender Fehler auf:
DOS-Fehler #4 bei 0004:3266 - Zu viele offene Files - I/O Error 4 [4 1
Laut Jörg sollte man schon wenn man 2 Mäuse um sich rum hat Files = 30 in CONFIG.SYS und MaxFiles := 30 in MAUSNET.CFG setzen.
Von: Frithard Meyer-Zu-Uptrup @ S3 (Di, 10.08.93 23:21)
Hi zusammen,
so, seit ein paar Stunden versuche ich hinter die Geheimnisse von NETSTAT zukommen, die Doku die ich habe führt lediglich neue Features auf. Und jeder den ich angerufen habe weiß auch nichts darüber. Ich möchte das aber gerne verstehen, darf ich das?! ;-)
Also: Die erste Ausgabe (In) verstehe ich noch, bei der Zweiten wird es für mich dann schon schwieriger:
Out Ergebnis Gebühren- Box Ok NotOk MAUS Einheiten Recs cps ---------------------------------------------- BB 65 2 0 73 215672 1979 BL 39 1 0 335 164028 1898 S 65 6 0 77 195720 1857 S2 65 1 0 72 220975 1970 WÜ 60 3 0 102 19608 1796 ---------------------------------------------- 59 3 0 659 816003 1927
Was geben denn die drei Spalten 'Ergebnis' an?
Ferner: In Würzburg steht unter IN 156 Einheiten, hier aber unter OUT nur 102,wie kann so eine große Differenz entstehen?
Jau, dann das dritte Ding, bis Recs OUT ist das auch noch klar, aber was istR/E? Und dann alle weiteren Spalten sind mir dann auch nicht so ganz klar, nur daßda irgendwas über den Anteil errechnet wird und dann der jeweiligen MAUS 'gutgeschrieben' wird, also z.B. der BB 2 Einheiten.
Telefonkosten: Box Einheiten Recs Anteil IN Erstattung IN OUT ges. IN OUT gesamt R/E % Einh Einheiten DM ---------------------------------------------------------------------- BB 29+ 73= 102 4583+ 215672= 220255 2159 2.1% 2 73- 2 16.33 BL 35+ 335= 370 941+ 164028= 164969 445 0.6% 2 335- 2 76.59 S 28+ 77= 105 7412+ 195720= 203132 1934 3.6% 4 77- 4 16.79 S2 30+ 72= 102 6049+ 220975= 227024 2225 2.7% 3 72- 3 15.87 WÜ 477+ 102= 579 232780+ 19608= 252388 435 92.2% 534 102- 534 -99.36 ---------------------------------------------------------------------- 599+ 659=1258 251765+ 816003= 1067768 1439 545 659- 545 26.22
So, und wenn ich das dann kapiert habe, dann kann man noch von MSGSTAT die Routingkosten mit reinrechnen, aber das kommt dann in der nächsten Frage- stunde, wenn es wieder heißt: Route mal mit Modemqual!
Salve fritz
PS: Falls ich's kapiere schreib ich dann mal eine Doku und für James hab ich da auch was vor ...
Von: Gereon Steffens @ K2 (Mi, 11.08.93 18:40)
>Was geben denn die drei Spalten 'Ergebnis' an?
OK=Anzahl Anrufe OK, NotOK=Anzahl Anrufe nicht OK, MAUS=Anzahl Anrufe, bei denen statt einem MAUSNET eine MAUS lief.
>In Würzburg steht unter IN 156 Einheiten, hier aber unter OUT
nur 102,
>wie kann so eine große Differenz entstehen?
Manuelle Netze verursachen nur in einer Richtung Kosten.
>aber was ist R/E?
Records pro Einheit.
>dann der jeweiligen MAUS 'gutgeschrieben' wird, also z.B. der BB 2 Einheiten
Genau, und zwar prozentual, abhängig von dem Mail-Aufkommen, das von dieser MAUS geliefert wurde.
>dann kann man noch von MSGSTAT die Routingkosten mit reinrechnen,
Richtig, und zwar Routinanteil-% vom Einheiten-Eigenanteil, also in Deinem Fall von den 545 Einheiten. Das dann durch Anzahl der Boxen unter Dir teilen. Gereon
Von: Jörg Stattaus @ AC (Do, 12.08.93 12:09)
>In Würzburg steht unter IN 156 Einheiten, hier aber unter OUT
nur 102,
>wie kann so eine große Differenz entstehen?
GS>Manuelle Netze verursachen nur in einer Richtung Kosten.
Nein, nein, auch manuelle Netze sollten sauber in den Logfiles beider Partner eingetragen werden. Ich hätte gerne die genaue Aufstellung auch der Gegenseite, wieviele Verbindungen stattgefunden haben, Fritz.
Und wenn die Verbindungszahl gleich ist, muß es mit den Einheiten pro Gespräch zusammenhängen. Da ist einmal die Frage, ob ihr die gleichen Zone und Sekunden/Einheit im netstat.cfg stehen habt. Wenn ja, müßten man die MN-*.LOG vergleichen und die Differenzen pro Tag ermitteln. S3 sagt am 01.07.93 im MN-OUT.LOG 230, WÜ im MN-IN.LOG 245 usw. Eine Differenz von 10 Sekunden ist normal, da der Angerufene vom Abheben und der Anrufer vom Carrier aus zählt. Gruß Jörg
Von: Marcus Schmidke @ BM (Do, 03.04.97 14:36) MId: 199704031436.a47961@bm.maus.de
Hi.
Die Abrechnung ist schon etwas komplizierter.
Netstat geht nur nach der einfachen Regel vor: jeder bezahlt das, was er bekommen hat. Wenn BM jede Nacht 1 MB von K2 bekommt, bezahlt BM an K2 den vollen Preis dafür. Genauer passiert folgendes:
Es wird aufgerechnet, wieviele Daten von BM nach K2 geflossen sind, und wieviele von K2 nach BM geflossen sind. Weiterhin wird berechnet, wieviele Einheiten dafür insgesamt verbraucht wurden, egal, wer die auf seiner Telefonrechnung hat.
Daraus wird berechnet, welchen Anteil dieser Einheiten BM zahlen muß und welchen Anteil von K2, und das wird miteinander verrechnet. Am Ende kommt heraus, daß BM an K2 zahlen muß, weil im allgemeinen deutlich mehr Daten von K2 nach BM fließen als umgekehrt. Von dem Betrag, den BM an K2 zahlen muß, wird jetzt noch der Betrag abgezogen, den BM schon aus eigener Tasche bezahlt hat (es werden also sämtliche Verbindungen, die von BM nach K2 liefen, abgezogen). Daraus kommt ein Betrag, der tatsächlich von BM nach K2 überwiesen wird.
Beispiel (hier aus der Sicht von K2):
Telefonkosten: Box Einheiten KB Anteil In Erstattung In Out ges. In Out gesamt KB/E % Einheiten DM --------------------------------------------------------------------------- BM 32+ 65= 97 7459+ 54381= 61840 638 12.1% 65- 12 6.36
Es gingen im März 7459 KB von BM nach K2 und 54381 KB von K2 nach BM. Dafür wurden in Anrufen von BM nach K2 32 Einheiten, in Anrufen von K2 nach BM 65 Einheiten verbraucht.
Insgesamt wurden 61840 KB übertragen und 97 Einheiten verbraucht, was einen Schnitt von 638 KB pro Einheit ausmacht. 12,1 % der Daten gingen von BM nach K2, also hat K2 auch 12,1 % der 97 Einheiten zu zahlen. Das sind 12 Einheiten. 65 Einheiten hat K2 aber schon mit seiner Telefonrechnung bezahlt, also bekommt K2 von BM eine Erstattung über 53 Einheiten, also 6,36 DM.
In einem zweiten Berechnungsschritt wird ermittelt, wieviele Daten *insgesamt* in BM eingegangen sind, egal, ob aus K2, D, SU oder B. Aufgrund obiger Verrechnung hat BM alle diese Daten ja bezahlt; die Kosten für diese Daten werden als "Eigenanteil" bezeichnet.
Msgstat berechnet, wieviel von den Daten, die insgesamt in BM eingegangen sind, auch wirklich in BM verblieben sind. Viele PMs, aber auch einige Gruppen, hat BM ja nur gesaugt, um sie weiterreichen zu können. Msgstat berechnet nun diesen "Routinganteil": wieviel Prozent der Daten, die BM insgesamt gesaugt hat, konnte BM denn überhaupt gar nicht brauchen?
In BM beläuft sich das konkret auf ca. 20% aller gesaugten Daten. Für die eingegangenen Daten bezahlt BM ca. 12 DM, d.h. 2,40 DM hat BM ausgegeben, ohne selber Verwendung dafür zu haben.
Bis hierhin ist die Abrechnung noch *absolut* korrekt.
Für den recht geringen Betrag von 2,40 DM pro Monat wird jetzt aber kein großes Aufhebens gemacht. Er wird einfach zu gleichen Teilen auf alle unter BM liegenden Boxen aufgeteilt, ohne dabei zu berücksichtigen, welche der Boxen denn nun den größten Anteil an den 2,40 DM hatte.
Das bedeutet letztendlich: jeder innere Knoten des Netzbaums zahlt genau so, als wenn er Blatt wäre, für alle Gruppen, die er bekommt. Wenn also ein innerer Knoten im Ferntarif Daten herankarrt und diese im Nahtarif auf viele Boxen verteilt, sind diese Boxen fein raus, der Server selber aber zahlt den vollen Betrag.
Dieses Ungleichgewicht wird - jedenfalls von der klassischen Kombination NetStat/MsgStat - nicht herausgerechnet. Eine fairere Lösung wäre vermutlich, auch die lokal eingetragenen öffentlichen Mitteilungen zu bewerten und jeweils die Kosten dynamisch auf die Boxen aufzuteilen, die die Mitteilungen erhalten.
Mit den herkömmlichen langfristigen Logfiles ist eine solche Aufteilung jedoch nicht möglich; ich könnte mir aber sehr gut vorstellen, daß James, der sowieso täglich die Netzlogfiles auswerten kann, hier exaktere Möglichkeiten bietet. Hm, nein, da stehen die Größen der Mitteilungen nicht drin. Das geht also auch nicht exakt. Tja, ich weiß es nicht, ob es eine exakte Abrechnungsmöglichkeit gibt.
Tschö, Marcus.
Wenn nach dem entpacken des Netzpaketes immer komische Zeichen in den Mails vorkommen, dann sollte man mal die Smiley-Optionen des PKZIP probieren:
-3+-)(~
In etwas abgewandelter Form benutzt das Michael Keukert in seinem ZIP.BAT
ZIP.BAT
@echo off echo %1 %2 %3 %4 %5 %6 > zip.ech :PKZIP mem > memory.lst M:\util\pkzip -~)!+3 -- %1 %2 %3 %4 %5 %6 M:\util\pkunzip -t %2 if errorlevel 1 goto ZIP quit :ZIP M:\util\zip %1 %2 %3 %4 %5 %6 quit
Die Bedeutung der Optionen:
-3 | Disable 32-bit instruction usage on 80386 or higher CPU's |
-^ | Echo the command line |
-+ | Disable Expanded Memory (EMS) usage |
- | Disable UMB/HMA Memory (XMS) usage |
-~ | Disable Network usage |
-) | Disable 32 bit DPMI usage |
-( | Use "Slow" MemCopy |
MNConfig /X
Darf nur einmal am Tag, und zwar nach dem Nachtnetz aufgerufen werden.
MNConfig ohne Parameter
Sollte nach jeder Änderung am *.CNF der eigenen Maus aufgerufen werden. Auch wenn man das Remote macht (dazu einen Event vorsehen). Anschließend sollte auch im MAUSNET.LOG nachgeschaut werden, ob alles korrekt ablief. Nicht immer werden Fehler in Mails an den Sysop gemeldet.
Wenn WriteSuccessMsg gesetzt ist, dann bekommt der Sysop auch immer eine Mail, wenn der MNConfig mit /X aufgerufen wird.
Was bedeutet folgende Meldung bei MausNet 2.54:
03:01:32>MSG-ALLG.PAR wird mit MSG-ALLG.NET verglichen.
03:01:45>A14351@BM regelmäßiger Versand -> Dupe ->
GetHeap
(0a41:1b05): 544, frei: 6328 6328(bis einschließlich "->
Dupe"
MS>GetHeap (0a41:1b05): 544, frei: 6328 6328
Eine einfache Ausgabe, daß 544 Bytes auf dem Heap angefordert wurden und dann liegen Mem- und MaxAvail bei 6328. Ist also etwas knapp in deiner Kiste.
04:07 P123456@xy -> WO nicht angekommen(?) seit 113 Stunden.
04:07 P123457@xy -> WO nicht angekommen(?) seit 88 Stunden.
Das Mausnet überwacht die Statusmeldungen der PMs. Mit den beiden Variablen PMVerlustMin und PMVerlustMax kann man einstellen, ab wann und wie lange die Meldung kommen soll.
Die Meldung bedeutet aber nicht, das die Mails nicht angekommen sind. Es kann auch die Statusmeldung verloren gegangen sein (ist fast immer der Fall). Diese Warnung bekommt immer nur der WoSysop (mit der MausNet- Meldung). Mithilfe von James kann man auch so eine Mail generieren lassen:
169h: P65428@B Von: Christian Goßlar @ B 1 PM wird von MAUSNET als nicht angekommen gemeldet.
die man in eine lokale öffentliche Gruppe posten kann. Damit sind die User dann informiert und können entsprechend reagieren.
Wie kommt so eine Meldung in der Maus A zustande (James-Posting)
107h: P30700@TBB Von: XXXX XXXX @ B an: XXXX XXXX @ HB2
107h: P30701@TBB Von: XXXX XXXX @ KR an: XXXX XXXX @ HB2
Diese Meldung wird durch das weiterleiten von PMs erzeugt. Dabei bleibt der Originalabsender erhalten
Von: Boris Meltzow @ AC2 (Do, 18.01.96 20:15)
Hi !
Seit Tagen bekomme ich ich folgenden Meldung vom Netz mit der Maus AC: ==================================================================== 14:03 MausNet Version 2.51/dpmi/debug mit Parameter "/C" gestartet 14:03 Daten <- MAUS AC : 00:11 min, 2.0 KB, 816 cps. 14:03 Daten -> MAUS AC : 0.3 KB, 816 cps. 14:03 Daten <> MAUS AC : 2.3 KB, 917 cps. 14:03 PM an KOPERNIKUS@IUS.gun.de-ac2: zurückgeroutet. 14:03 PM an RENEGADE@newswire.gun.de-ac2: zurückgeroutet. 14:03 PM an Geist@nature.gun.de-ac2: zurückgeroutet. =====================================================================
Offensichtlich werden diese drei Mails hin und her geroutet. Wie kann das?
.....Und Tschüß
Von: Gereon Steffens @ K2 (Sa, 20.01.96 14:40)
>Offensichtlich werden diese drei Mails hin und her geroutet. Wie
>kann das?
Bekannter Bug, korrekt.
Abhilfen gibt's zwei: entweder die Netz-.PAR-Files patchen, oder aber einfacheinen Gate für .gun.de einrichten, der für die MAUS, aus der diese Mails stammen,erlaubt ist (vermutlich MAUS K, ich hatte hier dieselben Empfänger).
Gereon
Von: Jörg Stattaus @ W2 (So, 21.01.96 09:50)
CG>Und was ist dagegen zu tun? Irgendwie die Mails entsorgen, nur
CG>wie? Wo muß was gepatch werden?
Das PAR-File besteht aus 48-Byte-Records. Das erste Byte ist ein 'P' für PM. Daspatcht du auf 'X' und das nächste MausNet, daß diese Msg importieren soll, tritt sie in die Tonne.
Gruß Jörg
Von: Gereon Steffens @ K2 (So, 21.01.96 19:57)
>Das erste Byte ist ein 'P' für PM. Das patcht du auf 'X'
Man sollte noch dabeisagen, daß in den drei Byte danach die ID der Msg binärsteht, zuerst ein (Intel!) Word mit der numerischen ID, dann ein Byte mit derNummer der Absender-Box.
Gereon
Von: Frithard Meyer-Zu-Uptrup @ S4 (Mo, 22.01.96 11:54)
Ihr könnt auch einfacher ein Netz von hand fahren. Danach liegt dann auf dereinen Seite wieder ein PAR/DAT für die andere MAUS da - das sind die zurück gerouteten Teile. Nochmal mit mausnet.log vergleichen und dann die beiden Teile löschen. Geht auch evtl nach dem Nachtnetz, dann aber auf jeden Fall immausnet.log nachsehen, ob nicht Mails von einer anderen MAUS kamen, die auch in diesem DAT/PAR sind.
fritz
Nachtrag von mir. Am einfachsten ist es, z.B. dirket nach dem Abendnetz nochmal ein MAUSNET /export aufzurufen. Dann sollte nur diese zurückgeroutet Mail im Netzpaket stehen. Und dann mit dem Hexeditor einfach die Mail wegpatchen.
Von Jörg Stattaus
Vorhaben: Maus OLD soll Maus NEU werden.
Bei einer Maus wird im alten CNF der Name geändert. Im OLD.CNF trägt man also *NEU ein. Der mnconfig /x nach dem nächsten Nachtnetz führt dann überall Zeitgleich die Umbenennung durch. Theoretisch sollte das auch bei Quarks so gehen, aber das habe ich nicht getestet.
Das ist nur für Doppelmäuse interessant, die per Netz miteinander verbunden sind und normalerweise immer ein lokales Netz zu bestimmten Zeiten fahren. Alle anderen sollen unbedingt die Finger davon lassen. Wenn so eine Doppelmaus auch einmal am Tag ein MausNet /1 auslösen will, aber nicht auf die Mausnetzzeiten warten will, ändert man einfach in dieser Maus die entsprechenden Zeiten. Hier mal der Netzplan, wie er im Moment vom Maunetz vorgegeben wird: In jeder Zeile steht pro Ebene AnfangSenden, EndeVonUnten, EndeNachOben, EndeVonOben und EndeNachUnten.
1 03:37 04:18 2 03:15 03:28 03:36 04:20 04:33 3 03:13 03:19 03:27 04:35 04:46 4 03:09 03:15 03:18 04:48 04:58 5 03:05 03:14 05:00
Eine Ebene-3-MAUS hat also Defaultmäßig diese Zeiten:
AnfangSenden := '03:13' EndeVonUnten := '03:19' EndeNachOben := '03:27' EndeVonOben := '04:35' EndeNachUnten := '04:46'
Die geänderten Werte sind in das MausNet.cfg einzutragen.
Das bedeute, daß das MausNet der Box Nachrichten für eine Gruppen mitgeschickt hat, die in der lokalen Box nicht vorhanden ist. Das kann eigentlich nur drei Ursachen haben, es ist aber meistens immer nur Punkt 1
Lokal wurde eine Gruppe entnetzt und auch gleich gelöscht. Nur woher soll das MausNet das wissen. Das MausNet schickt also bis zum nächsten normalen MNConfig-Lauf immernoch Mails für diese Gruppe mit. Siehe auch den Punkt zum MNConfig
Dein MAUSGRP.DAT ist defekt und deshalb wird dem MausNet mitgeteilt, das lokal die Gruppe xy existiert, obwohl sie nicht vorhanden ist.
Das MAUSGRP.DAT in deiner Serverbox ist defekt und denkt, das du die Gruppe xy hast, obwohl sie nicht vorhanden ist
Von: Jörg Stattaus @ AC (Mi, 02.06.93 12:44)
So sollte man vorgehen, wenn man die Vernetzung ändern will.
Natürlich alles mit den Beteiligten absprechen.
am Vortag das CNF ändern und mnconfig starten, aber _OHNE_ /x.
das Nachtnetz mit der alten Box abwarten, danach läuft ja netzweit mnconfig/x und die Vernetzung wird geändert.
MAUSNET.CFG (UseZip, UseZModem, ggf. ModemDialPre) anpassen
Ggf. MAUS.BAT wegen Abendnetz modifzieren
Auch eine Vertauschung der Reihenfolge von 2 Boxen geht auf diese Weise.
Aber: wenn das Nachtnetz nicht läuft, muß man von Hand nachbessern, sprich die EXPs entsprechend ändern und mnconfig /x aufrufen. Aber NUR dann.
Gruß Jörg
Einfach das EXP-File der eigenen Maus verändern oder auf das aktuelle Datum setzen (per touch). Dann schickt das MausNet das automatisch rum. D.h. wenn man bei einem Crash alle EXP-Files verliert, würde es sehr lange dauern, bis wieder alle bei einem vorhanden sind. Deshalb sollte man die EXPs bei der täglichen Datensicherung brav mit sichern. Wenn ein neues EXP verteilt wird, reicht das MausNet immer das original aus dem Netzpaket weiter und nicht etwa die Kopie von der lokalen Platte.
Änderungen nur vornehmen, wenn man weiß was man tut. Fehler können unter Umständen bedeuten, das die Maus im Netz nicht mehr bekannt ist
Vorher nachgucken, was die entsprechenden Parameter bedeuten.
Überlegen, was man in die u Zeilen einträgt. Die sind nach dem nächsten Nachtnetz für alle zu lesen!
Die Änderungen unbedingt mit einem DOS-Editor machen. Besonders bei Mäusen mit Umlauten im Kürzel ist das sehr wichtig
Nach jeder Änderung unbedingt den MNConfig ohne Parameter aufrufen und sich das Ergebnis im MausNet.LOG angucken.
Erstmal wollen wir hoffen, das dieser Fall nur sehr selten eintritt. Höchstens für temporäre Mäuse ist das ganze interessant.
Was sollte man also tun, wenn die Maus wieder aus dem Netz verschwinden soll?
Das ganze in Sysop.Info schreiben
unbedingt das CNF-File der entsprechenden Maus so ändern, das jeder sofort sehen kann, daß das EXP-File gelöscht werden kann. Am besten noch mit Datum, ab wann das geschehen soll. Wieso das ganze? Weil die Maus im Moment noch nicht alte EXP-Files löscht. Wenn jetzt die Mausnummer neu vergeben wird, bekommt man Probleme, wenn das alte EXP noch auf der Platte rumgammelt. Jeden Tag meldet der MNCONFIG mir eine neue Maus?
Copyright © by Christian Goßlar
Letzte Aktualisierung am 6. November 1997