Multiple Source Downloading.

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

Moderator: Moderators

ojmyster
Posts: 8
Joined: 2004-04-19 11:52

Multiple Source Downloading.

Post by ojmyster » 2004-04-19 12:05

Hi,

1. DC++ supports file download resuming.
2. DC++ supports TTH (CRC if I'm not mistaken...) searches.

Surely because of these two factors DC++ should be able to support downloads from multiple source at once in the same way something like WinMX might.
I think it would be a good idea for DC++ to support this feature in future versions.

:roll: lol, presuming it does'nt already and I just did'nt happen to realise it, is there any reason why DC++ does'nt already have this feature?

Thanx OjMx

Edit: Because this is a feature request i'm moving it there, it also has nothing to do with "FAQ", so i've edited your subject.. /Todi

BSOD2600
Forum Moderator
Posts: 503
Joined: 2003-01-27 18:47
Location: USA
Contact:

Post by BSOD2600 » 2004-04-19 12:11

At this moment in time, DC++ does not support mulitsource downloading. Although, since hashing has finally been implemented, its not too far off in the distance. Be patient

joakim_tosteberg
Forum Moderator
Posts: 587
Joined: 2003-05-07 02:38
Location: Sweden, Linkoping

Re: Multiple Source Downloading.

Post by joakim_tosteberg » 2004-04-19 12:17

ojmyster wrote:2. DC++ supports TTH (CRC if I'm not mistaken...) searches.
Now you've gotten something wrong, TTH is one kind oh hash CRC another so if you just removes the paranthesisis and everything between them it's correct.

BSOD2600
Forum Moderator
Posts: 503
Joined: 2003-01-27 18:47
Location: USA
Contact:

Post by BSOD2600 » 2004-04-19 14:08

Well the SFV check is a CRC check, no? so maybe he ment that :?

joakim_tosteberg
Forum Moderator
Posts: 587
Joined: 2003-05-07 02:38
Location: Sweden, Linkoping

Post by joakim_tosteberg » 2004-04-19 14:12

BSOD2600 wrote:Well the SFV check is a CRC check, no? so maybe he ment that :?
I think he though TTH was some kind of collection name and that CRC was one of the hashing that went under that name.
But that's only what I think he thought so it can be wrong.

ojmyster
Posts: 8
Joined: 2004-04-19 11:52

Post by ojmyster » 2004-04-19 15:20

Well, its some kind of 32bit digest.
However, what about multiple source downloads. I take it that DC++ does'nt support this. Who else thinks this is a good idea?

BSOD2600
Forum Moderator
Posts: 503
Joined: 2003-01-27 18:47
Location: USA
Contact:

Post by BSOD2600 » 2004-04-19 15:23

ojmyster wrote:However, what about multiple source downloads. I take it that DC++ does'nt support this.
Did you just ignore what I initially typed!?!

BSOD2600 wrote:At this moment in time, DC++ does not support mulitsource downloading. Although, since hashing has finally been implemented, its not too far off in the distance. Be patient

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

Post by GargoyleMT » 2004-04-19 19:21

ojmyster wrote:Well, its some kind of 32bit digest.

The tiger hash algorithm produces a 192-bit result, fyi.

St0ry
Posts: 3
Joined: 2004-04-05 17:59

Post by St0ry » 2004-04-19 22:11

I don't think this is a good idea. If you think you're downloading too slow, then switch to another user. If there's multisource, the queues are gonna be as long as WinMX.

BSOD2600
Forum Moderator
Posts: 503
Joined: 2003-01-27 18:47
Location: USA
Contact:

Post by BSOD2600 » 2004-04-19 22:40

If the file(s) are the same, how is that going to differ much from how it currently is now? For example, you download a movie released by a group now.... DC++ autofinds 9 different sources with the files and connects to them all, getting different files. You're now using a slot from each person.... In fact, its going to take longer to get a seperate file from each person than to get one file from them all at once.

hellosam
Posts: 1
Joined: 2004-04-20 00:51

Post by hellosam » 2004-04-20 01:01

I didn't download it, but the guys at http://dcgui.berlios.de/ have something.

"features"
"+ multi-/chunkdownload (download one file from multiple sources at the same time)"

but ... their program doesn't look like it has near as many features as dc++ ...

Shroom
Posts: 30
Joined: 2004-04-01 04:09
Location: Sweden

Post by Shroom » 2004-04-20 04:27

I have to agree with St0ry here. If multisource downloading is implemented, it will have a very negative impact on the current slot system. But I'm sure you guys have thought of this.

Maybe dc++ could figure out your maximum download speed (excluding the realtime compression that is), and only add new sources to the multisource download if your current total download speed is less than say 90 % of your maximum download speed. Multisource downloading would also have to be limited to say 3 sources at once. Anything more would be a huge waste of slots. (in my opinion of course).

:D

ojmyster
Posts: 8
Joined: 2004-04-19 11:52

Post by ojmyster » 2004-04-20 09:09

How about limiting the number of sources to say like... 2. Also, DC++ could *hot swap*. If a source goes below a certain speed (threshold) a new source is found. While the other source continues downloading.

Which gives me another idea... Give DC++ the ability to *hot swap* with just one source at a time. What I mean when the source goes under a threshold speed, DC++ starts looking (or pinging) other potential sources. When it finds a faster source, it connects, starts downloading then disconnects from the origeonal source.

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

Post by GargoyleMT » 2004-04-20 10:59

ojmyster wrote:What I mean when the source goes under a threshold speed, DC++ starts looking (or pinging) other potential sources. When it finds a faster source, it connects, starts downloading then disconnects from the origeonal source.

I've seen this before, and it still seems wasteful and possibly abusive. With multi-source, you never have to discard data, which is a win. Plus, I think users will micro-manage less on multisource downloads.

St0ry
Posts: 3
Joined: 2004-04-05 17:59

Post by St0ry » 2004-04-20 19:13

If this "hot swap" idea is implemented, many users will just use a bandwidth limiting program and cap their upload speeds. And since no one will download from them because they keep getting "swapped," hub ops won't know who to ban for speed capping.

Wisp
Posts: 218
Joined: 2003-04-01 10:58

Post by Wisp » 2004-04-21 04:01

I am thinking about multisource downloading a long time, and i'm not sure if it is such an improvement for dc++, offcourse your downloadspeeds would be faster in theory, but will the network as a whole function better? After all, other networks like Kazaa, WinMX or Emule are well known of their long queues and slow download speeds, will dc++ become the same if multisource downloading is implemented?

The reason that you can download so much and so fast on the dc++ network is the slot system, you don't have queues or priorities, so everyone can often immediately download without waiting. The problem with multisource downloading is that it will ruin the slot system if people can use multiple slots the same time.

After thinking about this problem i came with an idea, which is probably mentioned before, although I haven't seen it.

When you download a file, you use one source and slot. If you can download from multiple users you take more slots so other users can't download anymore, but when a user has plenty of slots, this isn't a problem. The main issue is to give a person who doesn't have a source to download from, priority above a user who wants to expand his sources for multisource downloading.

My idea was that when a user (A) wants to use an 'extra' slot for downloading, the slot isn't counted, so when a user (B) has 1 free slot, you can use that person as extra source, but when you do that, the user (B) remains to have 1 free slot, and when someone else (C) wants to download a file from that user (B) he gets priority and user (A) is disconnected and has to download from one person again.

The advantage is that you can download from multiple sources, but the extra sources have a lower priority and get disconnected when someone else wants to download. This way you only can have extra sources when the user has bandwidth available which is not used by other users.

I hope you understand my story :D

Astro-g
Posts: 2
Joined: 2004-04-21 08:01

why is upload limiting bad?

Post by Astro-g » 2004-04-21 08:25

Especially if auto speed swapping is available, Certainly if multisource downloading is available.

I mean, Im providing My storage, my carefully picked and organised set of files, and my (expensive) upstream bandwidth, for YOUR use, at no gain to myself. be glad Im am hosting a file you want. Bitching about the speed you are getting is not helpfull.

Personally, Im usually verry happy to find something I want, no matter what speed im getting. and appropriately thankfull

Wisp
Posts: 218
Joined: 2003-04-01 10:58

Re: why is upload limiting bad?

Post by Wisp » 2004-04-21 09:02

Astro-g wrote:Especially if auto speed swapping is available, Certainly if multisource downloading is available.

I mean, Im providing My storage, my carefully picked and organised set of files, and my (expensive) upstream bandwidth, for YOUR use, at no gain to myself. be glad Im am hosting a file you want. Bitching about the speed you are getting is not helpfull.

You trade your share with others so it's not like they have to be happy with it, it should be normal to share :)
Personally, Im usually verry happy to find something I want, no matter what speed im getting. and appropriately thankfull

Well I'm mostly not very happy when a user is limiting his speed at 1 kb/s so my 700-mb-movie has 2425912 hours left to download...
I hate users who have like 30 slots so they can get on >10 hubs and then limitting their speed to a few kb (but this is another story ;) )

Shroom
Posts: 30
Joined: 2004-04-01 04:09
Location: Sweden

Post by Shroom » 2004-04-21 10:58

Wisp: I really like your idea of how multisource downloading could be set up. :D

Are there any “official� thoughts from the developers on how a potential multisource downloading would work, and how it would bypass the slot-problem?

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

Post by GargoyleMT » 2004-04-22 19:35

Shroom wrote:Wisp: I really like your idea of how multisource downloading could be set up. :D

That's funny, because it's described in what I find to be a terribly obtuse and opaque manner.

It seems to require manual intervention (bad), and a client can easily avoid disconnection by telling all of the sources that they're its only source (also bad).

IntraDream
Posts: 32
Joined: 2003-12-12 14:28
Location: FL,USA
Contact:

Post by IntraDream » 2004-04-23 11:07

I think that multisource will hurt DC and eventually be the death of it, not because of corupt files necisarly but because of isp bandwidth ratios. if your downloading at your max d/l your uploading is going to suck much the same as if ur uploading at your max your download will suck. People WILL without question download more if they can download faster but they still will likely upload the same(or less) as they do now because of most people including myself-s ISP (Cable/DSL) caps uploads so low that uploading basicly cannot increase this causeing this 'Slot Problem'.

Before you say it. yes my client does have multisource d/ls but the public version is a pos anyway.. yes my private version has it also. and yes the main reson im being anti Multisource here is because im a greedy bastard. AND because weather you beleave it or not too many other people are just as greedy as me. just most cant write there own client. LMAO

Tim-

Wisp
Posts: 218
Joined: 2003-04-01 10:58

Post by Wisp » 2004-04-23 11:34

GargoyleMT wrote:That's funny, because it's described in what I find to be a terribly obtuse and opaque manner.

Sorry about that, I tried to be as clear as possible
It seems to require manual intervention (bad),

What do you mean? the searching for alternatives is automatically
and a client can easily avoid disconnection by telling all of the sources that they're its only source (also bad).

If you start modifying the client everything is possible, i assume modified clients are kicked (but you can never completely ban fakers offcourse)

mean_mashine
Posts: 1
Joined: 2004-04-26 21:07

Post by mean_mashine » 2004-04-26 21:13

Well the MULTISOURCE will be the only thing keeping me to download with Kazaa. With this i;m stuck with one person and no way to increase the download speed, where in Kazaa I can download from multiple sources, so even if their speed is low, it combines to good download speed.

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

Post by GargoyleMT » 2004-04-26 22:34

Because dammit, I don't want to wait around for my mislabeled corrupt midget porn called "britteney nude hot teen sex naked shower preteen hardcore boob tit.mpg.avi"

MeisterEder
Posts: 1
Joined: 2004-04-28 14:30

Post by MeisterEder » 2004-04-28 14:44

I think the DC network is the one with the highest quality regarding available files. Offering a multisource download features will make many people invade the DC network with corrupt and mislabel files like "britteney nude hot teen sex naked shower preteen hardcore boob tit.mpg.avi".

No reason for offering multisource downloads in my opinion. I never had problems with manually switching to other users or just waiting for a download to complete at a low transfer speed. I'm a patient person so you should be.

As I'm often in the situation of having found some rarity being offered by a 0-open-slots user I would say No to multisource downloads for that reason, too. All slots will be occupied for significantly more people than now, making rarities even harder to download from that special user while other users leech the newest, already widely spread hollywood production from him amongst ten other users.

In fact multisource downloads wouldn't help me as I tend to download popular files very rarely only and stick on rarities instead.

OrangeSlice
Posts: 12
Joined: 2003-12-09 19:53

Post by OrangeSlice » 2004-04-28 18:00

MeisterEder wrote:I think the DC network is the one with the highest quality regarding available files. Offering a multisource download features will make many people invade the DC network with corrupt and mislabel files like "britteney nude hot teen sex naked shower preteen hardcore boob tit.mpg.avi".


wait...how is multisourcing in DC++ going to cause this?

anyway...multisource is already offered on the dc network, reverseconnect, zDC++, DC:PRO are a few clients that have multisourcing

Guitarm
Forum Moderator
Posts: 385
Joined: 2004-01-18 15:38

Post by Guitarm » 2004-04-29 03:27

OrangeSlice wrote:anyway...multisource is already offered on the dc network, reverseconnect, zDC++, DC:PRO are a few clients that have multisourcing
Yes, and do they work properly? The idea of having multisource d/l might be good or it might be bad depending on the implementation. This is a sensitive thing to do and to make it work properly one should not rush into implementing some "not-thought-through" solution.
"Nothing really happens fast. Everything happens at such a rate that by the time it happens, it all seems normal."

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

Post by GargoyleMT » 2004-04-29 21:20

Well, regardless of whether DC++ itself does multi-source downloading, hashing is important because it can be done safely. The current implementations do it unsafely, and don't care much about the bad effects that corruption may cause.

So multi-source downloading could be good, or it could be bad. As someone whose slots are always full, I'd like those 56k users that I've uploaded megabytes upon megabytes to to be useful for something.

Stacker
Posts: 23
Joined: 2004-04-30 00:15
Contact:

Post by Stacker » 2004-04-30 00:19

Sorry not good at being patient :)
The multi-source downloading is that something that can be done with a script?

