DC++ Searcing alternative sources for faster download?

Archived discussion about features (predating the use of Bugzilla as a bug and feature tracker)

Moderator: Moderators

Locked
MadMax017
Posts: 2
Joined: 2003-04-19 05:35
Location: Falkirk
Contact:

DC++ Searcing alternative sources for faster download?

Post by MadMax017 » 2003-04-21 06:08

Hey all,

I've read a few pages back and I've read a lot about this "Segmented Downloading", which is fair enough but its already been covered so I won't bother, but I might have an (already discussed?) other idea.

Anyway, here goes. What if, when a file is being downloaded, DC++ searches the alternate sources for a better speed (I think Getright already does this to a degree?), meaning that the download would be coming from the fastest source available?

Just a thought,
Paul :P

GargoyleMT
DC++ Contributor
Posts: 3212
Joined: 2003-01-07 21:46
Location: .pa.us

Re: DC++ Searcing alternative sources for faster download?

Post by GargoyleMT » 2003-04-21 07:27

MadMax017 wrote:Anyway, here goes. What if, when a file is being downloaded, DC++ searches the alternate sources for a better speed (I think Getright already does this to a degree?), meaning that the download would be coming from the fastest source available?
This idea also has its supporters/petitioners as well. As you said, it doesn't have to be connected to segmented downloading at all. One of the first questions to ask, though, is how exactly the alternate sources would be tested for transfer speeds. You can't use a ping, because that's no a reliable metric, and I don't think that you'd want to start downloads and cancel them (thus causing additional traffic) just so that someone can potentially get a better transfer speed.

MadMax017
Posts: 2
Joined: 2003-04-19 05:35
Location: Falkirk
Contact:

Post by MadMax017 » 2003-04-21 07:52

Well from the downloaders point of view, the slot must already be open on the server's machine in order for them to even have a hope of getting the file faster from that machine in question. The client machine would only have to perform a "dummy download", possibly download the server's file list to get an idea of the speed of the new server, and if it is a better speed then switch sources.

In order to cut down on traffic from this feature, possibly only the next 5-10 or so possible sources in the alternate list could be checked at a time (with DC++ taking preference to better connections on sources?) , imposing a time limit on this would help cut down on traffic I guess.

All sounds good in theory, someone sit down for a week and code it all in, just to see if it works :lol:

At least im thinkin,
Paul x

volkris
Posts: 121
Joined: 2003-02-02 18:07
Contact:

Post by volkris » 2003-04-21 09:11

MadMax017 wrote:Well from the downloaders point of view, the slot must already be open on the server's machine in order for them to even have a hope of getting the file faster from that machine in question. The client machine would only have to perform a "dummy download", possibly download the server's file list to get an idea of the speed of the new server, and if it is a better speed then switch sources.
The problem with this is that there is often a disconnect between busting transfer speed and sustained speed. In fact you this might be intentional at times; a user might want to shoot his file list out really quickly before going back to his normal uploading.

Reliable speed measurement of the type you're suggesting is one of the grails of that branch of computer science. Lots of people are working on it, but not much progress is being made.

I would suggest, though, that a source be chosen based on TTL. If I have two sources that have vastly different TTL measurements, there's an ok chance that one's on the other side of the world from me. Extremely low TTL values might even locate sources inside your own ISP or local net.

But I believe Arne has basically nixed all ideas of this sort.

Locked