Auto 1 slot to each hub a user is in

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

Moderator: Moderators

Locked
hardist
Posts: 49
Joined: 2003-02-06 23:26

Auto 1 slot to each hub a user is in

Post by hardist » 2003-03-24 18:37

Some one please explain to me why it is SOOO bad to ask for a function that would automaticaly open 1 slot for every hub a user joins ?

We all know that ++ is used as a leeching tool and no one likes it to be used that way, and still there is fierce oppostion to any suggestion that this function be implemented .

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

Post by GargoyleMT » 2003-03-24 19:42

What's wrong with letting hubs enforce their own rules for slots?

hardist
Posts: 49
Joined: 2003-02-06 23:26

Whats wrong with not having leechers

Post by hardist » 2003-03-24 19:59

Whats wrong with having 1 slot open if your join a hub .

hardist
Posts: 49
Joined: 2003-02-06 23:26

In my opinion

Post by hardist » 2003-03-24 20:01

Hub count and slots should at least match.

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

Post by GargoyleMT » 2003-03-24 20:28

Why? Neither of the hubs I'm in right now have slot requirements. Letting hubs enforce their own rules seems to make the most amount of sense.

If you want this change, you need to convince people that it's worthwhile... If nothing else, you have to be convincing enough so that one programmer implements it, and then convincing enough that Arne will accept the patch.

hardist
Posts: 49
Joined: 2003-02-06 23:26

Why ? Simple...

Post by hardist » 2003-03-25 02:51

DC is a SHARING program.

The way ++ is set up now you can be in 30 hubs , have 20 slots open , and all 20 of those slots taken by users in one hub. Effectivly making you a leech in 19 other hubs .

Slots are not addressable to the hub they go to first come first serve , that just hurts in the long run. You can also set it up so that you only have 1 slot , no mater how many hubs your in , again this is NOT sharing! If you expect to be able to go into a hub you should by all that is right have at *** least*** one slot deticated to that hub. After all the hub is not there just so YOU can go in and download, it is there so everyone in the hub has a chance of at the very least 1 slot that you, as some one who wants access to that hub, should be able to supply , the way its set up now , hubs get screwed. it looks like a user that comes in is a good user to have , but in reality , the chance of getting a slot is nill.
Everyone wants to pretend that ++ users are responsible enough to be fair , they are not , they use the slot setup to their advantage , all the while degrading the overall DC experiance. The way I see it , if you want the privelage of entering a hub you should give that hub at the very least 1 slot for the privelage of being there . This is not KAZZA. And hub owners put a lot of work into making a nice hub , to be rewarded with this lame slot setup. I dont know how much more simply to say it .....

ivulfusbar
Posts: 506
Joined: 2003-01-03 07:33

Post by ivulfusbar » 2003-03-25 05:10

i have to agree with GargolyeMT, this should not be implimented and this is not a issue. DC++ informs the hub it enters with the dc++-tag, then the administrators of the hub can choose what todo.
Everyone is supposed to download from the hubs, - I don´t know why, but I never do anymore.

hardist
Posts: 49
Joined: 2003-02-06 23:26

Hmmm

Post by hardist » 2003-03-25 05:31

So it is up to the HUB to police ++ , not the ++ client to be fair.

Interesting concept.

hardist
Posts: 49
Joined: 2003-02-06 23:26

So a new project...

Post by hardist » 2003-03-25 05:40

Write a hub that will not let you in unless you give it an exclusive slot .

Thanks thats MUCH easier to do.....




sheesh !

Sedulus
Forum Moderator
Posts: 687
Joined: 2003-01-04 09:32
Contact:

Post by Sedulus » 2003-03-25 05:41

rule #1
never trust clients
http://dc.selwerd.nl/hublist.xml.bz2
http://www.b.ali.btinternet.co.uk/DCPlusPlus/index.html (TheParanoidOne's DC++ Guide)
http://www.dslreports.com/faq/dc (BSOD2600's Direct Connect FAQ)

