<story><title>UDP and me</title><url>http://www.reed.com/blog-dpr/?page_id=6</url></story><parent_chain></parent_chain><comment><author>Animats</author><text>The original plan for IP was that if you created a new datagram-level protocol, you&amp;#x27;d get a new IP protocol number for it.  There were a lot of those in the early days.[1]  Some were just encapsulation of other protocols - Xerox Parc Universal Protocol (IP protocol #12), Ethernet over IP (#97).  Others were for network routing and administration - Exterior Gateway Protocol (#8) and Dynamic Source Routing Protocol (#48). Those were all standardized numbers, and IANA still maintains that list, although most of those protocols are long dead.&lt;p&gt;UDP was a general encapsulation for doing the same thing one level higher.   Instead of IP level protocol numbers, the whole thing was repeated one level higher, and there are standard UDP port numbers.[2]  At the network level, there&amp;#x27;s no big gain here, and it adds another header and some overhead. But BSD and the socket interface made a big distinction between software based on existing protocols and ones using the &amp;quot;raw socket&amp;quot; interface. That pushed new work to UDP and away from the IP protocol level.&lt;p&gt;If you want to have fun with your network, crank up something that speaks ISO-TP4 (protocol #29) such as Windows 2000 and see how far the packets get.  Or look at your corporate network&amp;#x27;s packet traffic and see if there&amp;#x27;s any activity on the old protocol numbers.&lt;p&gt;[1] &lt;a href=&quot;http:&amp;#x2F;&amp;#x2F;www.iana.org&amp;#x2F;assignments&amp;#x2F;protocol-numbers&amp;#x2F;protocol-numbers.xhtml&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;www.iana.org&amp;#x2F;assignments&amp;#x2F;protocol-numbers&amp;#x2F;protocol-nu...&lt;/a&gt;
[2] &lt;a href=&quot;http:&amp;#x2F;&amp;#x2F;www.iana.org&amp;#x2F;assignments&amp;#x2F;service-names-port-numbers&amp;#x2F;service-names-port-numbers.xhtml&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;www.iana.org&amp;#x2F;assignments&amp;#x2F;service-names-port-numbers&amp;#x2F;s...&lt;/a&gt;</text></comment>
<story><title>UDP and me</title><url>http://www.reed.com/blog-dpr/?page_id=6</url></story><parent_chain></parent_chain><comment><author>drawkbox</author><text>&lt;i&gt;While I’m honored whenever anybody appreciates important design choices where I’ve been involved, this is not quite right, and it’s a little embarrassing to be the inventor of something so simple.&lt;/i&gt;&lt;p&gt;&lt;i&gt;Actually, UDP was “un-designed” by me and others. By this I mean that UDP was the final expression of a process that today we would call “factoring” an overly complex design.&lt;/i&gt;&lt;p&gt;Actually he should not be embarrassed.  Engineering at the core is taking something complex and making it simple, as simple as can be but not too simple.  It takes tons of effort to simplify. That is why most engineers&amp;#x2F;developers think that complexity shows their knowledge, it is actually the direct reverse of that. But where you try to simplify you will feel currents pulling you the other way and you&amp;#x27;ll have to swim upstream for a bit.&lt;p&gt;Thank you for inventing UDP and by inventing I mean simplifying something unnecessarily complex into something usable. It has been the key to many game technologies and has made possible and been a base platform for some wonderfully complex things, simply by being simple. Complexity only through simple parts.&lt;p&gt;“Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius — and a lot of courage to move in the opposite direction.” 
― Ernst F. Schumacher&lt;p&gt;“Life is really simple, but we insist on making it complicated.” 
― Confucius</text></comment>