How BitTorrent deals with people behind NAT?

[sytelus]

Scenario #1
My computer is behind NAT but I can see in my BitTorrent client that
other people are indeed connecting to me and data is being uploaded
from my machine. Because I'm behind the NAT I'd assumed that no one
can connect to me unless I make the connection request first to those
other users (even if I've a socket listenig). Now, is it correct for
me to assume that those other users downloading from me are not behind
the NAT and all of them accepts incoming connection? How this is working?

Scenario #2
Say 100 clients are trieng to download, out of which 90 are behind
their own NATs. Does that means none of these 90 will never
communicate with each other and they will depend on other 10 to get
the file? What if all 100 are behind their own NATs?

These questions are biting me a lot (almost spend half of a day to
find answers).

Thanks,
Shital.






Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/BitTorrent/

<*> To unsubscribe from this group, send an email to:
BitTorrent-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Brian Dessent]

Post by sytelus
Scenario #1
My computer is behind NAT but I can see in my BitTorrent client that
other people are indeed connecting to me and data is being uploaded
from my machine. Because I'm behind the NAT I'd assumed that no one
can connect to me unless I make the connection request first to those
other users (even if I've a socket listenig). Now, is it correct for
me to assume that those other users downloading from me are not behind
the NAT and all of them accepts incoming connection? How this is working?
Scenario #2
Say 100 clients are trieng to download, out of which 90 are behind
their own NATs. Does that means none of these 90 will never
communicate with each other and they will depend on other 10 to get
the file? What if all 100 are behind their own NATs?

"Behind NAT with ports forwarded" == you will initiate and receive
incoming connections

"Behind NAT without ports forwarded" == you will only be able to
initiate connections to those that can recieve them (== those not behind
NAT or those behind NAT with ports forwarded)

In either case once the connection is established both will be able to
upload to the other. So it's not a question of being able to upload,
it's question of who you are able to connect to, and forwarding ports
makes you much more connectable.

Brian



Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/BitTorrent/

<*> To unsubscribe from this group, send an email to:
BitTorrent-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[tnnd]

Post by Brian Dessent
"Behind NAT without ports forwarded" == you will only be able to
initiate connections to those that can recieve them (== those not behind
NAT or those behind NAT with ports forwarded)
In either case once the connection is established both will be able to
upload to the other. So it's not a question of being able to

upload,

Post by Brian Dessent
it's question of who you are able to connect to, and forwarding ports
makes you much more connectable.
Brian

Brian,

I have a question for clients behind NAT without port forwarding
enabled: when such client requests a file piece from a peer, it opens
a UDP socket to that peer. If that peer wants to download another
file piece from this client, would BitTorrent use the same UDP socket
to do the uploading and downloading?

The reason for asking is, if the client doesn't have port forwarding,
I think there is no peers can initiate any connection to that
client. If this is true, then the only way that client can upload is
because other peers have to use the same UDP socket to do upload and
download. Is this correct?

Thanks
Mingjun






Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/BitTorrent/

<*> To unsubscribe from this group, send an email to:
BitTorrent-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Vitenka]

Yes - typically a connection which is initiated in one direction will
then ALSO be used to transfer pieces in the other direction.

This deals well with situations where one of the two peers is behind a NAT.



Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/BitTorrent/

<*> To unsubscribe from this group, send an email to:
BitTorrent-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Joseph Ashwood]

I went ahead and snipped everything because I'm going on a severe tangent
from there.

NAT to NAT connection, assuming no port forwarding, etc is obviously
difficult, but it is not unsolvable. There is a statistical way of making
the connection, although I cannot think of a non-brokered version that is
100% successful.

