First, is it safe to frame the freenet performance issue as: "the rate you get for any particular request is the rate of the slowest/most-congested node in the request chain"?
I ask b/c I seem to recall a target time for streaming CHKs, or something... so the fundamental assumption might be wrong. But if it's not an invalid assumption, I had an idea which might boost performance all-around, but might also effect routing (so it's here for discussion). Basically, it's quite easy to determine what the "average bandwidth" of our peers is, as seen here: https://github.com/Osndok/fred-staging/commit/698591a15061df5896400e46e3439097e92287d5 ...which also defines a function to test if a peer is "above average", maybe letting us try the "fast lane" first (if the request came in on the "fast lane") to try and avoid a slow-down, sorta like: PeerManager::closerPeer(...) { Set<PeerNode> available; available=new ArrayList(connectedPeers()); available.removeAll(routedPeers); if (available.isEmpty()) return null; Set<PeerNode> temp; if (originatingPeer.isAboveAverage()) { temp=pickOutAboveAveragePeersFrom(available); if (!temp.isEmpty()) available=temp; } //... temp=pickOutPeersThatAreNotBackedOff(available); if (!temp.isEmpty()) available=temp; return closestPeerInSet(available, location); } I imagine that the most routing-disruptive case to consider is with 4 peers & 2 above average; b/c you need at least 2 above for the code to do anything (receive from above average, route to above average). Thoughts? BTW, closerPeer is not written in the above format, but shouldn't it be? It seems overly complicated, but if it's optimized for runtime speed (or memory churning, or something in particular) I wouldn't want to step on anyone's toes by wildly refactoring it. -- Robert Hailey
