Discussion:
[libtorrent] Using adapter name instead of IP to listen to?
sledgehammer999
2016-11-01 17:27:26 UTC
Permalink
I remember that in the past arvid said that we can use adapter names
instead of IPs to listen to.
Is this true? If so, how? Just passing "tun0:6881" to listen_interfaces?

I am trying to provide a possible solution to VPN reconnection problems.
When a VPN connection is dropped, libtorrent traffic is stopped as
expected. But when the VPN connection is reestablished libtorrent doesn't
resume. That's because the new connection has a different local ip and
libtorrent is still listening to the old one.
I think arvid has said that binding by name libtorrent will auto detect VPN
reconnections and resume.
Arvid Norberg
2016-11-02 04:14:39 UTC
Permalink
On Tue, Nov 1, 2016 at 1:27 PM, sledgehammer999 <
Post by sledgehammer999
I remember that in the past arvid said that we can use adapter names
instead of IPs to listen to.
Is this true? If so, how? Just passing "tun0:6881" to listen_interfaces?
Yes, you can do that.

However, as I was pointing out the other day in an issue on github, I don't
feel fully confident in it working reliably (in the RC_1_1 branch). The
socket binding code was generalized and simplified in master, along with
designing it around properly supporting binding to an interface.

In RC_1_1, proper bind to device is only used on linux, where
SO_BINDTODEVICE is defined.

https://github.com/arvidn/libtorrent/blob/RC_1_1/include/libtorrent/enum_net.hpp#L119

If that fails, it enumerates IP addresses of the device and binds to one of
those IPs. That seems to be the limitation of the 1.1.x implementation.

master supports a few more ways of binding to an adapter, but I don't
believe windows has this functionality. It will also fail the bind if an
attempt to bind to a device fails.

Another complication on windows is that device names are GUIDs (or
something that looks like a GUID).

I am trying to provide a possible solution to VPN reconnection problems.
Post by sledgehammer999
When a VPN connection is dropped, libtorrent traffic is stopped as
expected. But when the VPN connection is reestablished libtorrent doesn't
resume. That's because the new connection has a different local ip and
libtorrent is still listening to the old one.
I think arvid has said that binding by name libtorrent will auto detect VPN
reconnections and resume.
As far as I recall, there's no way to tell windows to bind to a specific
device. It's been a while since I did the research and worked on this.
--
Arvid Norberg
sledgehammer999
2016-11-02 15:47:13 UTC
Permalink
Thx for the info. Then this is pretty much limited to linux, I won't be
using it. It'll will create support nightmares from my part when it won't
work as advertised.
Post by Arvid Norberg
On Tue, Nov 1, 2016 at 1:27 PM, sledgehammer999 <
Post by sledgehammer999
I remember that in the past arvid said that we can use adapter names
instead of IPs to listen to.
Is this true? If so, how? Just passing "tun0:6881" to listen_interfaces?
Yes, you can do that.
However, as I was pointing out the other day in an issue on github, I don't
feel fully confident in it working reliably (in the RC_1_1 branch). The
socket binding code was generalized and simplified in master, along with
designing it around properly supporting binding to an interface.
In RC_1_1, proper bind to device is only used on linux, where
SO_BINDTODEVICE is defined.
https://github.com/arvidn/libtorrent/blob/RC_1_1/
include/libtorrent/enum_net.hpp#L119
If that fails, it enumerates IP addresses of the device and binds to one of
those IPs. That seems to be the limitation of the 1.1.x implementation.
master supports a few more ways of binding to an adapter, but I don't
believe windows has this functionality. It will also fail the bind if an
attempt to bind to a device fails.
Another complication on windows is that device names are GUIDs (or
something that looks like a GUID).
I am trying to provide a possible solution to VPN reconnection problems.
Post by sledgehammer999
When a VPN connection is dropped, libtorrent traffic is stopped as
expected. But when the VPN connection is reestablished libtorrent doesn't
resume. That's because the new connection has a different local ip and
libtorrent is still listening to the old one.
I think arvid has said that binding by name libtorrent will auto detect
VPN
Post by sledgehammer999
reconnections and resume.
As far as I recall, there's no way to tell windows to bind to a specific
device. It's been a while since I did the research and worked on this.
--
Arvid Norberg
------------------------------------------------------------
------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Libtorrent-discuss mailing list
https://lists.sourceforge.net/lists/listinfo/libtorrent-discuss
Arvid Norberg
2016-11-02 18:15:40 UTC
Permalink
on windows it will fall back to binding to an IP associated with the
device. So, it will simplify that aspect of it, but if the device's IP
changes, libtorrent would probably have to explicitly be asked to rebind
its ports or restarted for it to reconnect.

On Wed, Nov 2, 2016 at 11:47 AM, sledgehammer999 <
Post by sledgehammer999
Thx for the info. Then this is pretty much limited to linux, I won't be
using it. It'll will create support nightmares from my part when it won't
work as advertised.
Post by Arvid Norberg
On Tue, Nov 1, 2016 at 1:27 PM, sledgehammer999 <
Post by sledgehammer999
I remember that in the past arvid said that we can use adapter names
instead of IPs to listen to.
Is this true? If so, how? Just passing "tun0:6881" to
listen_interfaces?
Post by Arvid Norberg
Yes, you can do that.
However, as I was pointing out the other day in an issue on github, I
don't
Post by Arvid Norberg
feel fully confident in it working reliably (in the RC_1_1 branch). The
socket binding code was generalized and simplified in master, along with
designing it around properly supporting binding to an interface.
In RC_1_1, proper bind to device is only used on linux, where
SO_BINDTODEVICE is defined.
https://github.com/arvidn/libtorrent/blob/RC_1_1/
include/libtorrent/enum_net.hpp#L119
If that fails, it enumerates IP addresses of the device and binds to one
of
Post by Arvid Norberg
those IPs. That seems to be the limitation of the 1.1.x implementation.
master supports a few more ways of binding to an adapter, but I don't
believe windows has this functionality. It will also fail the bind if an
attempt to bind to a device fails.
Another complication on windows is that device names are GUIDs (or
something that looks like a GUID).
I am trying to provide a possible solution to VPN reconnection problems.
Post by sledgehammer999
When a VPN connection is dropped, libtorrent traffic is stopped as
expected. But when the VPN connection is reestablished libtorrent
doesn't
Post by Arvid Norberg
Post by sledgehammer999
resume. That's because the new connection has a different local ip and
libtorrent is still listening to the old one.
I think arvid has said that binding by name libtorrent will auto detect
VPN
Post by sledgehammer999
reconnections and resume.
As far as I recall, there's no way to tell windows to bind to a specific
device. It's been a while since I did the research and worked on this.
--
Arvid Norberg
------------------------------------------------------------
------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Libtorrent-discuss mailing list
https://lists.sourceforge.net/lists/listinfo/libtorrent-discuss
------------------------------------------------------------
------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Libtorrent-discuss mailing list
https://lists.sourceforge.net/lists/listinfo/libtorrent-discuss
--
Arvid Norberg
Continue reading on narkive:
Loading...