hardist
Posts: 49
Joined: 2003-02-06 23:26

Ok I get the point , same as always, but...

Post by hardist » 2003-03-25 16:51

I still would like an explanation that makes sense about WHY its such a "bad" function to implement .

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

Post by GargoyleMT » 2003-03-26 20:06

Because your "one slot per hub" shoe does not fit my foot. If you're trying to combat the problem of people opening too many hubs, this will not work. People will simply not upgrade to the new version, or they will make (or find) a client that will lie about slots to you.

I've already seen people open as many slots as hubs required by rules, knowing full well that their upload stream wouldn't support it. Their explanation was that if hubs wanted to require, for instance, 5 slots for 2 open hubs [knowing that the average transfer rate would be 2kbps], then that's not their problem. If they had a choice, they'd only keep open, for instance, two slots so that someone would be getting at 5kbps each.

My point in that cruddy little story is that good users will use good judgement about what's best for them to share and how. I really like to trust the user and not artificially restrict them because some other, stupider or more mailicious users misuse the freedom that the client currently offers.

I'm still waiting on a persuasive rationale from you. :-/

hardist
Posts: 49
Joined: 2003-02-06 23:26

Ok I see where you are comming from .

Post by hardist » 2003-03-28 05:33

And your absolutely right.

So let me start by saying , I think DC++ does so many things better than NMCD. All in all it IS a better program . The Problem I see with it is it creates and justifies users to be a drain on a system that at one time worked. ++ is very popular , lotz of people use it , so much so that the slot rules that were once standard in NMDC majority hubs were changed,everyone wanted this new better program that allowed you to open so many more hubs and get more stuff. All fine and good , so far, then they realized that since they were in all these hubs they had reached a threshold and could no longer support being in these hubs and sharing in all of them ( as you mentioned ^) thus the REAL problem is born , NOW no one wants to be limited to how many hubs you can be in, and they are will do anything ( again as mentioned above ) to bypass ANY rule set upon them which would limit them in ANY way.

What you need to realise is DC is in a slow decay more and more users in more and more hubs , expanding the total shares for DC by being in all these hubs. Yet in reality , they ars not contributing to ALL these hubs ( at the most an average user can suport 4 slots with a descent UL rate ) that means 4 possible hubs (at a 1 to 1 ratio) are really reporting VALID shares , all the other hubs he's in are NOT .
Imagine that this user is in 20 hubs and and sharing 100 gb.
That makes 4 hubs reporting 400 gb shared.
and 16 hubs reporting a bogus 1600 gb.

Now multiply that by just 100 users.

Do you see what NOT making a user share in every hub he is in does to DC now ?

Also IF you make a user share 1 slot for every hub , eventualy he will reach a limit as to how many hubs he can be in cause his DL rate will drop to nothing.

NMDC is a resource HOG and you can only run so many instances which is the GOOD thing about it because you couldnt be in outrageous numbers of hubs.
Remember when Leechers were people with fake shares , NOT people in 100 billion hubs and 1 slot ?

So you say the 1 slot shoe dont fit your foot .

I say your foot has cancer and is killing DC.
It may be slow , but its sure , UNLESS we wake up and put these LIMITS back in place.

I would hate to see the day when people talk about DC with the same distastefull tone they use when they talk about KAZZA........

Sedulus
Forum Moderator
Posts: 687
Joined: 2003-01-04 09:32
Contact:

Post by Sedulus » 2003-03-28 05:44

your shoe has been in the wrong place.
I think you should go to hubs that have/enforce 4 hub maximum (or less) rules.
problem solved.
http://dc.selwerd.nl/hublist.xml.bz2
http://www.b.ali.btinternet.co.uk/DCPlusPlus/index.html (TheParanoidOne's DC++ Guide)
http://www.dslreports.com/faq/dc (BSOD2600's Direct Connect FAQ)

