Commit (Netzwerk)

Kurz: Die Bestätigung, dass übertragene Daten tatsächlich erfolgreich beim Empfänger angekommen und dort dauerhaft übernommen wurden — nicht zu verwechseln mit einem Git-Commit.

Genauer: In Übertragungsprotokollen reicht das reine Senden von Daten oft nicht aus, um Datenverlust auszuschließen — erst eine explizite Bestätigung (“Commit”) des Empfängers stellt sicher, dass die Daten vollständig und unverändert angekommen sind, bevor der Sender sie z. B. aus einem Zwischenspeicher löscht. Dieses Prinzip taucht in vielen Protokollen wieder auf, etwa als Teil von Zwei-Phasen-Commit-Verfahren in verteilten Systemen oder als Bestätigungsschritt in zuverlässigen Übertragungsprotokollen.

Im Detail

Das Grundproblem: Unsicherheit über den Netzwerk-Zustand

Ein Sender weiß von sich aus nie sicher, ob ein gesendetes Paket wirklich angekommen ist — das Netz kann Pakete verlieren, verdoppeln oder in falscher Reihenfolge zustellen, und selbst eine ausbleibende Antwort beweist nicht zwingend, dass die ursprüngliche Nachricht nie ankam (vielleicht ging nur die Bestätigung selbst verloren). Ein “Commit” ist die explizite Gegenbestätigung des Empfängers, die dieses grundlegende Unsicherheitsproblem verteilter Systeme auflöst: Erst wenn sie eintrifft, darf der Sender mit hoher Sicherheit annehmen, dass die Übertragung erfolgreich war, und z. B. seinen Sendepuffer freigeben oder die nächste Aktion einleiten.

ACK als einfachste Form eines Commits

Bei TCP übernimmt das ACK-Flag genau diese Rolle auf Paketebene — jedes empfangene Segment wird mit einer fortlaufenden Bestätigungsnummer quittiert, sodass der Sender genau weiß, bis zu welchem Byte die Übertragung als gesichert gilt. Dieses Prinzip ist die einfachste Form eines “Commits”: eine einzelne, binäre Bestätigung zwischen genau zwei Parteien.

Zwei-Phasen-Commit in verteilten Systemen

In verteilten Datenbanksystemen geht das Konzept einen entscheidenden Schritt weiter, weil dort nicht nur zwei, sondern potenziell viele Knoten gleichzeitig konsistent bleiben müssen. Beim Zwei-Phasen-Commit (2PC) fragt ein Koordinator zunächst ALLE beteiligten Knoten, ob sie eine Transaktion committen können (“Prepare”-Phase — jeder Knoten prüft z. B., ob genug Speicherplatz frei ist oder ob ein Constraint verletzt würde, und antwortet mit Ja oder Nein), und erst wenn WIRKLICH ALLE zustimmen, gibt der Koordinator in der zweiten Phase das eigentliche “Commit” frei. Meldet auch nur ein einziger Knoten ein Problem, wird stattdessen ein globales Rollback ausgelöst — die Transaktion wird komplett verworfen, statt sie nur teilweise durchzuführen. Ohne dieses zweistufige Verfahren könnte ein Netzwerkausfall mitten in der Übertragung dazu führen, dass ein Teil der Systeme die Änderung übernimmt und ein anderer nicht — ein inkonsistenter Zustand, den 2PC gezielt verhindert.

Schwachstellen von 2PC

2PC hat allerdings einen bekannten Schwachpunkt: Fällt der Koordinator selbst genau zwischen Prepare- und Commit-Phase aus, bleiben alle beteiligten Knoten in einem unklaren Wartezustand (“Blocking Problem”) — sie haben zwar zugesagt, wissen aber nicht, ob sie tatsächlich committen oder zurückrollen sollen, bis der Koordinator wieder erreichbar ist. Weiterentwickelte Verfahren wie Drei-Phasen-Commit (3PC) oder moderne Konsens-Algorithmen wie Raft und Paxos, die z. B. in verteilten Datenbanken und Konfigurationsdiensten eingesetzt werden, adressieren genau dieses Problem, indem sie robuster gegen den Ausfall einzelner Koordinator-Knoten sind.

Abgrenzung zu Git

Wichtig für die Begriffsklarheit: Ein Git-Commit hat mit diesem Netzwerkkonzept nichts zu tun, außer dem gemeinsamen Wortstamm (“etwas verbindlich festlegen”) — dort bezeichnet Commit das dauerhafte Speichern eines Änderungssatzes in der lokalen Versionshistorie, ganz ohne Netzwerkkommunikation oder Bestätigung durch eine Gegenstelle.

Siehe auch: ACK, Übertragung, TCP