Features needed by all Gnutella clients
 

1. UltraPeers ... this is probably the most important addition for the clients that have no yet implemented it. It would allow for a much larger horizon, which would allow better download success using the already-implemented swarming technology in some clients. A 10,000 host limit is extremely small, and should be expanded to over a million or more in order for the swarming feature to be effective. In fact, it would be nice to be able to search the entire gnutella network, instead of just a subset of the hosts.

2. Swarming ... Bearshare already has this, and it is indeed a very useful feature that downloads the same file from multiple sources at once. It significantly improves transfer speeds. Constant source search would be a part of swarm downloads. Once a download has been selected, the program should continuously search the network for new sources for that download, and to add them to the downloaded sources once found.

3. Ability to search with metadata. This would be similar to the way the fasttrack (Kazaa/Grokster) protocol current works. For audio files (MP3/AAC/WAV/WMA/etc.) the following searchable metadata should be sent with each result: title, artist, album, category, language, year, quality (bitrate), length, size, and comments. For video files (AVI/MP4/MOV/WMV/RM/etc.) the following searchable metadata should be sent with each result: title, artist, category, language, resolution (image size), length, video codec (div3, div4, divx, ind5, ind4, xvid, 3ivx, etc.), audio codec (mp3, pcm, ogg, aac, ac3, etc.), size, and comments. For image files (JPG/GIF/BMP/etc.) the following searchable metadata should be sent with each result: resolution (image size), title, artist, category, size. All clients need to support this standard metadata functionality. However, since Bearshare and Gnucleus (morpheus) are the most commonly used clients out there right now, these two should spearhead the implementation of metadata searches.

4. By default, the client should search a user's computer for all standard media files and should ask the user if they want to share that media. Most users go with the default settings they are offered, so this would certainly increase the amount of data shared on the network.

5. Ability to specify upload bandwidth limits for separate types of data (eg. 128 kbps for video content, 64 kbps for audio content, 64 kbps for archives and programs, 32 kbps for images, etc).

6. Ability to block uploads to freeloaders (those who do not share files). Some clients already have this, but all of them should implemented this feature.

7. There is no need to have a separate incomplete folder for files that are still being downloaded. Instead, it is less confusing for the end user to just have a single download folder, and for the downloaded files to have an extension such as .dat until the download is complete. This is the same way fasttrack clients such as Kazaa and Grokster currently function, and it is a more elegant method than the gnutella method.

1-6 -- good points. we can agrue on details, such as swarming isn't supported by BS, you mixed it with segmented downloading. But in general -- good points. But not this! Never! At least for me.
--Max

I'm gonna go out on a limb and contribute my 2 cents to this. I'm currently attempting to develop a servent of my own. In my case, I'm not only trying to develop a servent, I'm trying to develop a "successful" servent.... one that includes a lot of the features that people are looking for.

I'm just going to go through your points one by one, bobbinson, and add my comments:

1) Ultrapeers - So far, they look promising.... and I would agree they are a healthy addition to the Gnutella network. I have my reservations about how they are currently being implemented, but that's another story.

2) From my understanding of what "swarming" is, I don't believe any current servent supports it, but I will admit that I'm not up to speed on it so I may be wrong. If you mean multisegmented downloading, I think no servent should be without it.

3) Yes, yes, yes! There have been times when I preferred searching on the Fast Track network because I was able to search for keywords in the meta data. I agree that it would be a very important addition to the Gnutella network.

4) Um... NO! I think searching peoples' hard disks for media files "by default" would do more harm than good. I have no doubt that this would dump more data on the network. However, how much of it would be "useful" is another question. There are already enough people out there with shared folders containing their incomplete downloads. If servents were made to automatically search users' drives for sharable media, then how many copies of "The Microsoft Sound.wav" do you think would start showing up on the network because those users allowed their servent to share their WINDOWS\MEDIA folder? Even if you ask people if it's OK to share those things, remember, most people accept the defaults. And taking into account the computer literacy of the average user, I know of a few "minimally computer literate" users already that couldn't change their sharing settings even if the settings were wrong.

And not to mention the privacy issues this would cause. I know of people who have digital cameras that would find it quite alarming to find their family photos had automatically been shared because their Gnutella servent decided it wanted to find sharable media. Again, these are users that probably wouldn't know how to change their sharing settings even if they wanted to.

5. Personally, I don't see why allowing different bandwidths for different file types would be useful. Quite frankly, I would rather a person downloading a 5MB MP3 from me be done downloading in 2 minutes than 4 minutes because bandwidth usage for MP3s is half that of digital video files. That's 2 minutes less waiting for someone else wanting one of my upload slots. IMO, if someone's downloading a video file from me, they're going to be downloading for quite a while regardless of how much bandwidth I can provide them.

