A transit authority must collect syslog from hundreds of closets without maintaining a transport session per device. Which approach best fits that operational messaging pattern?
Select an answer to reveal the explanation.
Short Explanation
Hundreds of closets yelling status updates don't need a reserved phone call each—UDP-style fire-and-forget fits. Parking a TCP session per box forever is heavy for simple ops messages.
Full Explanation
A transit authority collecting syslog from hundreds of closets without maintaining a transport session per device favors UDP-style fire-and-forget messaging. Syslog-over-UDP (or similar datagram export) lets each closet emit logs without retaining per-device TCP session and retransmission state on collectors already aggregating high volumes. That operational messaging pattern matches scale and simplicity when guaranteed transport session state per closet is undesirable.
Require a dedicated TCP session and retransmission state for every closet forever fails as the best fit when the stem wants to avoid per-device session maintenance—TCP syslog exists but contradicts the stated operational preference. Use only BitTorrent peer swarms as the syslog transport standard fails by concept—P2P file swarms are not municipal syslog transport. Encapsulate every syslog line in an OSPF LSA for routing-table delivery fails because OSPF LSAs are routing information, not a log-transport mechanism.
Exam caveat: High-volume telemetry/syslog often uses UDP for low overhead; choose TCP when you explicitly need reliability/session semantics and can operate that state. Read which constraint the stem emphasizes.
Operational check: Point closets at the collector using UDP syslog, confirm receipts under load, and monitor for acceptable loss versus collector capacity. If operators mandate zero message loss with full session state, move to TCP/TLS syslog deliberately—but that is a different requirement than the one in this question.