Jump to content

net.bind_ip and net.outgoing_ip, what does it really mean?


jfjm

Recommended Posts

In the documentation, net.bind_ip and net.outgoing_ip are defined as:

net.bind_ip: If your computer setup requires that you use a specific LAN adapter for incoming connections, you may specify that adapter's IP address here.

net.outgoing_ip: If your computer setup requires that you use a specific LAN adapter for outgoing connections, you may specify that adapter's IP address here. Note that Windows will sometimes ignore this setting and use other adapters due to their binding orders in Windows. To fix this, read Microsoft's knowledge base article

Does it mean that uTorrent will connect out to other peers using the net.outgoing_ip BUT when connecting to the tracker, uTorrent will use the net.bind_ip? If not, then other peers will not be connecting to the net.bind_ip since no peers will be aware of the net.bind_ip.

Also, how can I address the issue when the network interfaces use dynamic IPs. So is there a way to enter network interface instead of IP address?

Thanks.

Link to comment
Share on other sites

DreadWingKnight, perhaps I didn't articulate my first question clearly. I fully understand:

Incoming connections go to bind_ip (Listener binds there)

ALL outgoing connections go from outgoing_ip

And yes, Windows XP will properly honor the binding if you config the metric and dead gateway detection correctly.

However, this is like I have 2 phones, one I use to receive phone calls, and one I use to call others. However, if I do NOT ever tell others (others detemine my number based on the caller ID information, so they will get the number that I used to call them) of the phone number that I use to receive phone calls and the phone book only list the phone number I use to call out, no one will EVER call the phone that I use to receive calls.

The same situation occurs here. Other peers will only connect to the bind_ip if they obtain the information (IP, port,etc) from the trackers or other peers. Given many trackers will use the actual connected IP and not the reported IP, other peers will not know about your bind_ip. So how will they connect to it?

Of course now if you the bind_ip to connect to trackers and outgoing_ip to connect with other peers, you can actually achieve the effect of other connect to me on the bind_ip and I connect to others on ougoing_ip.

Firon, thanks for the info. Allow input of interface should be small (and quick) enough of a change, merely look up the IP of the interface that I hope the engineers would think this is "cheap" and "valuable" feature (mostly for people with multiple WAN). :)

Thanks.

Link to comment
Share on other sites

My understanding based on the basic principles of the BitTorrent Protocol and TCP/IP is:

First:

peer-to-tracker messages are HTTP Request/Response

peer-to-peer messages are TCP/IP Socket communications

The application has control over TCP/IP sockets it uses.

I think, the application hasn't control over HTTP. It sends its GET Request to the Tracker and the OS routes it through the appropriate Interface according to its Routing Table.

Then:

For an application implementing BitTorrent Protocol to start sharing it needs to know the participating peers.

So, it sends a HTTP Request to the tracker using GET Method.

The application puts:

info_hash (identifying the torrent), peer_id, ip (optional), port (the application's TCP/IP socket in use) and other information in its Request.

The Tracker Response contains peers' information (among other):

peer id: peer's self-selected ID

ip: peer's IP address

port: peer's port number.

It should be clear now that

if net.outgoing_ip parameter is set uTorrent will use it for its outgoing TCP/IP connections. These are the connections it initiates and they are used by both connected applications.

This IP shouldn't be sent to the tracker because uTorrent isn't using it for incoming connections.

if net.bind_ip parameter is set uTorrent will use it for its incoming TCP/IP connections which it doesn't initiate and will be sent to the tracker so as another participating applications to be able to initiate connections to it.

Link to comment
Share on other sites

HTTP uses TCP/IP, it is just higher layer of the 7 layers of network, so the application can completely control which interface it uses to send the HTTP request.

As you have indicated:

The application puts:

info_hash (identifying the torrent), peer_id, ip (optional), port (the application's TCP/IP socket in use) and other information in its

Note, IP is optional since the tracker can/will detect the IP based (and sometimes override the ip sent in the message) on the actual (HTTP request to the tracker) connection. Port is mandatory since TCP will use different ports (assuming re-use option is not used) for each outgoing connection.

So it still goes back the question, if the tracker will override the IP sent in the message with the actual IP used to connect with the tracker, then no one will "know" the net.bind_ip. At the same time, altough the net.outgoing_ip is not sent to the tracker in the HTTP message, but it is the interface that is used to make the actual connection to the tracker. Again, if the tracker override the IP sent in the message with the actual connected IP, then net.outgoing_ip would ended being the IP passed out to other peers.

Link to comment
Share on other sites

"HTTP uses TCP/IP, it is just higher layer of the 7 layers of network, so the application can completely control which interface it uses to send the HTTP request."

I think it isn't exactly correct.

Actually, I'm guessing about HTTP because I haven't programmed it. Of course I could check it out to answer strongly.

Again, I think you just write your GET Request, put the URL in and let it go.

But I'm pretty sure about programming TCP/IP. No doubt about that. As a programmer You can use every thing at the protocol level.

Preferences/BitTorrent IP/Host Name to report to tracker is another possibility for an application to choose which IP address for its incoming connections to send.

It isn't clear what the tracker is going to do because its incoming GET Request could be sent by a proxy also.

So, why would the tracker ignore the IP address sent to it by an application in its GET Request?

Obviously, it is up to the tracker designer to decide whether or not to use the IP address sent in the GET message.

If the Tracker don't use it this means the designer doesn't want a client application to be anonymous, for example behind a proxy.

And obviously, if the Tracker ignore the application sent IP address and if the HTTP incoming IP address isn't application's then the application would simply be non-conectible.

How to handle this situation is a different topic. :)

Link to comment
Share on other sites

http is the application layer.

tcp and udp are the transport layer.

HTTP requests and responses are transported using tcp or udp.

Of course there are dozens of libraries in pretty much every popular language to automatically create sockets and generate the appropriate HTTP using a simplified class. If you are used to 'just writing the GET request and putting in the url and let it go' then you have been using one of these.

But if you want you could do it all yourself by working directly with sockets, this would allow you to do the more advanced stuff like binding outgoing connections to a specific local IP (i.e. interface).

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...