6. I know the freeloading debate has been heated, but here's my 2 cents on the issue. I don't agree with blocking freeloaders... period. As has been stated numerous times before, they're part of the network once they join. They may be the only route between you and someone else with a file you want. However, I will also concede that they don't contribute to search results at all.

I'm sure this has already been mentioned already (although I couldn't find any mention of it in the threads I read) but what about just not counting freeloaders as hops when routing query packets? If a servent isn't sharing files and it receives a query packet, then it should just pass it on WITHOUT decrmenting the TTL field or incrementing the Hops field within the query packet as they normally would. Likewise, on the return trip, query hit packets would also not have their TTL or Hops fields modified. I know I probably haven't put as much thought into this idea as necessary, so anyone feel free to shoot holes in it. It's just something I thought of on the spur of the moment.

7. I think this is really a matter of personal preference. I prefer seperate locations for my incomplete files. I personally don't like wading through a list of partials mixed with complete files just to find one specific file. And no, it probably wouldn't even help to hide incomplete files. I'm one of those guys who likes to see everything including hidden files. I applaud all servents that give me the option to save my incomplete files somewhere other than my downloads folder.

1) Ultrapeers don't increase the horizon, and that's not their purpose either. It simply takes the traffic load off clients who connect as "leaves" to the Ultrapeer. And to add to that: Ultrapeers should mix its connections more, limiting leaves to those who have stricter bandwidth parameters, such as the case with modem users.

2) Per definition of "swarming", no Gnutella clients use swarming. I doubt this kind of swarming will be implemented as well, as this will pose quite some concerns for everyone. If you mean multi-source downloads (parallel downloads), then yes. This is something you'll see soon with the HUGE proposal, which has the ability to create a mesh.

3) I have it in my client (it also show image previews, FYI). But I'd certainly like to see it in other clients as well.

4) That's an iffy. People generally don't like other applications sniffing around on the PC, even if the application "says" it is searching for media that can be shared. It's best to leave that up to the end user. However, I would force the download directory as the upload directory as well, even though there are workarounds for that.

5) There's not much sense to that. It would be wiser to have a global cap on the upload speeds.

6) No, that's not going to work. Consider someone who's new to Gnutella and perhaps even to the world of filesharing in general. He/she may not have anything to share, even though there's intent. How can one satisfy that intent if he/she isn't allowed to download?

7) That would mean you could share ".dat" files as well. Currently, you woudln't want to encourage the uploads/downloads of halfway completed files. With the mesh coming up, this can change though.

UP and horizons
 

Actually ultrapeers should increase the "effective" horizon. If you currently search 10^7 peers (your connected to 10 peers, each connected to 10 ect, and the ttl is 7) you horizon with ultrapeers will still be the same. However, each of the ultrapeers you search can have anywhere from 5-200 leafs, making your effective horizon up 5 - 200 times bigger. And that is a huge difference.

I would also suggest dynamic content clustering. When you perform a search and get results you save the IP in your host cache. When the client needs new hosts it prefers clients that it got search results from. So people searching for and sharing the same type of stuff will migrate to the same areas of the network over time. If you search for/ share many types of thing you will remain plugged into many areas of the network.

Many of the ideas suggested above are on the way. One that I am greatly looking forward to is the broad implementation of GGEP. This will allow for the type of meta data searches you talked about.


BTW, cultiv8r when will you be releasing your client?

1) Ultrapeers will increase the horizon, at least in BearShare anyway.

2) BearShare 2.5.0 has swarming now. And believe me it is sweet! Downloaded a 200mb file from 14 different people at the same time, I got that file in under 10 minutes. :)

3) That would be nice.

4) Definately a no way for this one.

5) It has been called "Tiered uploading" in other places, and would be a great feature.

6) Sorry blocking is just not the answer.

7) The way you do it doesn't really matter. That only thing that is important is that no half downloaded files get accidentally shared by the client.

Swarming vs Parallel DL
 

BS does not have true swarming as defined here. I think its just semantics but many people on these forums worried about it.

Re: Swarming vs Parallel DL
 

You are right. I guess that I am more worried about the speed then the semantics. :D

Two features I'd like to see that I haven't seen much discussion about:

1) A feature that automatically filters out from the search results any files that are already in my Shared folder. Makes it easier to see what I might want to download.

2) Timestamp of the file. Something that indicates how new the file is to the network. Sometimes I'd like to be able to sort search results by what is the newest content. Two ways of handling this.

a) A custom tag, automatically updated by the client, that shows how many times the file has been downloaded on the network. This may be tricky to work out such that it is interoperable with all clients.

b) The creation date from the file properties.


Daniel

Ok so if swarming doesn't mean multi-source downloads or parallel downloads just what is the definition of swarming?