arvid | 5 Jul 19:32 2015

RFC: checking and auto-managed torrents

In libtorrent 1.0 I "simplified" the handling of paused and auto-managed 
torrents. It turns out that perhaps it opened up some other problems.

Basically, the way it used to work was that a torrent could be paused or 
started, and auto-managed or not auto-managed. Auto-managed means 
libtorrent is responsible for deciding whether it's a good idea to start 
it or pause it. A torrent that needed checking of its files would be 
queued up to be checked, one at a time, regardless of whether it was 
paused or not. It was a bit hard to control since only ever a single 
torrent would be checked at a time and there was no way of pausing a 
torrent that was being checked (i.e. stop checking it).

What I did in libtorrent 1.0 was to make the paused state apply to 
checking torrents as well. This made it possible to check multiple 
torrents in parallel (which especially makes sense if they are on 
separate drives) and the auto-manage logic also applied, and it 
implemented the queue and one-at-a-time checking.

So, in 1.0, adding a torrent that needs checking will queue it up just 
like before, if it's auto managed. If the torrent is started and not 
auto-managed (force started) it will be checked immediately 
unconditionally. If it's added paused and not auto-managed (force 
stopped) it will not be checked until it's started.

The behavior for non auto-managed torrents is thus significantly 
different than what it used to be. Specifically, the (perhaps 
unintuitive) behavior is that all torrents are checked in parallel, 
which is typically not desirable. Another quirk is that paused torrents 
are not checked, even if there's no other torrents being checked. This 
defers the cost until the torrent is started, delaying it from actually 
(Continue reading)

Ricky Huang | 2 Jul 20:20 2015

Connecting to IPv6 peers

Hello all,

I know there is IPv6 support in libtorrent since pre-1.0 but what I noticed is that I have never encounter any
IPv6 peers.  I am wondering if I need to have the session listen_on() an IPv6 address in order to communicate
with IPv6 peers or will it work in some kind of dual mode?

Sorry if the question sounds dump, but I am clueless when it comes to IPv6 space.

Thanks for your time.
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
sledgehammer999 | 1 Jul 15:52 2015

Files priorities aren't saved for completed files?

I am not sure if this is a bug in qBittorrent or on libtorrent. I have been
compiling various versions of libtorrent and qbittorrent and the results
are mixed.

Most of the time if:
1. You have a multifile torrent that is fully downloaded
2. You change the priority of one file
3. Query the priority of that file

You'll always get 1. And of course the same value is saved in the fast
Is this a bug or intended?

PS: I have mixed results with incomplete files.
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
gma625 | 17 Jun 18:27 2015

Receving Lots of "Resource remporarily unavailable"

I'm experiencing lots of error as follows, do you have any idea on this 

This error come out several times in a seconds. 
Libtorrent-discuss mailing list
Libtorrent-discuss <at>
Jimmy Selling | 18 Jun 16:18 2015

SSL Handshake failing

So I tried to connect to my client_test.exe with openssl s_client and I get a very strange error.

Loading 'screen' into random state - done
15536:error:140790E5:SSL routines:ssl23_write:ssl handshake failure:.\ssl\s23_li
no peer certificate available
No client certificate CA names sent
SSL handshake has read 0 bytes and written 347 bytes
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated

When I check my logs on the client I can see that s_client have tried to connect but been interrupted for some reason.

[Jun 18 15:27:48]  -  peer (, Unknown) peer error [ssl_handsh
ake] [asio.ssl]: clienthello tlsext

Any suggestions? Are you able to connect with this?

Btw, the way I build libtorrent is:
# b2 toolset=msvc-12.0 boost=source encryption=on crypto=openssl
Is this correct?
(Continue reading)

Georg Rudoy | 18 Jun 02:02 2015

state_update_alert::status fields

Hi there,

What fields are filled (as in torrent_handle::status_flags_t) in
torrent_status returned with state_update_alert in response to



  Georg Rudoy
Jimmy Selling | 17 Jun 16:29 2015

Debugging SSL connection

Tjaba Arvid,

So I am still having some issues with SSL torrents and would need some advice when it comes to debugging this.

The peers seems to see each other but they can't talk for some reason. When I open the logs I see:

 UDP error: An existing connection was forcibly closed by the remote host from:
 peer (, Unknown) peer error: short read

What I get from googling is that the clients doesn't open the expected UDP ports.

When I run with "normal" torrents and not SSL torrents this works as expected.

Do you have any suggestions on how to debug this?

best regards

gma625 | 16 Jun 10:23 2015

Bug Report, File routing_table.cpp


I'm using libtorrent 1.0.4, I found the following code in function 

node_entry const* routing_table::next_refresh()

for (bucket_t::iterator j = i->live_nodes.begin()
, end(i->live_nodes.end()); j != end; ++j)
// this shouldn't happen
TORRENT_ASSERT(m_id != j->id);
if (j->id == m_id) continue;

if (j->last_queried == min_time())
bucket_idx = idx;
candidate = &*j;
goto out;

                        if (candidate == NULL || j->last_queried < candidate->last_queried)
candidate = &*j;
bucket_idx = idx;

(Continue reading)

arvid | 14 Jun 22:18 2015

the wait is over [github]

Last weekend I transitioned the libtorrent repository to github:

I've set up travis and appveyor CI jobs (but there are still
some configuration issues, and some tests are not reliable yet).


Arvid Norberg

Steven Siloti | 14 Jun 19:18 2015

Persistent credit v5

A relatively small update this time. This is mostly to update the patch 
set for the latest trunk. There is one fix for the direct download 
credit multiplier being incorrect in some cases.

Also note 89f33bd is a deadlock fix not directly related to the 
reputation extension.

You can find the code here:

Stanislav Polozov | 12 Jun 11:04 2015

Torrent enhancement - new technology to store magnet links


We have a new technology that essentially increases the functionality and
usability of torrents and other p2p networks - a free service which allows
to place magnet links fully anonymously, without possibility to block,
delete or change.

The engine of the service is based on distributed database (block chain)
which cannot be blocked or somehow changed by any external force except of
the owner of the link.

This enhancement will give a new spin off for torrents or any other p2p

The description of the service is here (see "Magnet").

We will be glad to answer to your additional questions and to help to
implement it in your software.

Best regards,
Stan Polozov
CMO of Emercoin Team
info <at>