[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Archie: Unis schalten gemeinnuetzige Dienste ab





PILCH Hartmut wrote:

> > Vom Effizienz-Standpunkt her ist es besser, dass nur die Endpunkte
> > einer Kommunikation im Billing involviert sind, statt das Billing auf
> > jeden Hop auszuweiten. Es müssen sich nur die Endpunkte auf einen
> > (effizienten) Zahl-Modus einigen. Der wurde bislang nicht gefunden.
> > Oder gibt es einen, der unmittelbare und mittelbare Anonymität des
> > Geldgebers, Durchführbarkeit (incl. Authentifizierung und Durchsetzung
> > der Zahlung), Dezentralität, Unabhängigkeit und Effizienz aufweisen
> > kann?
>
> Vielleicht die Moeglichkeit, verschiedene Arten von Operationen zu
> unterscheiden.  Etwa get und put.  D.h. fuer das Senden von Mail zahlt der
> Absender, fuer das Saugen/Abrufen von Daten der Sauger.  Das kann immer
> der jeweils naechste Knoten sein.

Das läuft leider nur auf einer zu hohen Ebene, nämlich der der
Anwendungsprotokolle. Diese ändern sich ständig. Bleibt nur noch die Ebene
darunter, TCP und UDP. UDP ist stateless, es ist also nicht klar, wer die
ganzen Aktionen "initiiert", außer vielleicht der Absender des Paketes, der
muss aber nicht der Initiator sein. Bei TCP kann es ähnlich sein. Der, der
eine TCP-Verbindung aufbaut, muss nicht der sein, der die ganze Aktion
initiiert.

Beispiel FTP: Die Daten-Verbindung beim Download (im Active-Modus) wird
gewöhnlich vom Server aus aufgebaut, Initiator ist aber der Client. Mit einem
geschickten FTP-Client ist es sogar möglich, dass der User am Rechner A
Transfers zwischen den Rechnern B und C initiert. Wie soll da ein Router
zwischen B und C wissen, dass A der Initiator der Aktion ist?

Damit ist auch dieses Prinzip (ohne kryptographischen Overhead und dem Umbau
aller TCP/IP-Protokolle) nicht verfolgbar. Wenn wir also nicht nach dem
Initiator einer Aktion gehen könnten (auch wenn dies wünschenswert wäre), dann
können wir nur nach Absender und Empfänger von Daten gehen. Da hat sich zum
Standard entwickelt, dass der Traffic weder nur nach Sender noch nur nach
Empfänger, sondern nach der Summe aus beidem oder dem höheren Wert aus beiden
berechnet. Ein "nur Sender"-Standard würde die FTP-Server übermäßig belasten,
ein "nur Empfänger"-Standard wäre zwar für Suchmaschinen und Mail-Server ganz
schön viel (und würde Spammer bevorzugen), wäre im Endeffekt aber der
Gerechtigkeit eher angepasst, denn wer am meisten empfängt, nutzt auch am
meisten.

Nur ist diese Rechnung ohne den Wirt (Backbone-Betreiber), für den
Backbone-Betreiber ist es nämlich egal, ob nun eher der Sender oder eher der
Empfänger belastet wird, das Paket ist auf dem Backbone und erzeugt somit
Belastung und Nutzung. Es ist zumindest solange egal, bis der Empfänger meint
"das wollte ich garnicht". Bei solch einer Tendenz würde dann eher Senden
belastet, und nicht wie gewünscht Empfangen. (Denn der Sender kann
entscheiden, ob er sendet, der Empfänger kann nicht entscheiden, ob er
empfängt.)

Tja...

Xuân.

>
>
> -phm