Local Peer Discovery idea: prioritize LPD requests for downloads

[User294]

I given a try to LPD and I noticed one issue:
When I start download and I'm seeding other files (some other ~100 torrents), Transmission would take a while to announce all things via LPD. Actually, for 100 torrents it would take almost hour or so.

As for me, most of times it would happen that download is completed by usual means without single LPD request issued for running downolad, hence no chance to speed things up at all and/or reduce external traffic for ISP, so LPD is mostly useless for me (at least, it does not grants any gain for me or my ISP).

Idea is: maybe you can prioritize torrents in "downloading" state over torrents in "seeding" state when scheduling LPD announces to increase chance of hitting a local peer(s) while downloading, hence reducing external network traffic and speeding up download(s)? In current state I found no obvious gains from LPD in ethernet-based network. Most of times file downloads within hour so there is no LPD requests for that file at all and rather requests for files I'm seeding.

Note: actual version is recent 1.93+, but there is no such version in Version list.

[Eszet]

Thanks for your report! Admittedly, the LPD patch is rather conservative wrt to timings to prevent a local net from being flooded with announce messages (as you can see, people really seem to have lots of torrents active ;)). Your scenario is a somewhat "extreme" case where your external bandwidth allows downloads to be completed faster than a single LPD announce cycle for a large queue of torrents, but its definitely a scenario where we don't want LPD to "fail".

I'd see a rather simple way to prioritize downloads by:

• lowering the LPD housekeeping interval to, say, 5 seconds (from 30s)
• giving seeds some kind of "announceAt" factor (for example twice as long for seeding torrents)

The first point increases the maximum frequency for announces (allowing more torrents to be announced in a shorter time), which is indicated here at any rate. I'm not quite prepared to go down to 1 second (the DHT interval the LPD HK interval gets derived from) just yet. The second proposal schedules downloads earlier in the timeline; yet, eventually the code will also announce seeds. I guess we would have to test this modification in your environment to see if it solves your problem while preserving Transmission to be a good network citizen in general.

[Eszet]

I forgot to mention that all torrents are scheduled for announcement right when Transmission starts up. So the immediate problem can be resolved just by shortening the HK interval. Nevertheless, priorities for LPD announces in general may have positive effects across a variety of other use cases.

[Eszet]

First proposal for downloads to have priority before seeding torrents (minimal approach)

[User294]

So the immediate problem can be resolved just by shortening the HK interval.

The "only" problem is that excessive broadcasts may lead to port blocking on ISP-grade switches which are smart enough to apply broadcast storm protection. It is known issue with uTorrent that some customers have reported that ISP's switch has blocked their port due to excessive broadcasts when LPD is active. So do not reduce LPD housekeeping too much, else you will face the same reports. I'm suspect that 5 sec is OK but lower than that seems to be risky.

[Eszet]

That's right... however, I'd like to point out that we are talking about multicast messages here. It's these very 5 (or be it 10) seconds interval for housekeeping that poses a lower limit to corner cases, such as the one we're discussing. In fact, the LPD module cannot come up with a storm of messages, by design.

Usually, torrents get announced every 4 minutes (resulting in much less frequent announce messages); so in reality this is a much of a non-issue for most people who have < 10 or so downloads.

Conversely, if you know your ISP is sensitive wrt to multicast traffic, maybe you should have an eye on running an excessive number of concurrent torrents (in other words, the LPD protocol was certainly not designed for propagating information this way and, quite naturally, its use degenerates towards infinity, if you will :).

[jordan]

This ticket has been idle for 8 months... is discussion on this feature finished? Is it still a desirable feature?

Block requests vary per-peer based on the how much bandwidth the peer has been using recently, so local network peers should automatically get more requests to try & use all the available bandwidth. I'm not sure it's necessary to write a patch to make this explicit.

[Eszet]

User294 has a point here. Transmission users with a lot of torrents will get into trouble never seeing a LPD peer announce if the download has already completed via conventional announces before.

I propose to port the original patch to trunk, in order to run a regression if normal users have a problem with the modified (ie., weighted) announce intervals. Anyway, in most cases anyone should notice much of a difference; except for high-volume (> 100 torrents) users who should see an improved behavior.

-Eszet

[jordan]

Sounds like a good idea to me.

r12093 libtransmission/ (announcer.c tr-lpd.c): (trunk libT) #3208 "Local Peer Discovery idea: prioritize LPD requests for downloads" -- add patch from Eszet

[Eszet]

Great!

Cheers,
-Eszet