session destructor behavior

Hello,

Starting from revision 4681 behavior of session destructor has been changed:
…
 <at>  <at>  -319,59 +399,55  <at>  <at> 

        // abort the session and let the destructor

        // of the proxy to syncronize

        if (!m_impl.unique())

-           m_impl->abort();

+       {

+           TORRENT_ASYNC_CALL(abort);

+       }

    }
…
so session is destructed asynchronously now.

Is there a way to wait for "real" session destruction (all stopped events
are sent, all threads are stop) ?
Or maybe old behavior (synchronous destruction) should be returned to not
break existing code relying on it ?

Thanks,

Patch to forbid using of system defined port.

Hello,

I propose to add one more useful flag which can be specified for
session::listen_on function: forbid_system_defined_port , this flag will
prevent libtorrent to ask OS to pick a port, so application can exit
immediately if random port has no sense for it.

--

-- 
Alexander

------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb

_______________________________________________
Libtorrent-discuss mailing list
Libtorrent-discuss <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libtorrent-discuss

Patch which makes have_piece method available in torrent_hanle

Hello,

For now the only way to get information about available pieces is
torrent::status(), but it is big overhead if you only want to know
availability of some concrete piece.
I propose to make have_piece method available in torrent_handle, patch is
attached.

--

-- 
Alexander

------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb

_______________________________________________
Libtorrent-discuss mailing list
Libtorrent-discuss <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libtorrent-discuss

disable_hash_check on per torrent granularity proposal

Attached patch allow to disable hash checks per torrent, not per
session as current implementation.
Implementation based on storage_interface as only this interface
accessible inside disk_io_thread via jobs.
Probably should be done on per torrent_handle(torrent) interface but
it requires too and complex deep intervention,
as disk_io_thread subsystem which is responsible for hash checks does
not have access to torrents(handles).

Example, how to use proposed feature:
-------

libtorrent::add_torrent_params p;
p.paused = true;
...
libtorrent::torrent_handle hnd = s.add_torrent(p);
hnd.get_storage_impl()->disable_hash_checks = true;
hnd.resume()

------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb

_______________________________________________
Libtorrent-discuss mailing list

IPv6 on Linux

I'm trying to use libtorrent based client on IPv6 nodes (dual stack).
Unfortunately I can not get it work as libtorrent can not determine
IPv6 interfaces and addresses
in any case. Digging the code I found that ioctl(SIOCGIFCONF) used to
enumerate network interfaces, but it is not applicate for IPv6 at
least on linux
'getifaddrs' should be used instead, see
http://www.kernel.org/doc/man-pages/online/pages/man3/getifaddrs.3.html.
Attached patch solve my situation, it is based and tested on
libtorrent-0.15.4, than ported to trunk compilation only tested.

------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb

_______________________________________________
Libtorrent-discuss mailing list
Libtorrent-discuss <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libtorrent-discuss

Re: IPv6 on Linux

Quoting Kharkov Alexander <kharkovalexander <at> gmail.com>:
> I'm trying to use libtorrent based client on IPv6 nodes (dual stack).
> Unfortunately I can not get it work as libtorrent can not determine
> IPv6 interfaces and addresses
> in any case. Digging the code I found that ioctl(SIOCGIFCONF) used to
> enumerate network interfaces, but it is not applicate for IPv6 at
> least on linux
> 'getifaddrs' should be used instead, see
> http://www.kernel.org/doc/man-pages/online/pages/man3/getifaddrs.3.html.
> Attached patch solve my situation, it is based and tested on
> libtorrent-0.15.4, than ported to trunk compilation only tested.

Thanks! I just checked in this patch (with some minor modifications), in
[5279].

Out of curiosity, how did libtorrent break without this functionality? I thought
only "luxury" features (i.e. non critical ones) relied on this.

--

-- 
Arvid Norberg

------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb

Re: IPv6 on Linux

Arvid,

On Tue, Feb 15, 2011 at 12:31 PM, <arvid <at> cs.umu.se> wrote:

Quoting Kharkov Alexander <kharkovalexander <at> gmail.com>:
> > I'm trying to use libtorrent based client on IPv6 nodes (dual stack).
> > Unfortunately I can not get it work as libtorrent can not determine
> > IPv6 interfaces and addresses
> > in any case. Digging the code I found that ioctl(SIOCGIFCONF) used to
> > enumerate network interfaces, but it is not applicate for IPv6 at
> > least on linux
> > 'getifaddrs' should be used instead, see
> > http://www.kernel.org/doc/man-pages/online/pages/man3/getifaddrs.3.html.
> > Attached patch solve my situation, it is based and tested on
> > libtorrent-0.15.4, than ported to trunk compilation only tested.
>
> Thanks! I just checked in this patch (with some minor modifications), in
> [5279].
>
> Out of curiosity, how did libtorrent break without this functionality? I
> thought
> only "luxury" features (i.e. non critical ones) relied on this.
>

We have a setup when IPv6-only clients (without IPv4 address at all) connect
to the IPv4 tracker using NAT64.
libtorrent was not able to get IPv6 addresses and send them to the tracker
in the announce request.

--

-- 

Re: Patch to forbid using of system defined port.

Quoting Alexander Pauls <apauls <at> mediateka.tv>:

> Hello,
> 
> I propose to add one more useful flag which can be specified for
> session::listen_on function: forbid_system_defined_port , this flag will
> prevent libtorrent to ask OS to pick a port, so application can exit
> immediately if random port has no sense for it.

Thanks for the patch! I made some modifications to it and checked it in to trunk
in [5286].

The main changes I made was changing the name of the flag (to match the existing
flag) to 'session::listen_no_system_port'. I also added a new
session::listen_on() function which returns the error code in case it fails
(which should be a lot more useful than to pop the alert to get the error).

Please let me know if I broke something, or if this change is not enough for
your needs.

--

-- 
Arvid Norberg

------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb

Upgrade howto?

Hello,

sorry for my ignorance but I couldn't find any information about this on the
homepage. 
Is there a "howto" available for developers that shows what has to be
changed to upgrade from 14.x to the 15.x branch?
Also, is there a general overview about the differences of the branches?
I want to estimate the needed time&work prior to starting the upgrading task

BR,
 Michael
------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb

Re: Upgrade howto?

Quoting Michael Schneider <michael.jun <at> web.de>:
> Hello,
> 
> sorry for my ignorance but I couldn't find any information about this on the
> homepage. 
> Is there a "howto" available for developers that shows what has to be
> changed to upgrade from 14.x to the 15.x branch?
> Also, is there a general overview about the differences of the branches?
> I want to estimate the needed time&work prior to starting the upgrading task

Unfortunately there is no document covering the API differences between 0.14.x
and 0.15.x. However, they have been kept as small as possible. For the most
part, when functions have changed signatures, the previous version is still
maintained, so I believe the amount of work to make code compatible with the
0.15 interface should be quite small.

As a test I took client_test.cpp from the 0.14 branch and tried to build it in
the 0.15 branch. There were only two build errors. One caused by the change of
signature of the load_file() function (which is an internal function anyway). 

The second error was caused by the change of the block_info::peer member
changing to a member function block_info::peer(). The block_info objects are
parts of the partial_piece_info type which represents downloading pieces,
queried from the piece-picker.

Both of these build errors are trivial fixes.

The changes from 0.15 -> trunk are larger though. The main change there is
dropping the use of boost::filesystem::path for paths, to use std::string
instead.