[libtorrent] Unexplained port listening and uTP performance problems.

[sledgehammer999]

A forum user has been experimenting and has discovered a various things
with both latest 1.0.x and 1.1.x.

It is difficult to transfer all info in the mailing list. I will link to
the specifc forum post and I'll summarize here the findings:

Summary:
1. With utp, dht, lsd, pex, upnp/natpmp, ssl port, webui and embedded
tracker disabled libtorrent seems to locally bind to random ports in
addition to the one configure during session construction. Some bind to
127.0.0.1 and some to 0.0.0.0
2. He also conducts performance/speed tests. He has runs too clients in the
same machine(or via VM) and the seeding file is stored in a ramdrive so IO
wouldn't be the bottleneck. He uses uTorrent as the seeding client and
forces it to use only uTP to connect to other peers. Then he enables utp on
qbittorrent and tries to download the file. He has discovered that he
either doesn't have utp incoming connectivity or that the utp connections
performs poorly. uTorrent shows 10% retransmits. Same happens if he
substitutes qbittorrent for deluge. But if substitutes with Tixati or
uTorrent retransmits don't happen.

Much more detail in the posts starting from here:
https://qbforums.shiki.hu/index.php/topic,3982.msg24170.html#msg24170

[Arvid Norberg]

On Sat, Dec 24, 2016 at 5:30 PM, sledgehammer999 <

Post by sledgehammer999
A forum user has been experimenting and has discovered a various things
with both latest 1.0.x and 1.1.x.
It is difficult to transfer all info in the mailing list. I will link to

I finally got around to looking into this.

Post by sledgehammer999
1. With utp, dht, lsd, pex, upnp/natpmp, ssl port, webui and embedded
tracker disabled libtorrent seems to locally bind to random ports in
addition to the one configure during session construction. Some bind to
127.0.0.1 and some to 0.0.0.0

I don't observe this in client_test (in recent RC_1_0 nor RC_1_1) on macOS.

In both versions, with UPnP, NAT-PMP and local peer discovery disabled, on
macOS I get this with client_test:

client_te 26872 arvid 6u IPv4 0x9048993e351110f5 0t0 TCP *:6881
(LISTEN)
client_te 26872 arvid 7u IPv6 0x9048993e2811cd3d 0t0 TCP *:6881
(LISTEN)
client_te 26872 arvid 8u IPv4 0x9048993e25c66b7d 0t0 UDP *:6881
client_te 26872 arvid 9u IPv6 0x9048993e25c6adfd 0t0 UDP *:6881

Which is what I would expect. The UDP socket won't go away by disabling uTP
and DHT since it's also used for UDP trackers.

2. He also conducts performance/speed tests. He has runs too clients in the

Post by sledgehammer999
same machine(or via VM) and the seeding file is stored in a ramdrive so IO
wouldn't be the bottleneck. He uses uTorrent as the seeding client and
forces it to use only uTP to connect to other peers. Then he enables utp on
qbittorrent and tries to download the file. He has discovered that he
either doesn't have utp incoming connectivity or that the utp connections
performs poorly. uTorrent shows 10% retransmits. Same happens if he
substitutes qbittorrent for deluge. But if substitutes with Tixati or
uTorrent retransmits don't happen.

I tried to reproduce this as well, in a slightly different setup I suppose.
I ran uTorrent Mac and client_test on the same machine, seeding a file in
both directions. I used the utp.log instrumentation in libtorrent and did
not discover any retransmits. My test was over loopback, which may have
slightly different behavior though.