Swabby: an idea for better connections.
 

Here's a (possibly half-baked) idea I had I'd like to bounce off fellow Gnutelllites (Swabby in particular).

The problem: to save bandwidth, peers no longer pong like they used to which makes friend counts useless. It's become really hard to tell how "well connected" any node may be.

Possible Solution? I think instead you could use the average packet rate and the ratio of "searches" to "results" as a much more useful guide.

For example, have a setting to drop nodes that go below x packets per second over a period of time, and a setting to drop nodes with less than x percent of reply to search packets.

The packet rate lets you guess how active a connection is - the more traffic the more hosts are probably connected. As an added advantage, this can be watched continually and if a formerly "well connected" node looses hosts it'll notice. Friend counts never go down so you never know if a node eventually becomes "friendless".

The search ratio would be a good judge of how many peers were actually sharing files on a node. After all, searching is reason we're connected together to begin with, and a node that returns few results isn't much use. This also might tend to naturally weed out leachers as they'd eventually bubble out to less well connected nodes (perhaps they'd wind up all connected together ;-).

Of course none of this is perfect, but I think it might work much better than using friend counts alone.

The point of all this is you could maintain a good connection using fewer nodes. That saves overhead and places less strain on the winsock (which really suffers under gnutella). Also two or three really well connected hosts tend to stay alive longer and reduce the need to run through the host catcher so often (all the failed attempts when looking for a new connections are one of the major winsock stresses I think).

Anyway, sorry for the long post, but that's the idea - any comments anyone? Maybe I'm way off base, but I think this could help some of the overload and crashing problems. Low resources can cause even a bug-free program to act up, and I think, gnutella being so socket-hungry, it might be a factor in many of the problems users see.

Oops! sorry - wasn't signed in. Just so you know, the post above is mine.

so the hosts no longer "pong" in order to save bandwidth--
(didn't even know that...)

don't you think that informing all of the nodes you're connected to about your own client's average packet rate and ratio of searches to results would create more traffic than the actual "pong" solution?

if so, we'd have saved no bandwidth at all.

No extra traffic is necessary. This isn't a change to the protocol.

All you have to do is watch the traffic already flowing through your connected nodes to get this information. In fact, Gnucleus' statistics already show it - all that's needed is a way to drop connection that fall below a given threshold.

Gnucleus does drop unresponsive hosts, but does not use flowing traffic as a way to analyze the quality of the connection.

Connected to 6 people gets you pretty much good access to the network no matter who you're connected to.

And as time goes on you settle on very stable connections that generally migrate to the core of gnutella depending on how long your connected.

There are still some very basic routing issues that gnucleus and other clients need to analyze to start making rational descisions on which connections are quality.

The main reason for this is I'm finding it harder and harder to find things these days. Looking for large files is a particular problem as I often need to do a restart and many aren't well distributed (only one or two nodes sharing them).

Gnucleus gives up doing a re-search and goes into the "unable to connect" state in under 20 seconds! Often the same results take minutes to apear in a search window. I really wish Gnucleus kept trying the new connection until it found something like an open search window does.

Also while I know it increases traffic, I wish it would retry existing nodes say every 15 to 20 minutes until it gets at least one result. In that time the landscape can really change, and I don't think that would create too much extra load (especially as I have to do it manually anyway).

I've also noticed some nodes are returning very few search results (often less than 1% of total packets), and after time sometime I migrate towards pocket corners of the gnet rather than towards the center. That's what made me think some sort of traffic based preferencing might help.

I'm wondering if part of the reason search results are dropping is because clients are now not responding to queries unless they have open slots (ie: Gnucleus has this option, but it is defaulted to off)... I'm not sure what the other major clients do (lime & bear)... I understand the nessecity to reduce bandwidth but sometimes this seems to degrade the quality of the network.. in all honest I would rather find something on a busy server than not find it at all... maybe gnet should move towards a content based model, like what Limewire has... where you can select what kind of files you are searching for...

Yeah, that could be part of it, but currently I think gnucleus is the only one to do this.

It's a double-edged sword really. On the good side it keeps you form getting hammered by scores of people trying to download - a real problem when you've already got enough queued to keep busy for hours. When I used to use BearShare (a long, long time ago) I would disconnect from the network at night and have enough people pounding me that my uploads would still be busy the next morning!

All those retries eat up a ton of resources too. It would probably be better if it only stopped sending results once the number of download attempts hit a certain level maybe. Also the fact that most peers deperference busy servers in some way helps too. In fact, I wish Gnucleus had the "don't display busy servers" check box right on the front of every search window (along with a file type dropdown filter). I always find myself going into the preferences to switch it back and forth.