Host Evaluation
 

Some time ago, there was a discussion on this board about a scheme called Host Evaluation Number, or HEN, to increase the overall availability of files on Gnutella, which suffers a lot from the presence of so-called freeloaders (Hosts that don't share any or very few files or don't allow to download their shared at a decent bandwidth while at the same time downloading very much themselves). As I still think the idea is quite good and as it seems to have been more or less forgotten, I'm bringing it up again for discussion.

The basic idea is to assign an 8 bit number (the HEN) with every host to indicate how much of a freeloader/generous sharer it is, and then give those hosts with a high HEN preference over those with a low HEN as soon as they try to download something.

The HEN is calculated by dividing the number of uploaded bytes in all filetransfers during the last 48 hours through the number of bytes downloaded in the same time period and then multiplying the result with 128. (Thus, a HEN of 0 means the host hasn't uploaded anything; 128 means the host has uploaded as many bytes as it has downloaded; 255 means it has uploaded more than twice as much as it has downloaded.)
If the host is an UltraPeer/Supernode/whatever-you-want-to-call-it, every byte transferred to or received from a Leafnode over a Gnutella connection counts as a byte uploaded in a file transfer.

When Node now tries to download a file from another node, it sends its HEN as an additional HTTP tag along with the download request.
If the sharing host has not yet reached its maximum number of simultaneous uploads, the HEN of the downloading host is stored and the download request is accepted.
If the sharing host has already reached its maximum number of simultaneous uploads and if the HEN of the downloading host is more than 10 points higher than the average HEN of all the other hosts which are currently downloading from that sharing host, the sharing host opens an extra upload slot for the download requester.
If even the number of extra uploads of this sharing host is reached and if the downloading hosts HEN is more than 20 points higher than the lowest HEN in the sharing hosts list of established downloads, the upload to which that lowest HEN belonged is cancelled and the new download request accepted instead.

What do you think of this?

Looks like you put some good though into that. Except, what about those that have recently joined Gnutella and don't have anything to share yet? How do they efficiently fill up their shared files pool?

-- Mike

While it appears that a lot of thought was put into this proposal and theoretically it would work to a degree, I'm generally not a fan of any ideas which remove or cripple anyone else's ability to use the network. The Gnutella network is supposed to be an open and free network. Participating freely on the network should not rely on whether someone has uploaded anything at all.

All in all, using this proposal I forsee those people with T1 and higher getting the most preferencial treatment above all. They are ultimately the ones who can provide the throughput and the bandwidth necessary to share and to still download with no degradation to their service. And, with large (or even non-existent) bandwidth limits I'm sure, they can afford to share all they want and ultimately gain a high HEN.

I see a lot of modem users being hurt the most because ultimately, it's hard to share and to download at the same time. Personally, if I were a modem user, I would be most concerned with finding and getting the files I needed and then disconnecting... I wouldn't want to worry about sharing my files with others because sharing while I'm downloading just hurts my downloading. Therefore I would probably never reach a high HEN.

And then there are people in my situation. I may have a broadband DSL connection, but I also have a bandwidth limit on it. While I do share a lot, there are times when I may be downloading rather large files and my bandwidth limit doesn't allow me to get what I want and still upload to others. If that were the case, my HEN would probably be low and my chances of being disconnected from a host while downloading are increased dramatically and most possibly because of a T3 user who has a higher HEN wanting to download files from the same host I'm connected to.

At any rate, this is just my 2 cents on the subject.

To cultiv8tor:
Please notice that this approach doesn't block freeloaders. As somebody who doesn't share anything, you might have the bad luck that someone with a high HEN causes your downloads to break, but you still can download something - probably even more than in current network.

To Smilin' Joe:
So, what's wrong with this? If they contribute more bandwidth to the network than they take, everything will be fine. They might from time to time cause other users downloads to break, but isn't this worth the huge bandwidth that they povide? If they start downloading that much, however, that their 'privileges' actually become a nuisance to others, their HEN will ultimately fall again.

On the other hand, if there are any T1+ users out there who don't share much, this scheme will encourage them to raise their upload bandwidth limitator.

With the current model of network these T1 users are more likely to leave Gnutella completely behind them and run off to FastTrak or some other.

And this aproach is exactly the problem of the current network. Modem users grab their files and then disconnect again. This generates a network with rather few available files, which ultimately makes the whole thing really mode-user-unfriendly, because they can't get anything.
BTW, to be able to download files with high reliability in this kind of network, you don't need an exceptinally high HEN of more than 128, you just need a HEN that's slightly above average. And with all those asynchronous connections out there, this average will probably not even be very high - about 40 or 50 perhaps. This can easily be achieved, even with a modem connection.

You are speaking about the risk that some T3 user might come along and cause your downloads to stop. Hey, if there were that many T1 or T3 users out there that you'd actually have to worry about this, then the network wouldn't have a problem right now (and it definitely has...). With this scheme enabled, you would benefit a whole lot more from all those modem users start to actively share what they have than you would suffer from those few high bw users who might cause your downloads to stop from time to time.

Remember, the goal of this whole thing is not to cause huge inequalities among Gnutella user, but to encourage freeloders to become sharers again. Currently, many people are freeloaders just because they see no benefit for themselves in actively sharing their files.

Guido

Did you read this recent thread?
 

Don't break downloads, whatever you do
 

I don't like the idea of points systems.

There are a lot of things in gnutella that could be improved to make it easier to get downloads. There are a lot of files out there, they are just hard to find, then hard to download.

BEFORE you even consider this plan you would have to have in place easily recoverable downloads (ie hashes and has-searches), otherwise all these people getting their downloads broken (how frustrating!) by people with higher points will then need to find the same file again, which usually you don't, you find one similar, but the same song for example, then download from scratch usually.

Anyway, the point I would like to make is I think once you have hashes and hash-searching widely implemented then you would be less often frustrated and cursing at 'freeloaders'.

Now, there are some other incorrect assumptions/assertuions I would like to clear up in the posts above.

Modems, just like cable modems, have a dedicated upload bandwidth. The bandwidth IS NOT SHARED between upload and download, so whether you share or not should not be an issue for a modem user.

I share like hell on my modem. I also browse like hell at the same time. Most users probably use less bandwidth than me browsing, and I share at the same time and download too, two songs at a time.

So give up this fantasy that modem users have a hard time getting any value or putting back any value to gnutella. The biggest limit of modem users is the time factor. But if you have time to download, you have time to upload.

Please, modem users, share. That is all we need to say, not "if you don't share you'll get a smack!" Then they WILL join fast-track, or better yet audio-galaxy.

Nos

I've always been able to find what I need without tapping into the libraries modem users. In fact, I filter modem users out of my search results entirely. Hence, I don't mind if they grab their files and disconnect.

With quite a few users on campus networks or even corporate networks for that matter, T1 or T3 connections aren't uncommon. I have a feeling my downloads would stop more often than not under this scheme.

As for modem users being a benefit to me, like I said above, I prefer not to rely on modem users particularly because of the speed issue.... so added modem users probably wouldn't benefit me much at all (especially not for the rather large files I tend to download). Yes, their files eventually get distributed amongst others on the network, but like I said before, I haven't had any problems finding the files I've been looking for already... more of the same thing probably wouldn't help much at all.

Which is entirely acceptable to me. The network has relied on peoples' trust and generosity and managed to become quite successful without the need for coercion. I don't want to be part of any network where there are strings attached in order to be treated equally by any host I'm downloading from regardless of my sharing situation. I'm sure there will be others who agree.

Besides, there is one flaw that would have to be addressed in order for this system to work. And that is that a servent's HEN value is generated by the servent itself. This leaves the door open to someone who might want to guarantee their place in everyone's upload queue by modifying an open sourced servent to spoof their HEN values. If enough servents were to do this, the entire system could be rendered invalid and we'd be better off right back where we started. Of the few ways I've thought of to try to guarantee the HEN value is correct (and I will admit that I haven't thought of every possible option), every method could be spoofed in some manner.