Fallacies of Distributed Computing

---

Die Fallacies of Distributed Computing (englisch für Irrtümer der verteilten Datenverarbeitung) sind eine Sammlung eigentlich trivialer, aber doch häufiger fehlerhafter Annahmen, die Programmierer voraussetzen, wenn sie insbesondere das erste Mal eine verteilte Anwendung entwickeln. Die (heute) acht Trugschlüsse werden zitiert als:

1. Das Netzwerk ist ausfallsicher.
2. Die Latenzzeit ist gleich null.
3. Der Datendurchsatz ist unbegrenzt.
4. Das Netzwerk ist sicher.
5. Die Netzwerktopologie wird sich nicht ändern.
6. Es gibt immer nur einen Netzwerkadministrator.
7. Die Kosten des Datentransports können mit null angesetzt werden.
8. Das Netzwerk ist homogen.

Alle der obigen Annahmen sind falsch.

Erklärungen

Das Netzwerk ist ausfallsicher

Obwohl die Netzwerkinfrastruktur-Hardware heute sehr zuverlässig ist und Router und Switches nur selten ausfallen, gibt es dennoch keine Garantie dafür. Auch die Stromversorgung kann unerwartet und im dümmsten Moment abbrechen. Netzwerkprotokolle müssen also so gebaut werden, dass sie mit verlorenen oder verzögerten Packeten umgehen können. Nötigenfalls ist Transaktionsmanagement erforderlich, um bei der Unterbrechung einer Kommunikation keine undefinierten Zustände zu hinterlassen.

Die Latenzzeit ist gleich null

Als Latenzzeit bezeichnet man in einem Netzwerk die Zeit, die ein Datenpaket braucht, um von A nach B zu gelangen. Sie ist niemals null, und im Gegensatz zur Bandbreite (siehe nächsten Abschnitt) kann sie auch nicht beliebig verkleinert werden, da sie physisch durch die Lichtgeschwindigkeit begrenzt ist: Die Round Trip Time von Europa nach Amerika wird immer mindestens 30ms betragen. Eine kurze Latenzzeit ist bei Echtzeit-Anwendungen wie Onlinespielen wichtiger als eine große Bandbreite.

Der Datendurchsatz ist unbegrenzt

Obwohl der Datendurchsatz (auch Bandbreite genannt) in den letzten Jahren deutlich zunahm, ist er immer gegen oben begrenzt. Zusammen mit der Zunahme der Bandbreite steigt jedoch auch das Datenaufkommen kontinuierlich. Wird eine Software nur im lokalen Netzwerk getestet, wo die Latenz typischerweise sehr klein und die Bandbreite sehr hoch sind, können später beim Einsatz dieser Software im Internet unerwartete Probleme auftreten. Da die Paketverlustrate bei weiten Verbindungen zunimmt, wird die Bandbreite nach oben begrenzt, da Paketwiederhohlungen teuer sind. Man kann versuchen, die Paketgrösse zu erhöhen, um den Durchsatz weiter zu steigern, aber größere Pakete gehen mit einer höheren Wahrscheinlichkeit verloren.

Das Netzwerk ist sicher

Die Annahme, dass es keine Hacker gibt, und sämtliche Rechner und Anwender im Netzwerk vertrauenswürdig sind, wird heute kaum mehr jemand machen. Als diese falsche Annahme 1991 erstmals niedergeschrieben wurde, war das Internet allerdings noch sehr jung und nur in universitären Einrichtungen wirklich verbreitet.

Obwohl heute jeder Informatiker weiss, dass böswillige Personen versuchen, in Netzwerke einzudringen und Daten zu stehlen oder zu manipulieren, werden immer noch viel zu oft viel zu schwerwiegende Sicherheitsmängel in Software entdeckt. Zudem gehen gerade Firmen oft davon aus, dass Angreifer von aussen, also über das Internet, kommen müssten, um Schaden zu verursachen. Tatsächlich sind Firewalls heute ziemlich sicher, aber durch Phishing oder „verlorene“ USB-Sticks (siehe Rubber Ducky) können Angriffe auch aus der Firma heraus gestartet werden.

Die Netzwerktopologie wird sich nicht ändern

Die Annahme, das sich Server nicht ändern werden oder gar ändern müssen, ist Unsinn. Wenn eine Applikation erfolgreich ist, wird sie bald skalierbar sein müssen und es werden Server hinzugefügt, ersetzt oder geografisch verschoben. Dasselbe gilt in einem noch viel höheren Masse für die Clients, denn die Benutzer werden ständig neue und andere Rechner einsetzen. Die Applikation sollte also keine Annahme über die Netzwerktopologie machen, also beispielsweise Rechneradressen via DNS auflösen statt feste IP-Adressen zu verwenden.

Es gibt immer nur einen Netzwerkadministrator

Das mag für kleine Teams gelten, ist aber in großen Firmen oder bei firmenübergreifenden Projekten sicher nicht zutreffend. Die Annahme, dass ein Administrator (oder ein Team von Administratoren) auf alle involvierten Systeme uneingeschränkten Zugriff hat, ist dann nicht mehr realistisch und auch aus Sicherheitsgründen nicht wünschenswert. Jede Firma möchte aus nachvollziehbaren Gründen anderen nur soviele Rechte einräumen, wie diese unbedingt benötigen. Selbst innerhalb einer größeren Firma darf kein einzelner Benutzer auf alle Resourcen zugreifen.

Die Administratoren, die das produktive System am Laufen halten sollten, sind auch nicht unbedingt die Entwickler des Systems, so dass sie zwar Zugriff auf Diagnosedaten haben, aber diese erst mit dem Entwicklungsteam diskutieren müssen, falls unerwartete Effekte auftreten.

Entwicklung

Die Liste der Fallacies of Distributed Computing kommt ursprünglich von Sun Microsystems und wurde dort von Bill Joy und Tom Lyon mit vier Trugschlüssen eröffnet. Weite Bekanntheit erlangten sie 1994 durch L Peter Deutsch, der sie erweitert auf sieben Trugschlüsse als "The Seven Fallacies of Distributed Computing" veröffentlichte. James Gosling, ebenfalls von Sun, setzte ungefähr 1997 noch den achten Punkt dazu.

Vergleichbare Listen

Es gibt weitere Bereiche, in denen auch erfahrene Programmierer immer wieder dieselben Fehler gemacht haben. Ein berühmtes Beispiel sind falsche Annahmen über die Zeit, beziehungsweise über deren absolute Gültigkeit und Eindeutigkeit. Alle der dort angegebenen Annahmen – die jeder intuitiv als logisch erachten würde – sind unter gewissen Bedingungen falsch und können daher zu undefiniertem Verhalten von Software führen.

Quellen

• Arnon Rotem-Gal-Oz: Fallacies of Distributed Computing Explained (PDF; 254 kB)
• Moderne Erklärung der Irrtümer, Juni 2022, (englisch)