unruled
Posts: 10
Joined: 2003-05-15 12:49

Post by unruled » 2004-04-30 04:24

DUde, I dont mean to be rude but, the reason for u wanting multiple souce is for "better speeds"? no offense but I dont think that it would result in better speeds...my average in dc lies around 90-340 (340 is my max) kB/s...its all about knowing where to look...
if u ask me multiple source downloading would slow down the network as awhole, since you will be leaching off more people than before at the same time, so others will have more trouble getting slots and if they get slots they wil not be as fast...
I think peer2peer is better than peers to peers (multiple sorce..)

and IF this mult. source thing is really coming I would DEFINITELY advise to put a source limit of 3, 4 or 5 per download....

:) my 2cents

btw: what you said about the fact that atm there are very high quality files and not any fakes (that Ive experienced) is part of the fact that it is not multisource....multisource is like a disease that jumps from user to user....multi source is the quickest way for them to spread

Aletannica
Posts: 4
Joined: 2004-04-29 10:29
Location: Italy

Post by Aletannica » 2004-04-30 11:18

unruled wrote:and IF this mult. source thing is really coming I would DEFINITELY advise to put a source limit of 3, 4 or 5 per download....


and I would want that they were shown or in the tag or in the description line

unruled
Posts: 10
Joined: 2003-05-15 12:49

