I managed to confirm today that my relatively slow connection has nothing to do with my lack of getting significant hosts lately. I did this when i used my college's much better line earlier today, with the same results I achieved at home.

This leads me to put more stock in my previous theory--that gnutella is having major problems for two reasons.

1)people using insane numbers of connections

2)There is a client compatibility issue--supported by the strange ascii strings witnessed in the search monitor.

Also I have noticed seriously absurd numbers of files, in the billions, which again may be a client compatility issue, or may be a new form of spamming which has been as of yet unidentified. I will try to note particular ip's with this anamoly.

I believe all of these factors relate to why host info isn't registering properly, and more importantly why searching is largely uneffective.

Someone mentioned earlier about gnotella tacking on extra bytes to the packets, but i don't think this is the problem since i manage to get the same results no matter what client I use. If anything it's merely a matter of efficiency, nothing more.

I have had the opportunity to try this with different types of machines, with both different hardware configurations and speeds, both having the same results. This again leads back to my compatibility theory.

I wonder how much that java client is affecting things as well?

Thoughts? comments?

[This message has been edited by DarthGummiBear (edited 09-06-2000).]

The only odd behavior I've noticed on Furi (the java client) is with its Chat feature... Not IRC but the built-in chat. Most of the time, the stuff that shows up in the chat window comes in the form of huge binary packets instead of chat messages. I have successfully chatted with people on a couple of occasions but most of the time I just see junk.

I'm not sure how Furi distinguishes (or triest to distinguish) Furi chat packets from other data on the network. I've also heard that one of the clients (I don't remember which) determines the bitrate of shared MP3s and sends that data out with query replies. AFAIK neither of these "extra" data fit the spec, which calls for an exact format for the different packets.

In other words, it's impossible to say just who's responsible, but I do think bad packets are contributing to the lack of serach results. I think I've found another key problem as well but I'm still doing some testing.

Shaun

No solutions, since I lack the technical savvy, but only a confirming observation. I will suddenly (not gradually) see file numbers in the hundreds of billions. As time passes, searches become gradually less effective and cease altogether after about an hour. My conjecture is a deliberate attempt to disrupt the system by data overload. Or some spamming enterprise gone awry. Or simply bad juju.

Looking at the search monitor today, about half of the searched were extended acii characters. Also, i haven't been able to get a search result over the past few week, and have seen less and less upload.

I suppose there are not a few people with some interest in seeing that networks like this do not succeed.

If what you say about furi chat packets is true, Shaun, than that could very well be part of the problem--how would other clients such as gnotella and toadnode be able to tell the difference between regular gnotella packets and the chat packets?

I haven't used furi yet--do those chat packets go through the network? Or are they direct between furi clients?

As much as some of you may like the variation in clones, I think it is ultimately detrimental to the network as each client adds its own "special touch" to its packets. No matter how you look at it, all that extraneous data coming from all those different sources can't be good.

I think we need to get as many people as possible using the same client. Gnotella and Toadnode are the best two clients, and only through combining features of both can we achieve this goal.

Features such as determining bitrate are convenient but totally unescessary--it just adds to the congestion. Remember guys--[b]SIMPLE IS FAST.[b]

you should try gnucleus, its stable, has multiple searches. and you can find stuff quite quickly with it. because it seems to search better. and its open source. and its almost the exact same thing as toad node. also its programmed with c++ and has very low cpu usage.. except for when someone cancels a file transfer.. it freezes for a second, but transfers go on ok.

toade node.. while pretty good, sometimes doesnt complete searches.. with toad node i could try searching for madonna.. and actually get nothing.. but if i do it on gnucleus i get somewhere in the hundreds of songs. then i could go right back to toad. and still get nothing.. i tried even after connecting and reconnecting. also you get wierd spaces and such with toad node.

ohh.. one thing that could make the gnutella net slow down .. is people with 56 k modems trying to connect to it. couldnt that slow it down?

I get much better results (using Gnotella - all the other clients I tried lacked one or more essential functions available in Gnotella) when allowing a maximum of two or three connections and a max. of 4 Uploads. Even with these restrictions after a few hours my memory is totally filled, connection speed falls and my system acts like an old 486. It's then getting better if I cancel all the search connections and only keep the up- and downloads alive. Some people had the luck to leech from my hd with speeds of 100-200K/s, and I also had the chance of leeching files that fast from others once or twice - but mostly the speed crawls around 5-10K/s even if the other claims to have a T1 connection.