headers
arvid | 1 May 2010 19:45
Picon
Picon
Favicon

Re: Assertion failures when using add_piece

Quoting Henry Rodrick <moshisushi <at> gmail.com>:

> Hello list!
> 
> I have problems with various libtorrent assertions failing when using
> add_piece. I've included the patch I temporarily use to get around them.
> Looks like they assert things that are no longer valid when adding pieces
> from more places than the piece_picker (i.e add_piece).
> The assertions typically fail when i do alot of add_piece and there are
> seeders in the swarm.

Could you try to see if this patch makes it work for you? I'm checking this in
to 0.15 and trunk as well.

Index: branches/RC_0_15/src/piece_picker.cpp
===================================================================
--- branches/RC_0_15/src/piece_picker.cpp	(revision 4495)
+++ branches/RC_0_15/src/piece_picker.cpp	(working copy)
 <at>  <at>  -2134,7 +2134,10  <at>  <at> 
 			info.peer = peer;
 			if (info.state == block_info::state_requested) --i-≥requested;
 			TORRENT_ASSERT(i->requested >= 0);
-			TORRENT_ASSERT(info.state != block_info::state_writing);
+			if (info.state == block_info::state_writing
+				|| info.state == block_info::state_finished)
+				return;
+
 			++i->writing;
 			info.state = block_info::state_writing;
(Continue reading)

Permalink | Reply | 3 comments |
headers
Henry Rodrick | 4 May 2010 17:19
Picon

Re: Assertion failures when using add_piece

On Sat, May 1, 2010 at 7:45 PM, <arvid <at> cs.umu.se> wrote:

