UDP has it's place, but typically vanilla file transfer isn't it. UDP traffic typically is harder to NAT rather than easier. Since it is a stateless protocol, what is meant by a 'reply'? How do you keep a forward and reverse translation table for the communications? The answers to these questions are to wrap these 'stateful' UDP sessions inside a psuedo-connection. In otherwords, simulate TCP behavior. The reality of today's internet is that NAT is prevalent, especially in home use. There simply isn't enough IP space in IPv4 to accomodate everybody, so we are left with dealing with the mess that RFC 1918 addressing, NAT and all the other work arounds have given us. STUN came out of trying to get VoIP working in a NATed environment. Since the latency demands of any VoIP application is fairly extreme and a single lost packet isn't detrimental to the data, UDP makes sense for that application. To get it to function in a NAT world however requires some intellegence in software to determine that NAT exists, how it functions and what to do about it. Enter STUN. While you might be able to squeeze some extra speed out of UDP for P2P apps, it isn't without complexity costs somewhere. You basically have the options of ignoring packet loss (VoIP/Skype) or implementing your own packet reliability mechanism (TFTP) within the application. Something like BitTorrent could use UDP, since it is sending bits of data from many sources to many sources. (It doesn't use UDP, it uses TCP.) UDP makes a lot of sense for one-to-many or many-to-many relationships for networking traffic. That's what multicast is all about, which uses UDP. Unfortunately, it's not internet routable so isn't a good general solution to P2P traffic. Tom On Apr 5, 2005 11:26 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:
Intra-net where you are broadcasting updates or patches to a cluster of machines it makes since, but for peer-to-peer it just doesn't reap any benefits on the internet proper.
You are wrong, UDP is more and more adopted by end-user P2P software because of its ability to transparently go through - in and out - many types of NAT devices (which are themselves more and more popular among home users). Incoming TCP traffic, on the other hand, often needs to be specifically enabled on the NAT box.
For juicy details, you can read the RFC for the STUN protocol (Simple Traversal of User Datagram Protocol - UDP - Through Network Address Translators - NATs): http://www.faqs.org/rfcs/rfc3489.html
Regards
Antoine.
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python