Post by unruled » 2004-04-30 12:13

anyway, I AsK of the dc++ Crew, PLEASE do not incorporate multisourcedownloading as I said,I dont thik it will improve download speeds, infact Im afraid it will worsen them..and atm they are very good I have to say, one of the reasons why I use dc++I also think it would worsen the quality of files and worsen the user experience that atm is deifinitely great.

do you want dc++ to be ovverrun by *dead* and inneffient and not nice to use programs like kazaa or edonkey? please leave it as it is in order to avoid this. We do not want a dead network..., we also don't want to meet fakes/low quality files and low speeds
:roll:


is there ANYONE here that has a good argument for multisourcedownloading?
Except for speed?

cologic
Programmer
Posts: 337
Joined: 2003-01-06 13:32
Contact:

Post by cologic » 2004-04-30 12:35

I'll leave the speed arguments alone, at least for now.

unruled wrote:what you said about the fact that atm there are very high quality files and not any fakes (that Ive experienced) is part of the fact that it is not multisource....multisource is like a disease that jumps from user to user....multi source is the quickest way for them to spread


unruled wrote:I also think it would worsen the quality of files and worsen the user experience that atm is deifinitely great.


unruled wrote:do you want dc++ to be ovverrun by *dead* and inneffient and not nice to use programs like kazaa or edonkey? please leave it as it is in order to avoid this. We do not want a dead network..., we also don't want to meet fakes/low quality files and low speeds