> Quoting Henry Rodrick <moshisushi <at> gmail.com>:
>
> > Hello list!
> >
> > I have problems with various libtorrent assertions failing when using
> > add_piece. I've included the patch I temporarily use to get around them.
> > Looks like they assert things that are no longer valid when adding pieces
> > from more places than the piece_picker (i.e add_piece).
> > The assertions typically fail when i do alot of add_piece and there are
> > seeders in the swarm.
>
> Could you try to see if this patch makes it work for you? I'm checking this
> in
> to 0.15 and trunk as well.
>
> Index: branches/RC_0_15/src/piece_picker.cpp
> ===================================================================
> --- branches/RC_0_15/src/piece_picker.cpp       (revision 4495)
> +++ branches/RC_0_15/src/piece_picker.cpp       (working copy)
>  <at>  <at>  -2134,7 +2134,10  <at>  <at> 
>                         info.peer = peer;
>                        if (info.state == block_info::state_requested)
> --i-≥requested;
>                        TORRENT_ASSERT(i->requested >= 0);
> -                       TORRENT_ASSERT(info.state !=
> block_info::state_writing);
> +                       if (info.state == block_info::state_writing
> +                               || info.state ==
(Continue reading)

Permalink | Reply | 2 comments |
headers
Henry Rodrick | 4 May 2010 18:41
Picon

Re: Assertion failures when using add_piece

On Tue, May 4, 2010 at 5:19 PM, Henry Rodrick <moshisushi <at> gmail.com> wrote:

> On Sat, May 1, 2010 at 7:45 PM, <arvid <at> cs.umu.se> wrote:
>
>> Quoting Henry Rodrick <moshisushi <at> gmail.com>:
>>
>> > Hello list!
>> >
>> > I have problems with various libtorrent assertions failing when using
>> > add_piece. I've included the patch I temporarily use to get around them.
>> > Looks like they assert things that are no longer valid when adding
>> pieces
>> > from more places than the piece_picker (i.e add_piece).
>> > The assertions typically fail when i do alot of add_piece and there are
>> > seeders in the swarm.
>>
>> Could you try to see if this patch makes it work for you? I'm checking
>> this in
>> to 0.15 and trunk as well.
>>
>> Index: branches/RC_0_15/src/piece_picker.cpp
>> ===================================================================
>> --- branches/RC_0_15/src/piece_picker.cpp       (revision 4495)
>> +++ branches/RC_0_15/src/piece_picker.cpp       (working copy)
>>  <at>  <at>  -2134,7 +2134,10  <at>  <at> 
>>                         info.peer = peer;
>>                        if (info.state == block_info::state_requested)
>> --i-≥requested;
>>                        TORRENT_ASSERT(i->requested >= 0);
>> -                       TORRENT_ASSERT(info.state !=
(Continue reading)

Permalink | Reply | 1 comment |
headers
Henry Rodrick | 4 May 2010 20:58
Picon

Re: Assertion failures when using add_piece

Sorry for spamming the list today, but I just got the

TORRENT_ASSERT(p->blocks[block].buf == 0)

assertion again. It's very rare but i can get it with heavy torrent traffic
+ add_piece.

Any ideas what's causing this?

Thanks,
Henry
------------------------------------------------------------------------------
Permalink | Reply | 0 comments |
headers
imin imup | 11 May 2010 17:16
Picon

torrent announced before port mapping finished

Hello Arvid,

As port mapping may take seconds to finish, I found some torrents can be
loaded and announced before port mapping is finished. It is desired to load
the torrent after port mapping is done, no matter successfully or not. Here
are 2 questions:
#1. How can I know from library that if the peer is nat-ed or not?
#2. If it is nat-ed, can I rely on either port mapping success alert or
failure alter? i.e., one of two alert must happen.

Best
Imin
------------------------------------------------------------------------------
Permalink | Reply | 0 comments |
headers
Max | 19 May 2010 11:58

add off-torrent support

hi i want to suggest to add support in your lib for off-torrents
http://offload.sf.net
torrent starts not with magnet, but with http..

suggestions?

------------------------------------------------------------------------------
Permalink | Reply | 2 comments |
headers
arvid | 20 May 2010 00:42
Picon
Picon
Favicon

Re: add off-torrent support

Quoting Max <petersonmaxx <at> googlemail.com>:

> hi i want to suggest to add support in your lib for off-torrents
> http://offload.sf.net
> torrent starts not with magnet, but with http..

>From what I can tell, the off network is very different from bittorrent. I can't
even find any documentation of the protocol.

--

-- 
Arvid Norberg

------------------------------------------------------------------------------
Permalink | Reply | 1 comment |
headers
Max | 20 May 2010 00:55

Re: add off-torrent support

hi arvid
thanks for the feedback, off has less documentation yes
you might look here too http://offsystem.sf.net but you need to know the client
which button does what. the client is http://offload.sf.net
which does not share the urls on the same network
an OFF-Torrent looks like these:
http://dooble.sourceforge.net/doobledownloads/directory.php
(which are just examples, they are outdated torrents)
you can implement the library additionally as a parallel support in
your core lib?
thanks

On Thu, May 20, 2010 at 12:42 AM,  <arvid <at> cs.umu.se> wrote:
> Quoting Max <petersonmaxx <at> googlemail.com>:
>
>> hi i want to suggest to add support in your lib for off-torrents
>> http://offload.sf.net
>> torrent starts not with magnet, but with http..
>
> From what I can tell, the off network is very different from bittorrent. I can't
> even find any documentation of the protocol.
>
> --
> Arvid Norberg
>

------------------------------------------------------------------------------
Permalink | Reply | 0 comments |
headers
Endeer | 24 May 2010 03:17
Picon

Full preallocation

Hello,

  I have encountered a problem regarding very bad performance of files
downloaded using libtorrent (via deluge). The files are heavily
fragmented, random file I looked at used around 1100 fragments to
store 1GB of data. Originally I thought it was a problem of deluge,
but then I learned the third mode of libtorrent isn't what I hoped
for, as it's again a sparse mode, just with pre-setting file size.

  I'm not sure if it would be a good idea to "fix" the third mode, or
better to add fourth full-preallocation mode, but from what I've tried
just using fallocate(m_fd, 0, 0, s) instead of ftruncate(m_fd, s) in
function file::set_size() helps matters greatly. On XFS (which I use),
the files are preallocated instantly, are not sparse files and do not
have performance problems as they only occupy one or at most a few
fragments. 

  There's also posix_fallocate(m_fd, 0, s) which may work on more
platforms/filesystems, given that it emulates the behaviour by
writing zeroes for filesystems which don't support it natively.

  Maybe I could dig into a solution for Windows too, though not sure I
have all the devel tools required.

--
Live long and prosper,
Endeer

------------------------------------------------------------------------------
(Continue reading)

Permalink | Reply | 1 comment |
headers
arvid | 25 May 2010 08:20
Picon
Picon
Favicon

Re: Full preallocation

Quoting Endeer <f <at> endeer.cz>:

> Hello,
> 
>   I have encountered a problem regarding very bad performance of files
> downloaded using libtorrent (via deluge). The files are heavily
> fragmented, random file I looked at used around 1100 fragments to
> store 1GB of data. Originally I thought it was a problem of deluge,
> but then I learned the third mode of libtorrent isn't what I hoped
> for, as it's again a sparse mode, just with pre-setting file size.
> 
>   I'm not sure if it would be a good idea to "fix" the third mode, or
> better to add fourth full-preallocation mode, but from what I've tried
> just using fallocate(m_fd, 0, 0, s) instead of ftruncate(m_fd, s) in
> function file::set_size() helps matters greatly. On XFS (which I use),
> the files are preallocated instantly, are not sparse files and do not
> have performance problems as they only occupy one or at most a few
> fragments.

full_allocation mode is supposed to do allocate the files, with whatever means
are available on each platform.

looking at set_size() (in RC_0_15 branch), it tries:

SetFileValidData() on windows.

on non-windows, it starts off with ftruncate(), then tries
fcntl(m_fd, F_PREALLOCATE, &f) on BSD, then fallocate() on linux. If that
still hasn't worked, it uses posix_fallocate() as a last resort.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane