EMZETT.Commit (Networking)
In short: The confirmation that transmitted data actually arrived successfully at the recipient and was permanently accepted there — not to be confused with a Git commit.
In more detail: In transmission protocols, merely sending data is often not enough to rule out data loss — only an explicit confirmation (“commit”) from the recipient ensures that the data arrived complete and unchanged before the sender, for example, deletes it from a buffer. This principle recurs in many protocols, for example as part of two-phase commit procedures in distributed systems or as a confirmation step in reliable transmission protocols.
In Depth
The basic problem: uncertainty about the state of the network
A sender never knows for sure on its own whether a sent packet really arrived — the network can lose packets, duplicate them or deliver them in the wrong order, and even a missing reply doesn’t necessarily prove that the original message never arrived (perhaps only the confirmation itself was lost). A “commit” is the recipient’s explicit counter-confirmation that resolves this fundamental uncertainty problem of distributed systems: only when it arrives may the sender assume with high certainty that the transmission was successful and, for example, free its send buffer or start the next action.
ACK as the simplest form of a commit
In TCP, the ACK flag plays exactly this role at the packet level — every received segment is acknowledged with a running acknowledgement number, so that the sender knows exactly up to which byte the transmission is considered secured. This principle is the simplest form of a “commit”: a single, binary confirmation between exactly two parties.
Two-phase commit in distributed systems
In distributed database systems the concept goes a decisive step further, because there not just two but potentially many nodes have to stay consistent at the same time. In a two-phase commit (2PC), a coordinator first asks ALL participating nodes whether they can commit a transaction (“prepare” phase — each node checks, for example, whether enough storage space is free or whether a constraint would be violated, and answers yes or no), and only if REALLY ALL of them agree does the coordinator release the actual “commit” in the second phase. If even a single node reports a problem, a global rollback is triggered instead — the transaction is discarded completely instead of being carried out only partially. Without this two-stage procedure, a network failure in the middle of the transmission could lead to some of the systems accepting the change and others not — an inconsistent state that 2PC specifically prevents.
Weaknesses of 2PC
However, 2PC has a well-known weak point: if the coordinator itself fails exactly between the prepare and commit phases, all participating nodes remain in an unclear waiting state (“blocking problem”) — they have agreed, but don’t know whether they should actually commit or roll back until the coordinator is reachable again. More advanced procedures such as three-phase commit (3PC) or modern consensus algorithms such as Raft and Paxos, which are used in distributed databases and configuration services, for example, address exactly this problem by being more robust against the failure of individual coordinator nodes.
How it differs from Git
Important for clear terminology: a Git commit has nothing to do with this networking concept apart from the shared root of the word (“to bindingly fix something”) — there, commit refers to permanently saving a set of changes in the local version history, entirely without network communication or confirmation by a counterpart.
See also: ACK, Transmission, TCP