Changeset 5105
- Timestamp:
- Feb 25, 2008, 1:35:20 AM (14 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
trunk/libtransmission/peer-mgr.c
r5104 r5105 569 569 uint32_t piece; 570 570 uint32_t peerCount; 571 uint32_t fastAllowed;572 uint32_t suggested;573 571 }; 574 572 … … 587 585 return a->priority > b->priority ? -1 : 1; 588 586 589 /* if one *might be* fastallowed to us, get it first...590 * I'm putting it on top so we prioritize those pieces at591 * startup, then we'll have them, and we'll be denied access592 * to them */593 if (a->fastAllowed != b->fastAllowed)594 return a->fastAllowed < b->fastAllowed ? -1 : 1;595 596 /* otherwise if one was suggested to us, get it */597 if (a->suggested != b->suggested)598 return a->suggested < b->suggested ? -1 : 1;599 600 587 /* otherwise if one has fewer peers, it goes first */ 601 588 if (a->peerCount != b->peerCount) … … 654 641 setme->priority = inf->pieces[piece].priority; 655 642 setme->peerCount = 0; 656 setme->fastAllowed = 0;657 643 setme->random = tr_rand( UINT16_MAX ); 658 644 setme->missingBlockCount = tr_cpMissingBlocksInPiece( tor->completion, piece ); … … 662 648 if( peer->peerIsInterested && !peer->clientIsChoked && tr_bitfieldHas( peer->have, piece ) ) 663 649 ++setme->peerCount; 664 #if 0665 /* FIXME: this code is too expensive! */666 /* The fast peer extension doesn't force a peer to actually HAVE a fast-allowed piece,667 but we're guaranteed to get the same pieces from different peers,668 so we'll build a list and pray one actually have this one */669 setme->fastAllowed = tr_peerMsgsIsPieceFastAllowed( peer->msgs, i );670 /* Also, if someone SUGGESTed a piece to us, prioritize it over non-suggested others671 */672 setme->suggested = tr_peerMsgsIsPieceSuggested( peer->msgs, i );673 #endif674 650 } 675 651 }
Note: See TracChangeset
for help on using the changeset viewer.