-
Notifications
You must be signed in to change notification settings - Fork 10
WhyUDP
Mark W. Eichin edited this page Feb 5, 2012
·
1 revision
Multiple reasons that made sense in 1987:
- Original intent was for low-sender-overhead best-effort delivery of status messages to users; for example, the embedded system on a printer could directly attempt to notify a user that their print job was done or jammed. Even for more larger systems (for example, fileservers) it was felt that it would be easier to adopt if there wasn't persistent overhead - if you could cheaply bang out a notification without having to maintain a connection.
- Another advantage was allowing the server cloud to vary without client involvement - while the zhm "transmission tower" cached one likely-to-be-up server to *send* the message to, incoming messages "just arrived from space" without the client needing to be aware of the configuration of the set of servers.
- Note that at the start, messages didn't have fragmentation, that was added by Rob French; it doesn't need more than a packet to say "print job done" or "fileserver shutdown in 10 minutes".
- "unsafe" and "unacked" are common message types that actually don't need the overhead of TCP to still qualify as best-effort and get through some of the time.
- It was expected to scale to at a minimum "all students" and "all systems" on campus, and needing a file descriptor per TCP session on the server was thought to be a serious bottleneck (on the VAX 11/750's of the day, it probably was; 4.2BSD hadn't had any of the later kernel-memory footprint optimizations needed for things like C10K)