and one of the best working, if not even THE best ...

The best? Hmm, edonk has some great features but has a long long way to go. The two greatest features that I would love to see in gnutella are:

-ability to share partials (with tiger tree this can be done even better than it is with edonk)

-ability to creat hyper links. I know BS is working on this.

"the best working" is a relative expression...
you know? like "the one-eyed is king among the blinds"
and right now nothing is better than edonkey when it comes to "real" filesharing. (i dont mean downloading an mp3, i mean getting a very large very specific file fast and reliable)
Gnutella sure has the better networkdesign but as you already said is missing some important features in comparison to edonkey

(and btw did you read http://www.zeropaid.com/news/article.../05152002a.php ?)

[edit:]
just to make sure, i love gnutella, would i be hanging around here otherwise?

One of the reasons that many don't feel excited about eDonkey, besides its boring GUI, is becuase there are too many tricks (most undocumented) to go through before really take advantage of its powerful search and swarm file transfer.

When I first used eDonkey, I've got usually 1-5kb/s download speed, now with aids from the 'Bot' and server list and all the proper configuration, the speed can go up to 100 kb/s. The speed here, 50kb/s to 100kb/s, I meant is very stable, it remains this speed in hours.

When look into the list of sources that feed the download (of course, most are PARTIAL file), there are usually over hundred sources with a few of them transferring and the rest are in 'Queue' status.

Many also hate eDonkey due to the fact that it forces you to share partial file (those still in the middle of downloading), and purposely slow you down sometimes (conspiracy) to force you to stay on line longer and sharing, so a MP3 file may appear taking longer to download than Gnutella, but in case of a DivX, it will take much less time and give you more confidence to have it in a a short amout of time.

At the moment, all I need is eDonkey. Compare to what eDonkey can do, the rest of P2P world are really all jokes, take a look at http://www.sharereactor.com. However, the fear eDonkey may one day disappears is always there as it's a close source program, soon or later it will draw attention while it's becoming more and more a dominent deliver channel of the 'stuff' (luckily, not many tech media are paying attention to eDonkey's low profile status) That's why Gnutella needs to catch up and get the lead back while there is still chance.

Re: Re: PFSP 0.1 - Very Very Rough
 

What is the proper way to indicate an alternate location then?

The X-Alternate-Location is added it to the HTTP header of the response when somebody is trying to download from you.

file chunk size
 

I am probably going to change the protocol from 1mb chunks -> either 1mb chunks or 5% of the file, which ever is LARGER.

Anyone have any input, opinions, data, ect on this?

I would skip the lines where it says the servents must not share partial files without tiger tree hash. With tiger tree you can download from those hosts as well, since you will see quickly if the data is not what you want.

Before downloading a file, always get the tiger tree hash (of the 1MB chunks) first. Then simply download the file from any location you find and calculate the hash of each new MB you downloaded, so you can quickly verify you are downloading the right stuff.

QueryReplies shouldn't contain Alternate-Locations.

Another idea which saves gnutella-traffic: Servents should not return queryreplies for incomplete files at all. - If X-Alternate-Locations it HTTP- Headers work alright, each location having the complete file, will return X-Alternate-Locations of all servents that accessed the file recently, so you should be able to gather the locations quickly while connecting to all the hosts having the file.

Servents may NOT search by sub-hash. Let's say you are sharing 20Gigs of data, that means you would have to keep 20,000 subhashes in a library and even search through this library.

When a servent requests a file, he does request all the ranges he needs. The remote servent answers with either HTTP 206 including the ranges it has and including sending one the ranges or with HTTP 416 if it cannot satisfy the request. I would prefer it, if the ranges were requested and sent by one by one.

Servents should not upload ranges of the file randomly but satisfy the ranges of the as they were requested, since I wouldn't want to break HTTP here.

Servent settings (e.g. if they share partial files by default) don't belong into this protocol.

thank you
 

very good point


yeah, thats not right.


The think here was that if you cant find a full file in your horizon finding a partial might get you into the file mesh.


Good point, this is the stuff I miss because I dont actual program anything


sound good


The think here was to get random parts of the file onto the network so that everyone didnt start at the begining, the original source leaves, and there are 30 copies of the first 25 mbs of a 100mb file.


np


Thanks again for the feedback

I disagree. This is an issue of health for the network.