Haxe wrote: > Over the recent months (possibly even a year or so), I have seen my > upload volume declining from what was once a high load to a mere > dribble. I consider this a real problem, because I really like to share > my files to the net, to give back value to the gnutella network. If > this doesn't work, this is bad.
I my opinion, spam et al. is responsible for most of the problems. There are certainly many other issues but the amount of spam is so incredible that is overshadows everything else. Even if you filter all of it, it still causes congestion and exhausts resources. Currently, Gnutella is in a very, very bad shape. Also failures are very intermittent. Some days it still works like a charm and the next day, you get no results at all except for the most popular mainstream content of course. > The decrease in my upload volume seems to be a superposition of several > independent effects. The most visible step happened when I once cleared > my host caches, causing a re-bootstrap, which lead to BearShare > ultrappers completely vanishing from my view. I knew that this would > happen, because some of you developers said that BearShare was no > longer listed in the more modern bootstrap databases. But now that my > host cache has re-matured for some months, BearShare ultrapeers still > didn't come back. Spam isn't the only problem of course. Another is US American ISPs which block Gnutella. We have worked around most of that but others have not. Though gtk-gnutella does not support LimeWire's UDP-based transport protocol. The only other client which supports it is BearShare, as far as I know. This may very well reduces the chances that people download from you. > Question: Why is this so? Even if BearShare ultrapeers are no longer > listed in the bootstrapping databases, shouldn't they appear in my > cache after some network use? The island effect has probably increased but I still see BearShare peers. Though the old versions cannot handle large query routing tables (only up to 1 MiBit) and newer versions seem to be severely crippled by the owner (iMesh). Most-likely it does not allow download of ogg files and other unprotected formats at all. > Question: Is there nothing we could do on our own to prevent BearShare > from vanishing into their own island? This would obviously be bad for > all of us. The only good feature in BearShare is that it supports searches by hash unlike LimeWire. BearShare, Gnucleus and others are a major PITA when it comes to non-ASCII searches because they have been broken for several years now and never caught up. > Nowadays, all my connections are to LimeWire ultras. This doesn't sound > bad, but I realize that with these ultras, as opposed to the BearShare > ultras that used to fill my slots before, there are now fewer searches > reaching my leaf (Query(RX)), and even fewer hits sent out by my leaf > (QHit(TX)). I tend to consider these numbers, especially the latter > one, a quality measure for a given UP connection, because I like to get > my upload slots used. > Question: Why do LimeWire ultrapeers send me much fewer searches than > Bearshare once did? LimeWire has very little automagic. As far as I know, BearShare emits queries periodically and also queries by SHA-1 to gather sources if a download gets stuck. I don't know whether LimeWire even restores searches on startup. Also LimeWire uses tiny query routing tables (thanks to Java) which probably force them to do be very paranoid about query frequency and flow control. As LimeWire did not support any IP address block lists until a few weeks ago a lot of traffic was wasted for spam. I cannot really imagine using Gnutella without banning a least the worst offenders, so I wonder how LimeWire still has any users at all. When BearShare was still maintained, there block lists where quite up to date, so the network quality was much higher than now. Of course the spam has increased a lot as well. > But there seems to be going on more than just the difference between LW > and BS UPs. I think I have also noticed a much smoother decline in my > uploads that adds to the sharp break described. Over the last months, > there seems to be less and less demand for my shared files. > One possible reason could be that I only share ogg files. But I have > done so since day one, nothing has changed. Many people probably add "mp3" to their query or drop anything but that. For what it's worth, there is even ogg spam coming from swedish machines. If that was the first time people downloaded an ogg file, it's likely the last time. mp3 files simply have more sources and are more comfortable due to the wide support in software and hardware in contrast to ogg. I'd say there is not a single dominating factor (except spam maybe) but a lot of things add up. > Question: Could it be possible that some major gnutella client hides ogg > files from their users in newer versions? Newer BearShare (>= 5.2 and especially >= 6.0) might. I have never used LimeWire, so I cannot tell how Gnutella looks from that point of view and whether it treats ogg and mp3 equally. It's possible that due to the low amount of ogg files that their "learning" spam filter tends to drop those but that's just a thought, I don't know. > On a related note, but not exactly matching the "something has changed" > pattern above, I have also noticed that, after I successfully > downloaded a file, I seem to disappear from the mesh unnecessarily > fast. About one hour or so after I finished a download, I can be sure > that there is noone left who wants to download that file from me. You would have to explicitely share files after you downloaded them to stay in the mesh. > Question: Why is this so? Shouldn't I stay in the mesh forever after I > downloaded a file? It is one of bittorrent's strengths that downloaders > seed a file infinitely if they don't explicitly decide otherwise. > Shouldn't it be the same on gnutella? BitTorrent has completely different usage patterns. The differences in the protocols do not matter much. The likelyness that someone downloads bad content through BitTorrent is (at least for now) very low. Automagically sharing downloaded files forever might make things worse. For example spam could spread extremely fast. Then again, it would also help the good content of course. It wouldn't be too difficult to add this feature. There are some awkward details though. Should these files be shared just like any other files i.e., reported in search results? Or maybe only reported to SHA-1 searches? Regarding the download mesh, it's not really very smart. For example, we never try to check whether those sources still work. They just expire after some time. That means often they expire too soon and other times they expire too late. But we cannot manage a mesh for hundreds or thousands of files because that would eat up all bandwidth. With BitTorrent you typically just manage a very few files, often just a single one. I'm currently trying to add support for LimeWires HEAD ping/pongs which are similar to HTTP HEAD requests but use UDP instead. This isn't as wasteful as TCP connections and also supports use of PUSH proxies for firewalled peers. This allows exchanging alternate locations and checking of the availability of files. Supporting this passively is not much of a problem. The question is how to use this actively then. > So, it all boils down to "where are my uploads gone"? Something is > really suboptimal and should be fixed. But what ist it, exactly? That's pretty much impossible to answer because there are so many factors. There is really no other way than to analyze every single information you can get. That means you'd have to look at all log messages to search for bugs and incompatibilities. You would have to analyze how the software and users behave. -- Christian ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Gtk-gnutella-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel
