[Libtorrent-devel] drops received data when receive rate is not throttled

[a phantom]

running rTorrent 0.6.4 of debian package.

When peer's send is very fast, and still download rate is not
throttled in rtorrent (off or high enough), some data seems
accidentally treated as "queued but forgotten" in despite of actual
data arrival. In result rtorrent requests same data repeatedly and
wastes a lot of band width.

First I thought this is peer clients' problem because it happens
mainly with Mainline 5 peer, but today I found it happens with
uTorrent 1.6.0.0 too.

First queued as normal
    aaaaaaaa
arrives some,
    AAaaaaaa
then suddenly skips.
    AA..AAaa

When that pieces are skipped, status _immediately_ changes to
not-queued (.), I think that's strange. I think even when some piece
is coming out-of-order, it should take some while to become
not-queued.

Once that pieces became not-queued, after some while, "something is
coming but doesn't progress" happens. I guess it's actually receiving
previously skipped data, I feel it takes up some time proportional to
the number of skipped pieces.

It's counted to download rate from that peer and total downloaded
amount in Info, but the download never progresses. As a result, total
downloaded amount goes very high compared to the finished amount,
without any failures.

It seems it doesn't happen if: 1) peer is not so fast to respond, or
2) rtorrent's receive throttle is in action. Lowering receive throttle
to below current receive rate temporally solves the problem. Or
likewise, under constant receive throttle, if other peer's send
increased and total rate has hit the throttle, it goes away too. But
when others decrease, it comes back (oops).

I feel it has nothing with actual receive rate or cpu load or
filesystem load or other activities etc, but my box is somewhat old
slow one, so it's uncertain. But at least actual receive rate (total
or per-peer) varies depending on the peer when the problem arose. With
some peer it goes mad even at 15kb/s. However it may depend on
turn-around time to the peer. That is, too fast, I guess.

kernel is built from debian's linux-source 2.6.18-8 but mm-*.patch
reverted manually.

Is this issue addressed in 0.7 series? I tried looking for ml archive
but couldn't find helpful one. (I wish if there were experimental in
debian experimental...)

Ah, I have some problem with tracker too. I remember this issue is
reported on ml previously but I reforgot the answer (argh!).
Sometime tracker request become stacked at "Connecting to http:", and
it _never_ timeouts, at least for half hour. But when other torrent's
http tracker request has completed, stacked one magically completes
_successfully_ and immediately. I guess it's actually completed at
first time (too fast?) but became unnoticed.
udp request completion doesn't help stacked http request. I seldom use
udp tracker so I don't know udp request can become stacked too.

sorry for bad english... (I'm jp)