While the proposal is very ill-formed right now, it descends rather directly
from the Gnutella method of NAT2NAT connections. It works like this, from
behind the NAT send out UDP packets on the correct port to the other hosts
that you are willing to talk to, hosts that are willing to talk to you will
have done the same. At this point the NATs have established routing, with
each mapping ports to the other. From here the connection can be treated as
normal. The problem is that a stateless beginning packetset has to be made.
A simple "Open to connection" packet (any invalid BT packet, or a keep-alive
should work), would be stateless, and could establish the routing table.
Hosts not behind NATs have no need to send out these packets, and since no
response is expected the NAT mapping becomes a router.

The frequency of the packets is open to wide debate, and is an area that my
knowledge does not lay in.

The biggest disadvantage of this protocol as I see it are specifically that
there is only a statistical probability of establishing the connection. This
makes it undependable, but if every peer used it every time the NATs could
be effectively eliminated.

It would take a critical mass of clients in order to make this substantially
useful, but it does have greedy uses. By establishing these routing blocks a
peer is more likely to be able to accept incoming connections. Unfortunately
this is massively incomplete and will require someone with a more intimate
knowledge of UDP and NAT than I have any desire for.

Any thoughts?
Joe




Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/BitTorrent/

<*> To unsubscribe from this group, send an email to:
BitTorrent-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Olaf van der Spek]

Post by Joseph Ashwood
It would take a critical mass of clients in order to make this substantially
useful, but it does have greedy uses. By establishing these routing blocks a
peer is more likely to be able to accept incoming connections. Unfortunately
this is massively incomplete and will require someone with a more intimate
knowledge of UDP and NAT than I have any desire for.
Any thoughts?

Wouldn't this also require the entire BT protocol to be written on top
of UDP?



Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/BitTorrent/

<*> To unsubscribe from this group, send an email to:
BitTorrent-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[larytet]

"Wouldn't this also require the entire BT protocol to be written on
top of UDP?"

see NAT penetration in Rodi
http://larytet.sourceforge.net/userManual.shtml#Lesson%204.0 Lesson 4

essentially NAT penetration task (NPT) scans all ports in NAT looking
for anyone open and sends packet "Who am I" to some IP (for example,
gateway). NPT expects that the destination will send the packet back this
way exposing the port (hole) openned in NAT or to answer with reply
"You are" if the destination runs Rodi client. This way Rodi client
learns what it's external IP address and port.

to fight intelligent firewalls Rodi spec includes faking RTP and DNS
packets and UDP payload encryption.

Rodi is pure UDP based protocol. Rodi client never (i mean it - NEVER)
attempts to establish bidirectional connection and never assumes that
source IP/port in the UDP header are correct and can be relied on.

Rodi client generates unique (for this client) requiest ID - 64 bits
number and sends the request to some IP address. The same packet
stamped with
different request IDs can be sent to multiple IP addresses and this is
(similar IP address scan) what exactly LOOK makes.

Remote Rodi client will copy request ID in the reply packet. On the
receive side Rodi will fetch request ID from the arrived reply and try
to find in the hash table of pending requests






Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/BitTorrent/

<*> To unsubscribe from this group, send an email to:
BitTorrent-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Joseph Ashwood]

----- Original Message -----
From: "Olaf van der Spek" <***@LIACS.NL>
Subject: Re: BT behind NATs, getting it to work (was Re: [BitTorrent] Re:
How BitTorrent deals with people behind NAT?)

Post by Olaf van der Spek

Post by Joseph Ashwood
It would take a critical mass of clients in order to make this substantially
useful, but it does have greedy uses. By establishing these routing blocks a
peer is more likely to be able to accept incoming connections. Unfortunately
this is massively incomplete and will require someone with a more intimate
knowledge of UDP and NAT than I have any desire for.
Any thoughts?

Wouldn't this also require the entire BT protocol to be written on top
of UDP?

In short, yes, at least the NATd connections. The cost would be generating a
TCP work-alike, the benefit that NATs are less of an issue.

Technologically I think it's feasible, as far as development of such a
protocol, I'd probably step out of any part that wasn't security oriented.
Joe




Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/BitTorrent/

<*> To unsubscribe from this group, send an email to:
BitTorrent-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/