Official LimeWire 4.1 requests thread

[verdyp]

If you want to contribute, there's a Chord subproject in LimeWire, which is stale since long and experimental, but can be the base of such search architecture for unique IDs.
In Chord, some hosts are responsible of managing routes for some "fingerbits". Those hosts should better be UltraPeers (they need to have long availability to minimize the cost of structure updates), but for now we don't have enough UltraPeers with the latest version to allow deploying this parallel network.
Now that LimeWire 4.0 will be officially released and that it will clearly demonstrate an advance of efficiency in Gnutella searches with a much reduced bandwidth usage, the LimeWire cluster of UltraPeers could become a good candidate to start experimenting with Chord (or other structured topologies).
Before that we need to see the impact on Gnutella of the deployement of LimeWire 4.0. The next weeks will be used to monitor the evolution of traffic and see how much we can gain on the overall network (and as well take the time to correct or fine tune some statistical or usage policy parameters).
For now, I'm not inclined to change the QRP algorithm and routing. It's probably better to think about a parallel topology with separate routing tables for such searches by URNs.
QRP has been done and tuned mostly for keyword searches, with a very weak distribution of keywords.
Including URNs in QRP had a negative impact on routing efficiency (but it has been compensated by the introduction of the low-TTL/high-degree topology in association with dynamic querying).
My opinion is that, if we can remove URNs from QRP tables, the network will be better, but we can't do that before a new more appropriate routing topology is made and tested for URNs, and then deployed, tuned and scaled.