Wouldn't it be great if you had the possibliity to download from multiple users simultaneously, to increase throughput. Something like the segmented download in GetRight.
Since resume of download already works this should be easy to implement.
A few very small problems with file consistency checks might arise, otherwise it shouldn't be so hard to implement, or ....?
/ PÃ¥lle
Download from multiple users
Moderator: Moderators
I believe this would require hashes to really implement correctly. I don't think that CRC32/Adler32 checksums, as Arne proposes in the protocol forum, are sufficient even; the chances for duplicate files are too high (I _think_ given 2^16 files, there's a >50% chance of a collision between CRC32s, and a slightly higher probability for the more restricted Adler checksums) to the point where I'd consider it potentially counterproductive.
Download and share only rars and you will get some form of multiple download once the search for alternatives kick in.
However, isn't the delay between these searches a bit too long? I'd say that 10 seconds for new files in queue and perhaps 15 minutes for items in queue that have been searched for once would be much better....
Also, automagically search for alternates should be turned off for passive clients...
However, isn't the delay between these searches a bit too long? I'd say that 10 seconds for new files in queue and perhaps 15 minutes for items in queue that have been searched for once would be much better....
Also, automagically search for alternates should be turned off for passive clients...
[url=dchub://ancient.myftp.org]ancient.myftp.org - [BBB][Sunet][Tele2] ONLY! @ 20GB (ISP/IP/Share Scripted)[/url]
-
GargoyleMT
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
Re: Download from multiple users
On the feature forums, someone mentioned that he implemented this feature. He's got a website up, with source for his mod: pDC++ located here:PÃ¥lle wrote:Wouldn't it be great if you had the possibliity to download from multiple users simultaneously, to increase throughput. Something like the segmented download in GetRight.
http://www.lowertech.net/pdcpp/
The version he has patched against is 0.20.
I think hashes (Tiger, perhaps - certainly SHA1, but not MD5/4) are a good thing to mod into the client, but how would multi-source downloading be any more risky (as far as ending up with a corrupted file) than the existing alternate source scheme?cologic wrote: I believe this would require hashes to really implement correctly.
Fucking great!
Hi All!ender wrote:To tell the truth, I've been using the linux client, DCGui for some time, and it has no problems with downloading files from multiple sources at once... Actually, I never had a corrupted file, which wasn't the case with DC++...
I might actually start using Linux more often, since DCGui have this feature, this is something I have been looking for a long time now!
But I'm wondering if it will work like KaZaA,
so that you might download from multiple users,
or is it just utilizing more slots from the same user?
Because often many users have the same file,
and I might queue 5 downloads of the same file,
and the download start from only one of them.
One of the other users might be my neighbour
without me knowing about it, and I might still
download from one guy in australia, and get
a shitty speed as the result.
So with the feature like kazaa have, where you can
download the same file from multiple users,
I will get the file as fast as possible.
And it should continously search for other users
with the same file, so that I'm sure that I will
constantly have the maximum speed at all
times.
Thanks in advance!
Lars
You can't use more than one slot from a single user. (Well besides in NMDC, but that's a bug.) So it would have to be multiple users.
There was a lot of arguments about wether or not such a feature would be good for the DC network as well. Personally I think yes, but I guess the jury is still out on it.
A different approach would be that the client continues to try to get in on other computers, even if it has established one connection. And once a new connection is established it selects the fastest one. This should/could also be good for the network.
Unfortunately the way the DC protocol is designed it would also mean a lot more traffic for the hubs.
There was a lot of arguments about wether or not such a feature would be good for the DC network as well. Personally I think yes, but I guess the jury is still out on it.
A different approach would be that the client continues to try to get in on other computers, even if it has established one connection. And once a new connection is established it selects the fastest one. This should/could also be good for the network.
Unfortunately the way the DC protocol is designed it would also mean a lot more traffic for the hubs.
-
LordAdmiral
- Posts: 13
- Joined: 2003-01-03 23:25
-
Slycordinator
- Posts: 1
- Joined: 2003-01-23 02:25
- Contact:
Re: Fucking great!
I've been trying to use dcgui on redhat and have yet to get it to actually work. It now connects to my local hub and I get send-receive messages through the chat area, but I can't download anything. It's so stupid.Zyron wrote:Hi All!ender wrote:To tell the truth, I've been using the linux client, DCGui for some time, and it has no problems with downloading files from multiple sources at once... Actually, I never had a corrupted file, which wasn't the case with DC++...
I might actually start using Linux more often, since DCGui have this feature, this is something I have been looking for a long time now!
But I'm wondering if it will work like KaZaA,
so that you might download from multiple users,
or is it just utilizing more slots from the same user?
Because often many users have the same file,
and I might queue 5 downloads of the same file,
and the download start from only one of them.
One of the other users might be my neighbour
without me knowing about it, and I might still
download from one guy in australia, and get
a shitty speed as the result.
So with the feature like kazaa have, where you can
download the same file from multiple users,
I will get the file as fast as possible.
And it should continously search for other users
with the same file, so that I'm sure that I will
constantly have the maximum speed at all
times.
Lars
But for kazaa, kazaa lite already has ability to download from multiple people. If you don't know what kazaa lite, it's essentially a hack of kazaa minus all of the spyware (so it's far less bloated). But one extra feature was searching for multiple people sharing the same file. This does create some problems for music files, because some people share files that are at different bitrates so you end up with a file that's actual bitrate varies. It's a good program, but first remember to uninstall kazaa before installing kazaa lite.
Re: Fucking great!
Slycordinator wrote:I've been trying to use dcgui on redhat and have yet to get it to actually work. It now connects to my local hub and I get send-receive messages through the chat area, but I can't download anything. It's so stupid.
DCGUI is not able to downlaod your own files ... (It's so stu....)Best Regards
Mathias
Well, yes. A bit. It will be harder to find users that has no slots taken, as well as making use of more slots.Bobbish wrote:yeah thats all well and good but what you narrowminded people [that are] only thinking about yourselves [does not] realize is that this will slow down the network
Really? Why? The thing that will happen is that slots of all the slow users become used more - currently, anyone sharing common files on a slow connection may feel pretty confident in having its slots used less than a client on a fast connection. In the ideal situation (which will never happen in the Real World[TM]) more slots get utilized. Since slots are not in any way related to bandwidth in the normal clients (NM DC and DC++, that is) this should mean that the fast users get their files faster, and that the slow users get their files in a more reliable way (since some sort of more reliable checking has to be implemented to use segmented downloading effectively). This is due to the fast clients rarely hitting their bandwidth limits due to a lack of fast clients with the file in question.Bobbish wrote:this will hog up almost all slots and no one will get anything due to a lack of slots and bandwidth
For the slow clients the effect of a widespread implementation of segmented downloading would be detrimental, if any, since their bandwidth would be utilized more than it is today. This is more fair to the clients with the fast connections, as they can retrieve files faster and also distribute them to others faster.
To further that end, however, perhaps some measures need to be taken to try to enforce some sort of redistribution - perhaps recently downloaded files would become shared for a certain amount of time (perhaps equal to the time it took to download the files times three, or something, so that other clients have the time to detect and download the file). Tweaks such as these could help redistributing the files.
By the by, segmented download can be instituted in a client without a need to modify any other client - in fact, several clients already have some sort of segmented downloading implemented, and another one is currently developing it to a DC++-based client. When that modification is completed, expect to see a lot less free slots out there - but expect people to download faster, too.
If this will lead to faster redistribution of files is still unknown - but one can hope and try to implement things to try to help this process, or one can try to stop the tide rushing in. I prefer to be on the side of whatever is convenient for me - that way I can claim to be an idealist fighting for what I believe is right and get benefits I want.
Sarf
---
The only difference between a rut and a grave is their dimensions.