How do any of the previous three quotations relate to multisource downloading in any way? Alternatively: why would a competent (no, zdc/dc:pro/... well, any of them ... don't count) multisource implementation cause poorer quality?

Further, the first quotation appears to contradict other parts of your post: "multisource is like a disease that jumps from user to user" establishes that multisource is a disease. "multi source is the quickest way for them to spread" seems to indicate that it increases the efficiency with which ... something, it's not clear what, is spread.

If it's files, it contradicts "multiple source downloading would slow down the network as awhole". Not only that, but whatever it is that's it's spreading is a disease; are files a disease on a filesharing network?

Maybe you meant corrupt files; in that case, justify this claim.

If it's something else, you should clarify what you mean.

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

Post by GargoyleMT » 2004-04-30 19:39

Stacker wrote:The multi-source downloading is that something that can be done with a script?

No, it's not something you can accomplish with a (BCDC) script. There, however, exist clients that do multi-source already - none of them use the TTH hashing to judge compatible files, and none of them can use TTH for incremental verification of the files yet. They'd be a poor choice of clients to use just because you're impatient (see the corruption references in many previous posts).

Aletannica wrote:and I would want that they were shown or in the tag or in the description line

If multi-source ever gets into DC++, you'll be free to restrict the legal clients in your hub to earlier versions of DC++. Having it in a tag (description) serves no purpose.

unruled wrote:is there ANYONE here that has a good argument for multisourcedownloading? Except for speed?

Sure: users manually manage sources a lot, and want even more tools for doing so in DC++. If files could be downloaded from more than one source, a download currently running at 5 kilobytes per second would be perfectly fine, since other sources could be added to it. This means a less cluttered interface in DC++ and less bloat in the code.

cologic has a wonderful post, it'd be a shame if you didn't reply to it.

DynamiteNeon
Posts: 5
Joined: 2003-01-25 00:21

confusion

Post by DynamiteNeon » 2004-05-01 00:14

I think the problem is that some of you are confusing the theory with the implementations. There are obviously some bad implementations out there and there's always going to be positives and negatives with any download scheme. Let me give you an example to explain why multi-source downloading is a good thing if done properly.

Let's start with theory. Let's imagine that 20 people all have the same file and can serve at about 5Kb/sec. Now, let's imagine 2 people on fast connections want that file at the same time. Currently, they would be stuck at 5Kb/s max because they can only grab one slot. Now, if they had a perfect system, they could both max out at 50Kb/s because they could each latch onto 10 slots each. It would increase the overall efficiency of the system.

Of course, we all know that in the real world, things are more complex and managing all those resources is not trivial. What if new people want the file while the others are downloading? How do you make sure leeches aren't abusing things? How do you do all these cool things and still make it easy for people to search and find things?

What some of you are really complaining about is fairness, and of course, that's the hardest thing to code for and still give the user freedoms to control things, especially with open standards and multiple client versions. Take bittorrent, for example, which always tries to keep your upload and download rates proportional, at least in the original version. It favors fairness and simplicity, but at a price because it requires an external tracker to manage connections. Something like that would be hard to do in DC because hubs would not be able to handle the load as easily..

There's always going to be a balancing act between speed, ease of use and stability. That doesn't mean that a chance to improve efficiency should be ignored though. It just needs to be well thought out.

unruled
Posts: 10
Joined: 2003-05-15 12:49

Post by unruled » 2004-05-01 07:01

it is easy to think that multi source will be faster as you might think that, more people means more speed; but don't forget that if you are downloading from more people at the same time also other people are downloading from more people at the same time....so lets say that there are 3 users that have an upload of 5kB/s, and you have a download that all 3 users have...Ideally then you would have a download speed of 15kB/s (I could use higher values but just wanted to keep it simple)., HOWEVER, heres the drawback... there are 3 other users that want to download the file, so then instead of 1 user benefitting and having 15kB/s, you will have 3 users SHARInG the 15kB/s bandwidth, so each will still have 5kB/s.

in this case I set the example up as having the same number of uploaders as downloaders, but if a file is rare then the downloaders will exceed the uploaders by far...making it VERY hard to get a proper speed, eg. 3 uploaders at 15kB/s but 10 downloaders, 15/10 = each person gets 1.5kB/s.....

the approach we have now is you may have to wait a while for a slot, but once you get it you are almost garanteed to have a good speed...multi source can be very unstable.

also what I meant with "disease" was, lets say an ex-kazaa user gets onto dc++, he will have one of those AWFULL mislabelled movies, that turns out to be a cam or SMR (oh god... :shock: ) there will be a lot of users that will get this file (due to the multisorce thing, it will spread faster) and they will not know that they are getting a low quality file. and after a while so many people will have it that the high quality files will start to become more rare and harder to get.


hope this cleared something up, anyway, I ask you to think about this carefully.


BTW: I ask once again, what is the reason for wanting multisource? what's wrong with dc++ atm that you would want it to change?

ojmyster
Posts: 8
Joined: 2004-04-19 11:52

Post by ojmyster » 2004-05-01 07:06

While I understand the complexities of multisourcing in DC++ that have already been explained I don't however agree that they are a distinct problem.

I beleive multisourcing would cause a global change to DC++. For example, we would probably see the average number of slots increase. This is because there would be an increase in active transfers. However, the transfer speeds would be a lot lower per slot (on in cases where an upload was part of a multiple source upload.) With this is mind I must also point out that slots would be taken up for a vastly smaller ammount of time. You could quite easily find that a slot would be taken up for only 50% or less of the time it woudl have otherwise been open.

As far as data integrity and file errors are concerned I think this is a weak point of arguement. Matching all the parts of the file together at the end of the transfer is on;y a matter of good software. Also, the theoretical data interity probability is inversly proportional to the speed of the transfer. For example, the faster the transfer, the more lickly you are to experience errors (not that this is a strong point of arguement but it is still a factor).

I can't see how Hub performance will suffer greatly from an increase in TTL searches. I thin most ppl TTL search their downloads in the event that their primary source disconnects or becomes unavailable.

I think its a matter for testing rather than theorising.

Josh

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

Post by GargoyleMT » 2004-05-01 09:49

unruled wrote:BTW: I ask once again, what is the reason for wanting multisource? what's wrong with dc++ atm that you would want it to change?

I think I answered this earlier:

GargoyleMT wrote:
unruled wrote:is there ANYONE here that has a good argument for multisourcedownloading? Except for speed?

Sure: users manually manage sources a lot, and want even more tools for doing so in DC++. If files could be downloaded from more than one source, a download currently running at 5 kilobytes per second would be perfectly fine, since other sources could be added to it. This means a less cluttered interface in DC++ and less bloat in the code.


unruled wrote:HOWEVER, heres the drawback... there are 3 other users that want to download the file, so then instead of 1 user benefitting and having 15kB/s, you will have 3 users SHARInG the 15kB/s bandwidth, so each will still have 5kB/s.

It depends on how many slots the user has open. Multi-source downloading will still use slots. Sure, some users might open more, but hub rules will prevent them from opening too many slots, just as they do now.

unruled wrote:also what I meant with "disease" was, lets say an ex-kazaa user gets onto dc++, he will have one of those AWFULL mislabelled movies, that turns out to be a cam or SMR (oh god... ) there will be a lot of users that will get this file (due to the multisorce thing, it will spread faster) and they will not know that they are getting a low quality file. and after a while so many people will have it that the high quality files will start to become more rare and harder to get.

This is interesting. How can a single user's files spread faster under multi-source downloading, since you are claiming that the speeds will be the same or slower? It doesn't make sense.
Also, users are still encouraged by anyone who knows anything to verify and properly sort their files. Common sense just won't fly out the windows if/when safe multisource is implemented...

unruled
Posts: 10
Joined: 2003-05-15 12:49

Post by unruled » 2004-05-01 09:52

ojmister thats a good point, I take that into consideration.
btw I was thinking about a good feature that would increase availability - the way that edonkey and bittorent work, once a certain 'part' is completed it can be shared even if the download isnt finished...I know this would be a HUGE thing to write up in code and difficult too, but I think its a pretty good system. this will not be around for a long long time as far as I can see :lol:
anyway, this is getting complicated...(damn where is someone to back me up here :shock: )
Il see if I can come up with any more ideas.
Last edited by unruled on 2004-05-01 09:57, edited 1 time in total.

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

Post by GargoyleMT » 2004-05-01 09:55

unruled wrote: the way that edonkey and bittorent work, once a certain 'part' is completed it can be shared even if the download isnt finished...I know this would be a HUGE thing to write up in code and difficult too, but I think its a pretty good system.

It's called Partial File Sharing (PFS). It's on our Radar, and it's been talked about along with same-hub source exchange among us developers. With the ADC protocol core, it might be easier to implement, as well.

unruled
Posts: 10
Joined: 2003-05-15 12:49

Post by unruled » 2004-05-01 10:02

thats nice to know, I also just thought of some ideas, for example having certain hubs that would support multisource whilst others wouldn't (although this is upto the hubs...not u guys..) or something like a trial period of multisource and to then take a poll, or to collect some statistics on the networks ability to transfer files and the avg. speeds and compare the 2.

:)

