I was the person who proposed UDP in the original TCP/IP design (in 1976), and fought for it as a vehicle for connectionless protocols. Connectionless protocols are very powerful, especially when there are more than two end-points in a protocol, and when communication among the end points is used to propagate state changes in an application-specific way. UDP does NOT have 'connections'. It is NOT required, and was NEVER intended that a UDP datagram must be part of a 'session' set up by some kind of initial datagram from the person 'opening' the 'session'. That may be a common use, but it is not the only use, and such a restriction was not intended in the original design. It's a peculiar rewrite of history to say (as one correspondent did) that Quake violates a rule of UDP by transmitting addresses in data portions of datagrams. That rule is not a UDP rule, but a NAT-compatibility limitation - a case where NAT does not work. But NAT-compatibility is not a requirement for Internet protocols - to the contrary, IP is an end-to-end protocol, and the IP spec says that certain parts of the IP datagram are to be delivered unchanged (and that includes the address fields). That NAT happens to work at all is a lucky accident. NAT requires that UDP be used in this restricted manner (requiring connections) in order to detect new translations that it must do. In other words, NAT precludes a wide variety of perfectly legitimate protocols. IMHO, this makes NAT bad for the Internet. If you cannot conceive of the Internet evolving and adding new multi-endpoint protocols, you may not agree. But I hope some of you will join me in resisting the spread of NAT by not using the feature, and by informing any ISPs or corporate sysops who use NAT that NAT is a bad idea for the health of the net. The spread of NAT (which Ascend and other vendors are encouraging, much to my chagrin, and anger,) with its assumption that 'connections' are maintained, is being used as a vehicle for stamping out protocols that are PERFECTLY valid, and in many cases very good ideas. It may be possible to make Quake's protocol NAT-compatible - and I suspect the market will do that, because enough ISPs have decided to offer NAT-crippled service to save a few bucks on subnet address space. But there are other protocols (some yet to be invented) that make a lot of sense for their application, but for which forcing NAT compatibility may be difficult, impossible, or just plain suboptimal. - David ++ Ascend Users Mailing List ++ To unsubscribe: send unsubscribe to ascend-users-request@bungi.com To get FAQ'd: <<A HREF="http://www.nealis.net/ascend/faq">http://www.nealis.net/ascend/faq</A>> </PRE> <!--X-MsgBody-End--> <!--X-Follow-Ups--> <HR> <STRONG>Follow-Ups</STRONG>: <UL> <LI><STRONG><A HREF="msg10378.html">Re: (ASCEND) Quake/QW and Pipeline 75 and NAT</A></STRONG></LI> <UL> <LI><EM>From</EM>: Jason Eggleston <jason@jet.net></LI> </UL> </UL> <!--X-Follow-Ups-End--> <!--X-References--> <!--X-References-End--> <!--X-BotPNI--> <HR> <UL> <LI>Prev by Date: <STRONG><A HREF="msg10371.html">(ASCEND) Max 4004 72 Modems</A></STRONG> </LI> <LI>Next by Date: <STRONG><A HREF="msg10368.html">(ASCEND) Digital Modem Use</A></STRONG> </LI> <LI>Prev by thread: <STRONG><A HREF="msg10376.html">Re: (ASCEND) Quake/QW and Pipeline 75 and NAT</A></STRONG> </LI> <LI>Next by thread: <STRONG><A HREF="msg10378.html">Re: (ASCEND) Quake/QW and Pipeline 75 and NAT</A></STRONG> </LI> <LI>Index(es): <UL> <LI><A HREF="maillist.html#10369"><STRONG>Main</STRONG></A></LI> <LI><A HREF="thrd226.html#10369"><STRONG>Thread</STRONG></A></LI> </UL> </LI> </UL> <!--X-BotPNI-End--> <!--X-User-Footer--> <!--X-User-Footer-End--> </BODY> </HTML>