hardist
Posts: 49
Joined: 2003-02-06 23:26

Did you catch the error ?

Post by hardist » 2003-03-28 06:29

"The way ++ is set up now you can be in 30 hubs , have 20 slots open , and all 20 of those slots taken by users in one hub. Effectivly
making you a leech in 19 other hubs ."


Guess not , and by NOT catching it you ruined my best line.


" So you CAN do the math"

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

Post by GargoyleMT » 2003-03-28 09:25

This isn't going to be a full blown response, because I'm on my way to work (soon, soon).

I think your energy is misdirected. If you -want- to enforce sharing regardless of how many hubs someone is in, you'd be better off supporting the idea of a ratings system (check past threads) or an upload queue. One way to work an upload queue is to have, essentially, a line per hub you're in, and select the next person to get the slot from those lines. (To combat being in one hub for a long time, having a lot of people in line from that same hub, then connecting to another hub and having users from that hub go to the end of the first line.) To make this effective, you'll have to enforce a time or byte limit on slots, so they don't get hogged.

True, people being in multiple hubs inflate the share totals, but that's not the problem. The problem is that it's hard to get a slot. You'd have to hub-lock slots (or the above solutions) to make that work well. There's no reason why people's downloads would ever slow down, hopefully every user out there with Asymmetrical connections use a throttling client a couple kb below their upload limit. I just don't see people being deterred by opening multiple hubs.

If you're thinking of what ruins kazaa, it's probably the half-life of the user. People opening 30 hubs are probably in the same mindset: get what you want as fast as possible and leave. That kills every P2P application. Enforcing slots/hub ratios doesn't do anything to solve that.

You can't force those people to stay and contribute to the community. I do that and am not part of the problem: 115.0gb/32.8gb now on a crappy 128kbit upload.

hardist
Posts: 49
Joined: 2003-02-06 23:26

I disagree Gargoyle

Post by hardist » 2003-03-28 17:11

The simpelest way is to make the client give each hub it enters at least 1 slot , JUST for that hub , and get rid of the wandering slots.

Marvin
Posts: 147
Joined: 2003-03-06 06:56
Location: France
Contact:

Post by Marvin » 2003-03-28 18:17

Since you can't assign slots to hub, this might require major changes in the way DC++ handles slots and hubs. It is really simple to handle the to many hubs problem at the script level.

hardist
Posts: 49
Joined: 2003-02-06 23:26

True you can handle the problem at a hub/script level , but

Post by hardist » 2003-03-28 18:33

The problem still remains , as long as ++ uses a wandering slot setup , it will ALWAYS be a leeching client.

Marvin
Posts: 147
Joined: 2003-03-06 06:56
Location: France
Contact:

Post by Marvin » 2003-03-28 18:37

Leeching in p2p is something you can't avoid, regardless of the protocol/client employed, unless a rating system is implemented.

[KUN.NL]mepmuff
Posts: 73
Joined: 2003-01-06 09:32

Post by [KUN.NL]mepmuff » 2003-03-28 18:38

No matter what p2p client, or what p2p protocol, there will ALWAYS be ways for leechers to do their leeching. Assigning slots to hubs won't change that...

hardist
Posts: 49
Joined: 2003-02-06 23:26

ok , then what ?

Post by hardist » 2003-03-28 18:49

That is true, but why make it EASY for people to do it , yes there will always be leechers , but why allow a slot setup the WILL be abused .
Most users cannot alter the code to leech , most use ++ cause its easy to DL ans setup , I just propose a majority fix.

Before ++ came along this was NOT a problem. Now every one needs to write scripts to "handle" it, the problem is not the hubs its not the users , its the client.

++ is responsible for this problem .
So why is it too much to ask thet ++ addresses it , and fixes it ?

mo
Forum Moderator
Posts: 81
Joined: 2003-02-06 11:20
Location: Ohio
Contact:

