Changes between Version 4 and Version 5 of Ticket #1587
- Timestamp:
- Dec 11, 2008, 5:11:24 PM (14 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #1587 – Description
v4 v5 1 The re are some stupid bugs in the peer managerwhich cause it to hold onto nonproductive peers longer than it should.1 The peer manager has some errors which cause it to hold onto nonproductive peers longer than it should. 2 2 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. 4 4 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. 6 6 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. 8 8 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. 10 10 11 Blah. 11 These are really stupid bugs. :)