[request] Make use of multiple network interfaces

[GoogleCodeExporter]

Relevant qbittorrent wishlist: 
https://github.com/qbittorrent/qBittorrent/issues/639

It seems that Vuze allows the usage of multiple network interfaces to download 
torrents(even single ones). It would be great if this could be implemented in 
libtorrent too.

Original issue reported on code.google.com by hammered...@gmail.com on 9 May 2013 at 8:56

[GoogleCodeExporter]

I am sorry. I didn't search the docs enough.
This seems implemented by torrent_handle::use_interface()
Please close this.

Original comment by hammered...@gmail.com on 9 May 2013 at 9:23

[GoogleCodeExporter]

I have made some attempts to support this well in libtorrent. the main thing 
you cannot do is to bind to a specific device (just IPs). If you come across 
some use case that doesn't work in libtorrent, please let me know.

Original comment by arvid.no...@gmail.com on 10 May 2013 at 2:56

• Changed state: WontFix

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I don't have access to multiple connections myself. I will try to expose this 
setting in qBittorrent and let end users test it. I will report any problems 
here with a new issue.

Original comment by hammered...@gmail.com on 10 May 2013 at 9:45

[GoogleCodeExporter]

I don't think binding by IP is sufficient.  If I understand correctly, this 
would require fixed IP addresses, and I don't know what behavior would occur if 
multiple interfaces each had the same IP address on their respective networks.

DHCP-assigned addresses are probably the norm for most users (especially with 
uPNP easing/enabling port forwarding for that scenario).  In my case, my IPs on 
available networks/interfaces are DHCP-assigned, although I have a reserved IP 
on one network and am ever the only client on the other--so my own IPs--when 
the networks are up--may be effectively fixed.

* A listing of descriptive interface names would probably be best.
* But one other candidate behavior that might be desirable comes to mind:  
Windows monitors network connections and determines when they are unfamiliar.  
Windows Firewall users are then prompted whether the network is public or 
private, and Windows/Windows Firewall saves their decision for future 
connections to that network.  This is a level of abstraction beyond interface 
to _what is the interface connected to?_.  It may be possible to query 
Windows/Windows Firewall for that information (but if it's tightly tied to 
Windows Firewall, the user may not be running the Firewall/may be running 
another firewall...).  It should also be possible to use your own criteria for 
identifying the current network of an interface.   MAC address of DHCP server, 
router or gateway might be a most important factor, possibly also combined with 
SSID for WiFi networks and IP subnet for all networks.  It's debatable whether 
you would want to lock that "network identification" to a specific interface or 
not, as wireless interfaces are mostly interchangeable, as are wired 
interfaces.  The "network id" abstraction is more complicated than just using 
an interface list, but might be most useful for laptop users that are on 
various networks throughout the day (home, work, school, train, cafe, poor 
neighbor's wifi).  A human-readable approximation of the network ID might be 
the SSID and the router name (either advertised by uPNP, DNS, or possibly some 
other protocol).
* Actually, a scenario where it would be desirable to include the network 
interface as a criteria either alone (as I began my recommendations) or coupled 
with the network identification, would be when you are using multiple wireless 
or wired connections to the same network.  This might come up if the network 
has a wideband WAN interface and the user has several independent LAN/WiFi 
connections enable to capture as much of the WAN bandwidth as possible, even 
though their individual links are each slower than the available WAN throughput.

Original comment by a...@lovetour.info on 11 May 2013 at 10:20