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 DNS NOTIFY? You send the packet but never expect any form of ack.
There are may be other types of best-effort notification working the same way.
@bortzmeyer @b0rk
There is a response defined in RFC1996 4.7:
"It will also send a NOTIFY response back to the NOTIFY request's source, with the following characteristics..."
This memo describes the NOTIFY opcode for DNS, by which a master server advises a set of slave servers that the master's data has been changed and that a query should be initiated to discover the new data. [STANDARDS-TRACK]
@Lunaphied @b0rk Early games such as Doom used UDP.
Many early voice transmissions were UDP. Live audio is a good fit since you want low latency and being silent (lost packet) is tolerable. I believe modern synchronized audio transmitter/receivers on the local network are UDP based, but embed timing information so when loss happens, you can keep the audio in sync based on the explicit timing data. The human ear needs delays <30ms.
If you want some simple experiments at the cli, see netcat / nc
early voice? The SIP protocol is still used for a lot of phone calls. SIP creates two UDP streams for audio and/or video. One from caller to callee and one from callee to caller. These streams are called RTP in SIP.
Audio stream is cut into ~20ms or 1/50 second worth of data. UDP is great for this application as a lost packet (~ 20ms) can be "back filled" by our brains.
Operating Consul as an Early Adopter - Download as a PDF or view online for free
@PresGas @b0rk I think (udp) NFS wasn't quite spray and pray in this sense; much like DNS, the UDP packet itself might get lost but the client was expected to retry.
(The server did not retry its answers, which led to all sorts of fun. Clients were expected to retry an operation that didn't get a reply, but some operations can't be retried cleanly if they already succeeded, so servers added hacks to recognize such retried operations, and etc etc.)
@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.)
@b0rk @bortzmeyer what about wake on LAN,
Can even be routed
@pulkomandy @b0rk tried looking in the other thread, and spray might be sending towards one system, or to various destinations
UDP syslog is spraying towards a logging infrastructure, sometimes resembles a firehose
I have also seen file transfer programs built using UDP just rapidly sending a lot of data, and the at the end filing the missing pieces
The old Ghost for making images onto a classroom of PCs also comes to mind
https://en.m.wikipedia.org/w/index.php?title=Ghost_(disk_utility)&diffonly=true
@b0rk vpns? maybe? encapsulating tcp in udp feels like it would solve some problems of tcp in tcp but i haven’t looked under the hood recently either
the decision to use udp for quic feels like an important bit of
@b0rk I think the deal is that protocols layered on top of UDP do the retrying, re-implementing the parts of TCP that they need.
Edit: I had to look this up - TCP itself is not implemented on top of UDP, rather they are both built on top of IP. UDP actually came after TCP. Maybe the way to approach this line of inquiry is to ask what UDP adds to IP. And I think the answer is: ports and a data checksum.
@RandomDamage
I came here to say basically that. UDP is "spray and pray". Then things like QUIC or video/audio streaming protocols build complex systems and rules on what to do if packets arrive out of order or not at all, instead of depending on underlying TCP to take care of that for them.
Or I guess putting it differently, UDP is "I don't care about reliable delivery at "transport" layer, I have a better solution for that in the application" (which also may be TCP inside VPN)
@b0rk
@b0rk sorry.
Can I offer VOIP as a place where it is also used in "spray and pray" mode?
The actual use cases are very limited, but the place to look is anywhere that latency dominates the requirements
@RandomDamage @b0rk Is VOIP actually "spray and pray"?
I think it helps to define what "spray and pray" means, and I'd say it means sending out packets without any feedback.
Request/response is not spray and pray, TCP style reliable in-order delivery is not, but also anything which does congestion control also wouldn't be considered spray and pray.
AFAIK, VOIP is generally done over RTP which does have packet loss detection and congestion control.
@b0rk I'm not quite sure what counts as 'spray and pray'.
My biggest use of UDP is in VPNs, where each outer UDP packet wraps an encrypted inner IP packet. The VPN doesn't worry about acks or retries – it expects higher-layer inner protocols to do that. But _something_ is still worrying about it.
'Spray and pray' suggests multiple destinations. Perhaps a set of secret-sharing servers, so that you need any M of N to answer your query? But I don't know of anyone doing that for real.
@b0rk niche but there is a small class of "udp multicast" protocols to do parallel file distribution. They literally spray the whole blob with some error correction bits so clients can recover from missed packets. I can only find one example at the moment [1] but I think there used to be a few more floating around.
The same trick is useful on asymmetrical connections like old school satellite downlinks.
@b0rk some multiplayer games kind of do (did?) a similar thing, they'll stream some amount of state deltas without any ack and then do a less frequent roll-up of the whole state. Missed updates are just ignored by the client so sometimes you just "teleport" when the roll-up contains an important delta that you missed.
Very not my area of expertise so maybe games haven't done this since the 90s but I swear it was a thing at one point.
@skorgu @b0rk the fancy version of this is Fountain Coding (or early, Tornado Coding), where the entire file is intertwingled with itself in a way that allows guaranteed reconstruction when K packets are received. Long ago I did some work on distributing tornado-coded files over UDP, which had the property of not caring about retransmission or ACK.
Our metaphor for it was: it’s raining beer. Hold out your cup, and when it’s full, drink!
@b0rk Syslog over UDP does that; I assume other stats/logging systems make the same trade off re simplicity and bounded work in the client VS delivery guarantees.
Otherwise, I think I've only seen un-acked sends coupled with erasure coding, for latency sensitive payloads where getting the data multiple RTTs late is useless. So sure, some amount of prayer, but only after putting extra work to let receivers cope with a couple lost packets.
Julia Evans
Stéphane Bortzmeyer
Csillag Tamás
John W. O'Brien
Lunaphied
Trouble
RobJE
École des Bro-Arts
Coda
PresGas - RPG and Left Nerd
Chris Siebenmann
Bill Plein🌶
Paul
Jonas Schäfer
Graham Sutherland / Polynomial
Gary Parker
Richard Johnson
Henrik Kramselund - kramse
PulkoMandy
gravely
Rich Lafferty 🐀
Viraptor
Jef Poskanzer
Random Damage 🌻
viq
Brian Campbell
m_eiman
Simon Tatham
GSV Megastructure Enthusiast
Michael Hanson
Haelwenn /элвэн/ 
feld
Avdi Grimm
Ivo Limmen
Mark Pauley
Paul Khuong
doragasu
cate
Ben Clifford