Changes between Version 4 and Version 5 of Ticket #1587


Ignore:
Timestamp:
Dec 11, 2008, 5:11:24 PM (14 years ago)
Author:
charles
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #1587 – Description

    v4 v5  
    1 There are some stupid bugs in the peer manager which cause it to hold onto nonproductive peers longer than it should.
     1The peer manager has some errors which cause it to hold onto nonproductive peers longer than it should.
    22
    3 (1) It looks at tr_peer.pieceDataActivityDate to decide how long a peer's been idle, even though that variable is never assigned.  In fact, both tr_peer.pieceDataActivityDate and tr_peer.peerSentPieceDataAt should go away.  atom.piece_data_time does everything we need.
     3(1) The manager uses tr_peer.pieceDataActivityDate to decide how long a peer's been idle.  Unfortunately, at some point that variable stopped being assigned any value.  Since atom.piece_data_time does everything we need, tr_peer.pieceDataActivityDate can go away, as can tr_peer.peerSentPieceDataAt.
    44
    5 (2) the minimum timeout period is too high for situations where we are peer-rich.  This is more a judgement call than a bug, but it's true.
     5(2) atom.piece_data_time is incorrectly updated whenever data is sent or received.  it should only be updated whenever ''piece data'' is sent or received.
    66
    7 (3) atom.piece_data_time is incorrectly updated whenever data is sent or received.  it should only be updated whenever ''piece data'' is sent or received.
     7(3) In shouldPeerBeClosed(), idleTime (the time a peer is allowed to be idle) ''increases'' as strictness increases.  It should ''decrease'' as strictness increases.
    88
    9 (4) In shouldPeerBeClosed(), idleTime (the time a peer is allowed to be idle) actually ''increases'' as strictness increases.  It should ''decrease'' as strictness increases.
     9(4) the minimum timeout period is too high for situations where we are peer-rich.
    1010
    11 Blah.
     11These are really stupid bugs. :)