An emergency-management office streams live council-meeting video where low latency matters more than retransmitting every lost packet. Which transport is the better fit?
Select an answer to reveal the explanation.
Short Explanation
Live video is like a radio broadcast—better a tiny glitch than a long pause while someone rewinds the tape. UDP keeps it moving; TCP's retransmits can add lag you don't want on a live stream.
Full Explanation
Live council-meeting video for emergency management prioritizes timely delivery over perfect retransmission of every lost packet. UDP fits that loss-tolerant real-time pattern: it avoids head-of-line blocking from transport retransmissions so streams continue with minimal latency, accepting occasional glitches rather than long freezes. For live streaming where low latency matters most, UDP (often under RTP/HTTP media stacks that choose datagram semantics) is the better transport fit than strict TCP reliability.
TCP only, because every video frame must wait for full retransmission, fails as the better fit when the stem values low latency over waiting for every loss recovery at the transport layer—TCP retransmissions can stall real-time play. FTP control-channel semantics as the video media transport fails by concept—FTP is a file-transfer application protocol, not the preferred live media transport. SMTP message queuing to deliver each video frame as email fails because email queuing is high-latency store-and-forward, unsuitable for live council video.
Exam caveat: Match transport to application needs: TCP for reliability/ordering; UDP for timely, loss-tolerant streams. "TCP only always" is a common trap on real-time stems.
Operational check: Validate the streaming stack uses UDP-based or real-time-friendly transport, monitor latency/jitter vs rare loss, and avoid forcing TCP-only paths that introduce multi-second stalls during loss. If operators insist every frame retransmit before continuing, they are optimizing archival integrity—not live emergency-management viewing.