Aletannica
Posts: 4
Joined: 2004-04-29 10:29
Location: Italy

Post by Aletannica » 2004-05-03 09:01

GargoyleMT wrote:
Aletannica wrote:and I would want that they were shown or in the tag or in the description line

If multi-source ever gets into DC++, you'll be free to restrict the legal clients in your hub to earlier versions of DC++. Having it in a tag (description) serves no purpose.


I've have request this, because in much forum is discussed that the multidown " steal " the slot,for example a user that it has set up 40 max alternate sources (default of all multidown clients) it could occupy 40 slot (much theoretically), this in a small hub would be a problem, if I know how many alternate sources are setting I can kick the user whit the reason that in my hub I accept the multidown set up with max 3/4 alternate sources

Sorry for my bad english, I hope to have you understand

Blade^^
Posts: 9
Joined: 2004-03-30 11:24

Post by Blade^^ » 2004-05-04 04:57

It sure is going to be hard to make a multi download system that works without messing up the current dc system to much.

People that worry about bad files being spread faster, the chance that bad files being spread is actually smaller with multi source downloading, since people will be searching for TTH and not for names so even if someone shares a bad file even if it has the same name and even the exact same size the TTH outcome will still be different so it won't be downloaded. (coz if you find 20 with the same name and size and 19 have the same TTH your not going to download the 1 with a different TTH that just stupid...)

