[Twisted-Python] UDP File Copy
tomc74 at gmail.com
Tue Apr 5 15:31:23 EDT 2005
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.
On Apr 5, 2005 11:26 AM, Antoine Pitrou <solipsis at 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):
> Twisted-Python mailing list
> Twisted-Python at twistedmatrix.com
More information about the Twisted-Python