Thanks for the link -- I took a first pass, and will study in more detail, but at first blush it seems that the issue described in the forum discussion you've pointed me at is about the negative impact of "auto-requeries" (auto searching) which I agree with and don't suggest be changed for magnets. The problem at the moment with regard to Limewire's handling of magnets is that it never actually sends out a first query in the first place (other than to the IP address specified by xs, which will almost always fail on a dynamic p2p network since IP addresses change frequently and host computers come and go continually). So I think we're saying the same thing in terms of the bandwidth issues and auto-requeries (auto search) -- don't use auto-requeries for magnets at all, but simply do a single initial query based on the xt=urn:sha1: info so that the process of clicking on a magnet and having it at least start the download (if possible) is seamless and reliable.

So rather than support auto-requeries it's only a matter of Limewire doing a single query in the first place using the xt=urn:sha1: info instead of relying on the http:// IP host info provided in xs. This would be the equivalent of doing a single search, but in this case for a specific file. If that search fails to turn up any files then don't do an auto-requeries, but instead require the user can click on "Find More Sources" as usual. The problem is that currently the first search doesn't take place at all, other than for the http:// on a specific IP addresss specified by xs.

Since the proposed fix doesn't require auto-requeries, won't create large amounts of traffic, and is only needed to properly process a magnet links would Limewire do that?

Aaron