Sign in to follow this  
Followers 0
JoeBuhdee

1 Client that has Different Shares in Different Hubs

23 posts in this topic

This was discussed many times before, and the excuse was missing ADCsupport and user identification. What's about now?

Share this post


Link to post
Share on other sites

The reason of not implementing is that it can be abused for destroying the network => users will share only a minimum amount on each hub to decrease their upload.

Share this post


Link to post
Share on other sites

Surely certain limit's could be put on it? Such as you must share a minimum of 75% of your total shared data or summit? iono.

Share this post


Link to post
Share on other sites

It should not be up to the client/programmers to decide whether or not that ability will destroy a network.

Fact here, it is exactly up to client developers to do those decisions... if there is a possibility that a feature may have negative effect on the network in a wider scale it should not be implanted at all.

Share this post


Link to post
Share on other sites

i like the idea, not to share only a minimum amount on each hub , but it will allow me to share more stuff in some hubs.

Actually i must run two clients: one with the stuff which is allowed everywhere (mp3 , rar , avi.....) and one with the stuff that only some hubs let share (vob for example)

Share this post


Link to post
Share on other sites

I would like to be able to share all my rar's in one hub. Thats the only one I want, I have a few rar hub's I would like to share only my rar's in.

Share this post


Link to post
Share on other sites

It should not be up to the client/programmers to decide whether or not that ability will destroy a network.

Programmers make clients to develop the DC network, so it's up to them to ensure that network won't be destroyed by stupid users.

Hubs have minimum shared GB implemented as well, counter measure enough for that.

And this is exactly the reason why it won't be implemented.

Hub A: min share 5 GB

Hub B: min share 15 GB

Hub C: min share 40 GB

now user being in hubs A,B,C needs to share 40 GB, so it provides great amount of data also in hubs A and B.

Implementing hub-dependent share would allow him to share only 5 GB in hub A and only 15 GB in hub B. So his upload would decrease dramatically and amount of shared data in network would decrease too.

Share this post


Link to post
Share on other sites

Carraya has just done this for "Nothing" which is built on flowlib. Works properly on both NMDC and ADC. :)

heh, nice to see it actually got done properly on NMDC, with regard to the 5+ years people have been requesting this on different clients. :blushing:

Share this post


Link to post
Share on other sites

Erm, put in Fav Hubs a file extension filter for each hub? :) So no abuse. These "secondary" FLs could be probably created even dynamically on connect, so disk space will be saved.

Share this post


Link to post
Share on other sites

Not exactly, more like the reverse "share only files with these extensions". So it won't be needed to write a book to skip for each hub.

Share this post


Link to post
Share on other sites

The reason of not implementing is that it can be abused for destroying the network => users will share only a minimum amount on each hub to decrease their upload.

So what ?

If a hub owner allows min share of only 1 Gb, then it's his decision not yours. The only network that will be "destroyed" will be his hub. But why are you taking decisions for him ?

If an owner will see that all his users are sharing the bare minimum, he has the simple option to increase that minimum. This will produce an interesting hub stratification.

Users will have the option to connect to hubs with more share, if they want to. Serious users will gather on those hubs... kids or whatever will join hubs with 0 Gb share. If I want download, I will only connect to large share hubs... what would be the purpose of setting a small share on hub X and connect to it, if on hub X there is not much share at all ?...

Instead, this option will allow to share *different types of file* on different hubs, making possible hubs oriented on specific materials. Nice idea from my point of view.

Share this post


Link to post
Share on other sites

Carraya has just done this for "Nothing" which is built on flowlib. Works properly on both NMDC and ADC. :crying:

heh, nice to see it actually got done properly on NMDC, with regard to the 5+ years people have been requesting this on different clients. :)

How does it ensure that incoming connection from IP 12.34.56.789 belongs to hub X and therefore it should provide filelist #2 ?

Share this post


Link to post
Share on other sites

Sorry for the old topic, I'm pretty new here.

Do you think a modification in the protocol so that when a peer connects to me he must also send me a reference to the hub from where this connection was initiated... do you think such a protocol modification could be supported and would be welcome by the hubsoft developers ? Or useful ?

Share this post


Link to post
Share on other sites

Current NMDC protocol is almost dead, so no other modification to it. There is modification which sends hub url in the latest dc++/strongdc++, but it isn't still what it needs to work properly. And also, there are another reason not to implement this feature, not only protocol limitation.

Share this post


Link to post
Share on other sites

Okay, so this means that my Find_User_Ip bot will continue to work properly in the future... no worries... :) :)

Share this post


Link to post
Share on other sites

Current NMDC protocol is almost dead, so no other modification to it.

Yes, but you use it. And most hubs does. I don't follow your logic. You don't want to improve it because it is dead. But you have no problems using it, with all the problems it has, dead as it is...

Share this post


Link to post
Share on other sites
Sign in to follow this  
Followers 0