Opened 12 years ago

Closed 12 years ago

#3113 closed Enhancement (wontfix)

Prune peer list/Close connections to slow peers

Reported by: ShaggyRed Owned by:
Priority: Normal Milestone: None Set
Component: Transmission Version: 1.92
Severity: Normal Keywords:


Transmission seems to fair poorly on Mac OS and possibly other OS's when downloading from large numbers of peers. The UI recommends no more than 200 peers total, and this can place a limit on torrent performance.

I understand that supporting a large number of peers may not be an easy thing to do on a lot of systems, so instead why not have an option that periodically closes connections to peers that fail to send/receive any data at all.

My peers lists seem to be filled with lots of totally inactive peers, and yet there's not even an UI option to select a group of connections to close.

The option to close a selected group of connections manually would be step 1. But one could imagine a fully automated mechanism that runs on a timer every 30-60 seconds to kill all peers who have not transmitted or received any data at all for the entire duration of their connection.

Change History (5)

comment:1 Changed 12 years ago by livings124

  • Resolution set to wontfix
  • Status changed from new to closed

Transmission does attempt to drop "bad" peers, and does apply criteria to pick the best peers. Unfortunately, dropping peers and assuming better peers will connect is not always the best solution. Manual peer management is something we don't want in the app - it's bloat that most won't use and might result in worse performance for those that do. The UI recommends 200 peers because most systems/routers can't handle much more - that's really outside of our control.

comment:2 Changed 12 years ago by ShaggyRed

  • Resolution wontfix deleted
  • Status changed from closed to reopened

I fail to see how dropping a peer that has never transmitted or received any data for the lifetime of its existence after an extended period could actually harm performance. I see my peer lists filled with tons of non-transmitting peers. More than half the list being dead seems typical.

Or do you just mean that this logic already exists via some other mechanism? Is that documented anywhere? Or can you point me to the relevant code sections?

I am a developer with some networking experience and am curious why I have so many bad peers if there is already logic to prune them/select them "intelligently".

comment:3 Changed 12 years ago by livings124

It does exist to a degree (as far as I'm aware). Of course, the app can't just drop peers - who knows if they might send data later, and if they'll be replaced by a peer if dropped. We would love a patch to improve the logic of this. A good starting point is peer-mgr.c.

comment:4 Changed 12 years ago by livings124

ShaggyRed?: Anything to report?

comment:5 Changed 12 years ago by livings124

  • Resolution set to wontfix
  • Status changed from reopened to closed

Please reopen if you have a patch or any new info. Otherwise, I stand by my posts.

Note: See TracTickets for help on using tickets.