1 Client that has Different Shares in Different Hubs

[JoeBuhdee 0]

?

[Zlobomir 3]

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

[Big Muscle 1]

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.

[Satan 1]

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.

[JoeBuhdee 0]

Just a thought, this would definitely make Apex an even better client!

[Crise 26]

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.

[Kryppy 0]

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)

[Satan 1]

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.

[Big Muscle 1]

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.

[JoeBuhdee 0]

Thanx. Just giving out ideas.. :)

[Pothead 0]

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:

[Zlobomir 3]

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.

[Kryppy 0]

Zlobomir do you mean a share skiplist option in favorites hubs properties? sounds nice :)

[Zlobomir 3]

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.

[Lotus 0]

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.

[Crise 26]

Please, an year old topic....

[Big Muscle 1]

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 ?

[Big Muscle 1]

Please, an year old topic....

ah true I haven't notice a year :crying:

[Lotus 0]

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 ?

[Big Muscle 1]

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.

[Lotus 0]

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

[Lotus 0]

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...

[Big Muscle 1]

I don't use it so much. Only one hub.