tion host that the connection agreement has been accepted and that
the actual connection has been established. Data transfer can now begin.
is generating data traffic a lot faster than the network can handle transfer-
ring. A bunch of computers simultaneously sending datagrams through a
single gateway or destination can also botch things up nicely. In the latter
case, a gateway or destination can become congested even though no single
source caused the problem. In either case, the problem is basically akin to
a freeway bottleneck--too much traffic for too small a capacity. It's not
usually one car that's the problem; there are simply too many cars on that
freeway.
But this buffering action can only solve the problem if the datagrams are part
of a small burst. If not, and the datagram deluge continues, a device's mem-
ory will eventually be exhausted, its flood capacity will be exceeded, and it
will react by discarding any additional datagrams that arrive.
and allowing data to be lost, the transport can issue a "not ready" indicator
to the sender, or source, of the flood (as shown in Figure 1.6). This mecha-
nism works kind of like a stop light, signaling the sending device to stop
transmitting segment traffic to its overwhelmed peer. After the peer receiver
processes the segments already in its memory reservoir--its buffer--it sends
out a "ready" transport indicator. When the machine waiting to transmit
the rest of its datagrams receives this "go" indictor, it then resumes its
transmission.
transmitted--and the transmission fails if this order is breached! If any data
segments are lost, duplicated, or damaged along the way, a failure will transmit.
This problem is solved by having the receiving host acknowledge that it has
received each and every data segment.