Post by mo » 2003-03-28 23:17

hardist wrote:The way ++ is set up now you can be in 30 hubs , have 20 slots open , and all 20 of those slots taken by users in one hub. Effectivly making you a leech in 19 other hubs .
Why would having 30 slots be any better than 20 in this case?
30 is a ridiculous amount of slots to be sharing.
hardist wrote:The simpelest way is to make the client give each hub it enters at least 1 slot , JUST for that hub , and get rid of the wandering slots.
There are many times that 1 hub will eat up more slots than another, but locking a slot per hub is not the answer.
Your effectively reducing the amount of slots that your sharing to the whole community.
Many of the open slots will go unused.

hardist
Posts: 49
Joined: 2003-02-06 23:26

Yes 30 is

Post by hardist » 2003-03-28 23:38

Its also rediculous to be in hubs your not sharing in, THAT is what degrades DC.

How can you say locking the slot to the hub is not the answer , if you do that you also limit the number of hubs you can be in by default.

I say if you want the privelage to be in a hub ( it's NOT your god given right, no matter what you think) you should give that hub at LEAST 1 slot.

mo
Forum Moderator
Posts: 81
Joined: 2003-02-06 11:20
Location: Ohio
Contact:

Post by mo » 2003-03-29 00:29

hardist wrote:it's NOT your god given right, no matter what you think
Your right, it's up to the hub owners/ops to decide. (not hardist)
hardist wrote:you should give that hub at LEAST 1 slot.
Who are you to say what all the hub owners/ops want?

Personally, I say you should only share as many slots as your connection support.

If you want to be in 20 hubs on your isdn line, sharing 20 slots is worthless.
Everyone will get their nice slice of a 16k connection.
that works out to 800 bytes/sec...

You should stop worrying about what you think all the hub owners should enforce, and worry about your own hub, if you even own one...

hardist
Posts: 49
Joined: 2003-02-06 23:26

Show me

Post by hardist » 2003-03-29 01:04

Show me just 1 hub where they DONT want you to share .


You can act like I want this JUST for me , but you should know better.

hardist
Posts: 49
Joined: 2003-02-06 23:26

Mo did you read ANY of this post ?

Post by hardist » 2003-03-29 01:13

I dont want to be in 20 hub , I dont want more leeching , and I am not telling anyone anything , the ORIGINAL DC was set up so that each user had slots open in each hub he entered. That is the way DC was made.
Until ++ changed that for the worst.

You being a moderator , I would think you would be above telling me what I should worry about.

ivulfusbar
Posts: 506
Joined: 2003-01-03 07:33

Post by ivulfusbar » 2003-03-29 01:39

yes and no, the original protocol and client was devolped with one client, one hub in mind. And how the protocol is written now, its impossible to know from which hub an "incomming" connection is from. Ofcourse you could try to hack this by adding different ports for different hubs.. i will not go into more details on the subject...
Everyone is supposed to download from the hubs, - I don´t know why, but I never do anymore.

hardist
Posts: 49
Joined: 2003-02-06 23:26

Thats interesting

Post by hardist » 2003-03-29 01:42

I never thought of that approach.

Thanks for the idea.

hardist
Posts: 49
Joined: 2003-02-06 23:26

Mo let me shoot this back at you....

Post by hardist » 2003-03-31 03:34

mo wrote:
Who are you to say what all the hub owners/ops want?
I reply:
Who are you to say what all the hub owners/ops don't want?


I am not telling you what anyone want's . I am trying to discuss a controversial feature, as the name of this forum suggests.

mo wrote:
If you want to be in 20 hubs on your isdn line, sharing 20 slots is worthless.
Everyone will get their nice slice of a 16k connection.
that works out to 800 bytes/sec...


I reply:

If your in 20 hubs with ++ and your slots are taken by 4 of the hubs your in . You are a leech in 16 other hubs.

You cant get around this.

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

Post by cologic » 2003-03-31 08:37

So it is up to the HUB to police ++ , not the ++ client to be fair.

Interesting concept.
It's a correct one, though. As sedulus points out, the client is under your mindset under enemy (potential leech) control. The hub, on the other hand, has an incentive/self-interest to correctly enforce its desired rules. Which would you trust more?
I still would like an explanation that makes sense about WHY its such a "bad" function to implement .
It's not, in principle, "bad". Rather, it represents an unnecessary loss of choice on the part of the user, and for no appreciable gain.
mo wrote:
Who are you to say what all the hub owners/ops want?
I reply:
Who are you to say what all the hub owners/ops don't want?


I am not telling you what anyone want's . I am trying to discuss a controversial feature, as the name of this forum suggests.
And you're generating controversy. Good for you.

Hub owners may want a pretty pink pony too. As "who are you to say what all the hub owners/ops don't want", I propose you give all the hub owners a pony. Who knows, they might want one. Certainly as much as you've supported their desire for this auto slot/hub 'feature'.
If your in 20 hubs with ++ and your slots are taken by 4 of the hubs your in . You are a leech in 16 other hubs.
Well, for the time period during which users from those four hubs are downloading from you, sure. Once they finish, the sixteen previously underserviced hubs' users get as much of a chance as anyone else at your slots. Over the long run, this averages out, unsurprisingly, to <total slots>/<total hubs> slots/hub, even if the former is less than the latter. While you may consider 0.2 (or whatever the math works out to) slots/hub leeching, it's certainly not the simplistic 0 slots/hub for those other 16 hubs that you seem to propose, and people from every hub, if they so choose, will likely get a slot from you should you remain on that hub.

hardist
Posts: 49
Joined: 2003-02-06 23:26

cologic

Post by hardist » 2003-03-31 17:12

I am olny dealing with the last part of your post.

It doesnt mater how many hubs your in at all as long as the hub count is higher than the slot count , even when the slot is free it will go to another hub or stay open , but it will NOT increase.

If we use the model I have been using , sure slots dont stay used and open eventualy , but it doesnt matter, you are still a leech in 16 other hubs , they may not be the same hubs , but the numbers dont change.

Pretty pink ponies , stop smokin that shit.

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

Post by GargoyleMT » 2003-03-31 18:46

Ok, so basically you're saying that if potential downloaders from one hub have to compete with potential downloaders from other hubs for a slot, then you're a leech, but if potential downloaders from one hub have to compete against users from the same hub for a slot, you're not a leech?

Please reconcile your posts and follow up with a single, coherent argument. Really.

You've gotten excellent visibility and response here, but you're the only one who is supporting this idea. That should tell you something.

AlleyKat
Posts: 40
Joined: 2003-01-31 15:37
Location: Denmark

Post by AlleyKat » 2003-03-31 19:58

I think hardist's idea is brilliant. Then I'd just have to limit the speed for each of the "perm" slots to keep leeching.... :lol:

Hubs enforcing max hubs limits essentially does the same. Waste no more keypresses on this issue, and think up new ideas instead of cooking the same soup twice.

Personally, I'm still for a download-following-upload scheme, feeling a ratings system would be too extensive, too much in risk of being abused/hacked/flooded with crap.

Anyway, I'll bet it wouldn't take 2 days before such a scheme was broken by some leecher making fake slots connection or whatever they'd come up with. The problem of fakers and leeches has been kept remarkably low on DC due to its nature. It'll grow... but then again, efforts will be made to fight it I'm sure!
____________________________
Sure, Paranoia is my middle name - but only when I'm me.

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

Post by cologic » 2003-03-31 20:16

Pretty pink ponies , stop smokin that shit.
Here's the more explicit version:

You set the statements
Who are you to say what all the hub owners/ops want?
and
Who are you to say what all the hub owners/ops don't want?
as if they're comparable statements. They are not.

mo makes a good point, which could be falsified if, in fact, you were able to show that there's been a great demand for this 'feature' in DC++ by numerous ops. As demonstrated here and at other DC forums, they're a vocal bunch; they complain when they don't like something, or want a change. I haven't seen any widespread movement for this change.

As the one who began this thread, and who's attempting to persuade others of your point of view, you should be presenting evidence to justify the inclusion of this change into DC++.

I brought up the pretty pink pony to show that the basic structure of your argument is fatally flawed: I haven't heard any of them so far deny such a desire. Their silence on this issue does not imply that they all want a pretty pink pony, as you're analogously claiming their silence effectively counts as support for your pet idea here.

That last bit of rhetoric, then, is misleading and intellectually dishonest; find a method of argument that isn't complete and utter shit next time.

The pretty pink pony was an attempt to illustrate this concept implictly.

Twink
Posts: 436
Joined: 2003-03-31 23:31
Location: New Zealand

Post by Twink » 2003-03-31 23:37

You do realise that some hubs aren't for downloading dont you?, at the moment I have a few main hubs for downloading from, then select people from that hub are in another hub that I'm also in for a decent conversation. So it's not always wanted to have a slot per hub.

Also your point that you are in 30 hubs, and all your slots are used by one of them making you a leecher in 19 (you mean 29 dont you?) isn't really valid, I doubt that all 20 slots will be used by the one hub for all eternity, in fact in 30 days you may find that it averages out.

Then my mate bob, who is in 4/5 of the same hubs as me tries getting a slot from me. Which hubs slot does he take?

hardist
Posts: 49
Joined: 2003-02-06 23:26

Cologic lets get this straight

Post by hardist » 2003-04-01 02:33

Lets get this straight, I did NOT start that "who are you to say" bullshit. I just pointed out the reverse. Why does everyone assume that I am trying to speak for anyone .

I have seen this question asked on EVERY ++ board I have seen, and its always the same , some person or another comes in and starts bashing the person posting instead of discussing the matter at hand , then others jump in , and the person gives up.
I do not say EVERYONE wants this or that its HAS to be done , I am just saying what ALOT of people have thought and talked about . Now I know this IS a ++ friendly board and you all do not like people finding any thing wrong with a program you love and use, but you seem to think that just because ++ is popular and people use it , all its functions are ok , I do not . I see ++ as a drain on a good system , and if you dont agree, fine . I am NOT jumping down YOUR shit just cause you dont agree , so give me the same consideration.

So as far as your claim that since no one is jumping on my bandwagon , so to speak, that it is not desired by any one . Remember you ++ users are a visious bunch when anyone challenges what + should be allowed to do, and people see that. Most will not risk posting a thread like this in a ++ forum because of it .

[KUN.NL]mepmuff
Posts: 73
Joined: 2003-01-06 09:32

Post by [KUN.NL]mepmuff » 2003-04-01 03:09

Off topic:

Hardist: I do believe most posts are sincere in this thread. Most people just don't agree with your point, or don't see how that proposal would make dc++ better anyway. Don't let a few flamers get to you.

Saying you haven't been taken serious is way over the top IMHO.

Now back on topic:
Why do you think that hub policies (like max hubs, min slot/hub ratio) won't work for this leeching problem?
I don't understand your math. I am of the persuasion that the slot-hub distribution will level out over time. If people can queue, they can get a slot. If I just stay in that hub until i downloaded what i want, and leave immediately, only then would i consider myself a leech in that hub.

A downside to your sollution: the hub im primarily on forces me to have max 10 slots, max 3 hubs and min 2slots/hub. im usually on three hubs and have 10 slots, but from the mentioned hub very few people are downloading from me, which would be slot wasted under the reserved slot way of working.

hardist
Posts: 49
Joined: 2003-02-06 23:26

OK

Post by hardist » 2003-04-01 05:00

Lets get to the jist of it, TOO many scripts have been written to handle the slot to hub ratio to even think it is NOT a problem .

If + is the cause of this problem ( and NO ONE can say its NOT a problem) why not ask them to fix it.
Sure my idea may not be the only one , but I dont see + doing ANYTHING about it either.

Why is it up to the hubs to write or use scripts to "handle" this.

Get real , get to the source , ++.

[KUN.NL]mepmuff
Posts: 73
Joined: 2003-01-06 09:32

Post by [KUN.NL]mepmuff » 2003-04-01 05:26

Ok,

Personally i think glueing slots to hubs will make things worse. Lets take a user who is on 6 hubs and has 12 slots. As it is now, those 12 slots are (in principal) available to all users on all hubs. By coincidence, all slots might be appointed to users from on or a few hubs. (Do you agree that would be due to coincedence?)

Now let's take 6 of those slots to assign to the hubs, leaving 6 free for all. Here a new problem arrises. One of the 6 assigned slots get hogged by a user (who ofcourse is only doing you a favour by backing up your hd). Now the other users from that hub have to wait for one of the six floating slots (which are more likely to be taken), even though one of the other assigned slots might be free.

I'm not denying there's some problem, but i think your sollution is in the wrong direction.

I think this problem can best be solved by some sort of upload-queue (there is a discussion about possible implementations for that somewhere). This would guarantee that each user from every hub your in can realisticly get a slot (as opposed to getting queued).

Marvin
Posts: 147
Joined: 2003-03-06 06:56
Location: France
Contact:

Re: OK

Post by Marvin » 2003-04-01 06:51

hardist wrote:Why is it up to the hubs to write or use scripts to "handle" this.
This question has been answered in this very thread by Sedulus 6 days ago : clients can be modified to cheat your rule, your hub can't.

hardist
Posts: 49
Joined: 2003-02-06 23:26

Marvin

Post by hardist » 2003-04-01 08:10

You can take about any sentence out of a post and use it for what ever you want , but in the context I used it in , it was to stress a point.

I know what he said , and boy wouldnt you all love a ++ buster hub. It seems that may be the only option , I wonder where ++ will be then , not in that hub that for sure.

KUN.NL ,

OK so if there is a problem and ++ is the cause , then why is it wrong to ask that they DO SOMTHING about it . Like I said I am not arrogant enough to think that my idea is the only one that will work i, if there are others post them there have been a couple posted already, and thats GOOD , and what this thread is realy about , and again I stress , why does ++ not even admit there IS a problem or do anything about it ?

My solution may very well be in the wrong direction , but the wrong direction is better to take than standing still , at least we're moving......

mo
Forum Moderator
Posts: 81
Joined: 2003-02-06 11:20
Location: Ohio
Contact:

Post by mo » 2003-04-01 08:47

Well, I'm all about improving dc++, and I'm always open to good ideas.
hardist wrote:why does ++ not even admit there IS a problem or do anything about it ?
I just think your idea to assign slots to hubs would hurt the community, not help.

As Twink stated, some hubs are for "decent conversation."
Also, some hubs have more users than others. Should I share 2 slots to 300 users and another 2 slots to 30 users?
I understand that the 30 users would have a harder time getting a slot compared to your request, but dc++ is more about the community.
If your concept was implemented in the above situation, 2 slots would likely be used constantly, the other 2 would likely go unused. This seems more like leeching to me than sharing 4 slots that both hubs have access to.

There is a thread open about modifying the functionality of the queue to create more of an IRC style queue, and if I'm not mistaken there is a modified client out there that actually uses it. This is an idea that tries to make things fairer, and I think ideas that truly improve the client are embraced by the developers and the community.

There is no valid reason for the developers to resist ideas that make the client better. Just because people do not seem to like your idea, doesn’t mean that they are no willing to change things for the better. It seems that you have confused the two.

hardist
Posts: 49
Joined: 2003-02-06 23:26

Kewl, ok lets assume my idea will not help....

Post by hardist » 2003-04-01 09:14

Then what are the alternatives, if my ideas are not feasable , then what else can be done.

I beleive that the limits that were once in place need to be re-established .

The ++ community will have NONE of that , so how is this slot to hub ratio fixed, ++ developers have taken no stand on the issue, it is left for we users to discuss. As I said , there are a few ideas on this thread , and you mention another thread going on , here is everyones chance to brainstorm , and post , who knows , some one out there may have the PERFECT solution......

hardist
Posts: 49
Joined: 2003-02-06 23:26

Side note

Post by hardist » 2003-04-01 09:19

Confusion is not part of this , the slot to hub ratio has been an issue since ++'s introduction , and has never been addressed in a constructive manor by the developers, they just passed the problem to the hub owners veiling it as a option that could be controlled by scripts.

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

Post by cologic » 2003-04-01 09:34

Well, that last post was fun, but slightly more productively I hope:
Get real , get to the source , ++.
The basic problem with the approach you're pushing is that is trusts the client. The client is in the hands of the enemy. The hub is not. The hub, therefore, should be the one trusted to enforce the rules that benefit it. You seem to acknowledge this in the next quotation of yours I use about '++ buster' hubs; anyone interested in cheating the system will use a client better suited to it anyway [such as one of the many alternative compiles of DC++ available], and your one slot/hub check would be removed anyway.

Hub rules should be taken care of by hubs. The client, to borrow a phrase of yours, doesn't know "what all the hub owners/ops want", so it shouldn't assume anything.
I know what he said , and boy wouldnt you all love a ++ buster hub. It seems that may be the only option , I wonder where ++ will be then , not in that hub that for sure.
Feel free to set up a DC++-free hub. No one's stopping you; on the other hand, you can't expect hundreds of existing hubs to become "++ buster" hubs just to suit your whimsy.
My solution may very well be in the wrong direction , but the wrong direction is better to take than standing still , at least we're moving.....
Moving the "wrong direction" is not better than standing still.

hardist
Posts: 49
Joined: 2003-02-06 23:26

Again you try to put this off

Post by hardist » 2003-04-01 09:51

This is not my personal pet project or whimsy, it is an issue that has been ignored for way too long.

Making a mistake and learning from it IS better than stagnation.

And again I did not coin that phrase in this thread, I just pointed out the reverse.

mo
Forum Moderator
Posts: 81
Joined: 2003-02-06 11:20
Location: Ohio
Contact:

Post by mo » 2003-04-01 10:01

hardist, I'm not as passionat about this issue as you are, but I admire your desire to come up with a better solution that the one we currently have.

I don't feel that there is a big problem, but as I said before if there is a better way to handle being in multiple hubs, I'm all ears, and other will be too.

hardist
Posts: 49
Joined: 2003-02-06 23:26

OK here we go

Post by hardist » 2003-04-01 10:14

How about this:

If you want to be in 200 hubs fine, go for it .

But if you want to download in ANY of them then you log in your slots , that would seperate the search and chat from the downloads, if you want to download then you are automaticaly bound to that hub and MUST share there.


Just an idea.....

[KUN.NL]mepmuff
Posts: 73
Joined: 2003-01-06 09:32

Post by [KUN.NL]mepmuff » 2003-04-01 10:25

The only upside of the proposed system i see so far is the fact that users from a small hub might have better access to slots when you also are connected to a large hub. The other problems are better arranged by the hubs imo.

I do believe that some sort of upload queue can be part of the sollution. One possibilty would be to implent some sort of weighted queue, where if there are 100 people queueing from a 300 user hub, 1 person from a 30 user hub can get some sort of priority. I know that from one point of view (or rather 100) this wouldn't be quite fair, but it would help small hub communities, and those 100 persons probably have better access to alternatives.

Locked