store-and-forward transmission

Picture a relay race where each runner must hold the whole baton in hand before sprinting to the next runner — no one passes the baton mid-stride. Store-and-forward works like that: a packet switch must receive the entire packet and store it before it begins forwarding any of it onto the next link. It does not stream the bits straight through as they arrive.

Why hold the whole packet first? Because the router needs the full header (and often a checksum) to decide where to send the packet and to verify it is not corrupted — and it cannot start sending on the next link until it has somewhere to send it and is sure the packet is intact. The consequence is a transmission delay at every hop: pushing an L-bit packet onto a link of rate R bits per second takes L/R seconds, and that whole delay is paid once per router on the path. For a packet of L bits crossing N store-and-forward links each of rate R, the end-to-end delay from this effect alone is roughly N times L/R (ignoring propagation and queuing).

This is a foundational reason real networks are not instantaneous even with no congestion: each hop adds the time to clock the packet out. Pipelining many packets hides most of this (while hop 2 is forwarding packet 1, hop 1 is already receiving packet 2), which is exactly why long transfers are sent as a stream of packets rather than one giant block. The term contrasts with cut-through switching, where a switch starts forwarding as soon as it has read the header — faster, but it cannot drop a corrupt packet it has already begun sending.