It would also be nice to see some support by the release groups if they put the original TTH in the nfo or in the filename. Some groups already do this with CRC and it increases the overall file quality.

It's called Partial File Sharing (PFS). It's on our Radar, and it's been talked about along with same-hub source exchange among us developers. With the ADC protocol core, it might be easier to implement, as well.


But this would mean people will share unfinished files.. That would be messy, since if you stick the unfinished files in the temp folder no one can search for them unless the temp folder is shared. And you might get something like bit torrent ending up at 80% and finding out that there no compleat file left on the hub (Same thing as running out of seeds on bt). Or maybe I am missing something here.


I also think there should a hub side option to enable multi source for all clients or turn it off for all clients (i know they can just ban the client with multi source but this will a disadvantage when bug fixes come out)

I will leave it up to the smart people to think of a good mutli source download system since i have nor the knowledge nor any technical experience with multi source downloading.

Tho i do think there should be something to set the maximum amount of sources depending on the up/down load ratio. Becouse this system would fail when 56k users start taking up 10 slots... Then again most adsl lines should have more then enough for 4 to 6 sources at the same time but then again people with a 10mbit + line would need a lot more but if they take to many slots evrything would just come to a hold up... so nr of max sources set to there upload speed would be nice (also would stop nr off bandwith limiters since they won't get more then 1 source..)

ok.. my post is long enough now >_< +me is quite...
// Blade

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

Post by GargoyleMT » 2004-05-04 19:36

Blade^^ wrote:It would also be nice to see some support by the release groups if they put the original TTH in the nfo or in the filename. Some groups already do this with CRC and it increases the overall file quality.

TTH will enable DC++ to handle Magnet-URI links, which will let anyone put a root hash and a filename in a link on their website, and allow DC++ to add a file to the download queue from that information - you'll have to find sources in connected hubs, as per normal.

Blade^^ wrote:But this would mean people will share unfinished files.. That would be messy, since if you stick the unfinished files in the temp folder no one can search for them unless the temp folder is shared. And you might get something like bit torrent ending up at 80% and finding out that there no compleat file left on the hub (Same thing as running out of seeds on bt). Or maybe I am missing something here.

Don't worry, we've (I've) thought about it a lot. Allowing partial files to propogate through search (to be returned as hits) will only be possible on the ADC core hubs (where you can define a field to mean "this is a partial file, with this % or this range downloaded"). Once you have one source, two PFS supporting clients could also exchange known partial-sources (for the same hub only - to avoid leaking information about sources on private/other hubs). Anyhow, those are all implementation details that you really don't need to worry about - if it gets coded, we're not going to fuck you.
Also, some P2P clients on the Gnutella network won't share partials if it doesn't know aobut at least one full source. Likewise, they won't return hits if there's no full source out there. I've been stuck with orphaned files on the eDonkey network, I won't let that go unaddressed.

Blade^^ wrote:I also think there should a hub side option to enable multi source for all clients or turn it off for all clients (i know they can just ban the client with multi source but this will a disadvantage when bug fixes come out)

I'd really, really, prefer that additional information not go into the tag (or allow hubs to turn off any functionality in DC++). Yes, bug fixes will be missed by those who mandate an old version - but there aren't too many situations where you'll find otherwise. Irix (the SGI OS) is one exception - you can download a feature full "dot release" of the new OS if you've paid your license, or a "bugfix only dot release" if you haven't. When/if the day where multisource arrives in DC++, and hubs ban that version, I'll accept payment in return for backporting fixes.

Blade^^
Posts: 9
Joined: 2004-03-30 11:24

Post by Blade^^ » 2004-05-05 02:40

Thanks for the great replay GargoyleMT, And I guess I was right :) I should leave this to the smart people like you :roll: Your already way ahead of me (and probably anyone else ) on this.

+me watches in awe...
// Blade

Shroom
Posts: 30
Joined: 2004-04-01 04:09
Location: Sweden

Post by Shroom » 2004-05-05 06:59

Agreed. It's nice to know that the DC++ team seems to know what they are talking about, and that they won't implement any functions before they are well thought through.

I’m really looking forward to the new protocol and what could be accomplished once its implemented. Cheers.

Blade^^
Posts: 9
Joined: 2004-03-30 11:24

Post by Blade^^ » 2004-05-05 07:32

Shroom wrote:Agreed. It's nice to know that the DC++ team seems to know what they are talking about, and that they won't implement any functions before they are well thought through.


Wasn't expecting anything less from the DC++ team =)
// Blade

BSOD2600
Forum Moderator
Posts: 503
Joined: 2003-01-27 18:47
Location: USA
Contact:

Post by BSOD2600 » 2004-05-05 09:43

Dude, if you dislike DC++ so much stop using it. Even better, how about you code in the features you want.

DC++ is free, live with what it is.

Blade^^
Posts: 9
Joined: 2004-03-30 11:24

Post by Blade^^ » 2004-05-05 10:08

BSOD2600 wrote:Dude, if you dislike DC++ so much stop using it. Even better, how about you code in the features you want.
.DC++ is free, live with what it is


Where did I ever say I did... I like DC++ a lot its by far the best DC client there is, I just had some doubts about the implantation of mulisource downloading since that's going to affect the whole DC community...

But I never intended to insult anyone, I know the DC++ team puts a lot of effort in making DC++...
// Blade

BSOD2600
Forum Moderator
Posts: 503
Joined: 2003-01-27 18:47
Location: USA
Contact:

Post by BSOD2600 » 2004-05-05 15:30

Blade^^ wrote:Where did I ever say I did... .
By flaming and trash talking the people on the DC++ team.

Just accept the fact that DC++ will have multi-source downloading when its ready.

Locked