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.
Copyright © by Christian Goßlar
Letzte Aktualisierung am 6. November 1997