when I asked people to explain how UDP works I got a lot of answers to the effect of "it's spray and pray"

but I'm having trouble thinking of examples of UDP-based protocols that actually work in a "spray and pray" way —

* DNS is "send 1 packet, retry if you don't get a reply”
* QUIC is a sophisticated system for streaming data over UDP
* I'd guess that video protocols correct for packet loss
* maybe statsd is a "spray and pray” system?

(please do not reply to this explaining how UDP works)

@b0rk ArtNet. It's essentially UDP encapsulated DMX for lighting. Typically broadcast like DMX is, with each fixture figuring out which channels to read from the packets. Loss is tolerable since the lighting controller is continuously putting out frames.
@b0rk there's also NMEA-0183 over Ethernet, which is a common protocol in marine OT networks for broadcasting (or multicasting) sensor readings from things like GPS, compass, sonar, etc. to navigational equipment on the network. again these are loss tolerating systems with continuous updates.
@b0rk there are also a ton of industrial control protocols built around this type of design. a notable feature I've seen at least once (I'd need to do some digging to find out which protocol it was) is in alarm state broadcast protocols where they use QoS to tag the frames as being the highest priority, and send several alarm packets with the same data, to improve delivery likelihood.
@gsuberland @b0rk if you’re deliberately sending multiple copies of the same packet for redundancy, what’s the benefit over TCP and retransmits? Speed?
@witewulf @b0rk latency and broadcast (which is also partly a latency thing, since you only need to send one frame to the switch). while UDP doesn't have delivery guarantees at the protocol level, in practice there's not much reason for a UDP packet to get dropped on a dedicated local network. the repeated packets are mostly just there in case of an extremely rare bitflip.

@gsuberland @b0rk
USA NOAA NWS weather radars and associated sensors at a radar site would broadcast their raw data via UDP on the LAN, or use multicast. This enabled safe-enough addition of 3rd party research university "listeners" on-site to pick up the stream, with the listeners' ethernet NICs/cables having transmit physically disabled (not connected).

I don't think we've lost a plane on final approach to a microburst since that work. (NOAA now runs the microburst prediction.)