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

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

Another variation of my idea

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

Keep the ++ slot theme as it is, with one exception, if you choose to download in any of the hubs you in, then 1 slot is bound to that hub for the duration of the download. That way if you are using the hubs resources (the users) you are also giving back, tit for tat.........

cybersurfe
Posts: 1
Joined: 2003-02-04 13:52

Post by cybersurfe » 2003-04-01 11:21

i think hardist is right
assign slots to hubs

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

Post by GargoyleMT » 2003-04-01 12:20

Nobody has suggested alternatives, Hardist? Did you read my previous post?
GargoyleMT wrote: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.
Oh, and in case you missed it, there's only one DC++ developer: arnetheduck. Pretty much everyone else here who has commented has contributed patches (including me) or has their own alternate client. You are getting DC++ developer opinions.

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

huh????

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

When did I say that , I think I mention the alternatives posted here in a few of my replys....

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

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

Post by GargoyleMT » 2003-04-01 12:34

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

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

Only 1 huh ?

Post by hardist » 2003-04-01 12:37

https://sourceforge.net/project/memberl ... p_id=40287


And I am sorry , I dont see your name listed there .

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

Post by mo » 2003-04-01 12:41


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

This is in the SAME reply...

Post by hardist » 2003-04-01 12:42

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



Gargoyle, whats up with you ...

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

LMAO

Post by hardist » 2003-04-01 12:45

So , you knew there was more than one ....


Why are you doing this to yourself ?

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

You know guys , this is getting silly

Post by hardist » 2003-04-01 12:50

I am not going to be pulled into this game of picking out every little phrase in a reply to respond to , just for your amusement .

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

Post by mo » 2003-04-01 12:59

GargoyleMT is right, there is only one real developer for DC++ ... arnetheduck, everyone else just submits code, bug fixes, and helps work out ideas and such.

When he said "You are getting DC++ developer opinions" he was referring to the people that arne considers "worthy of the developer status."

So you can rest assured that you’re getting notable responses.

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

No Doubt

Post by hardist » 2003-04-01 13:06

I can see that from the content.

Well at least some of them.

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

Re: This is in the SAME reply...

Post by GargoyleMT » 2003-04-01 20:25

I think that an upload queue that serves requests in the order that you joined the hubs, would be a very equitable solution.

You've indicated that the current solution, of hubs kicking users who violate their rules, isn't the best one for you. I can respect that. And I agree wholeheartedly with Mo's respect of your devotion to this feature.

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

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

Hardist: I would like to know what you think about an upload queue? I think (as stated) that would be good starting point when someone wants to work on making the slot over hub distribution more fair.

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

Post by cologic » 2003-04-02 08:22

What do you think of this solution?

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

Post by Sedulus » 2003-04-02 09:01

for now a queue would be much easier to realise. esp. considering that the ratings system is far from anything concrete.

a queue would be nice,
I would propose a queue for each hub,
but then you have the following issue:

q1: 20 users waiting
q2: 5 users waiting
and the last slot has gone to a user from q1.

the fair thing would be to give 80% of the slots to q1. as this is most likely the biggest hub. in this scenario, however. the second hub still hasn't got the full "extra" privileges (comparable to the dedicated slot hardist wants).

the other option would be to have a pointer that re-iterates over all queues, so the next slot would go to q2 (next q1, next q2). this would be easier to implement. but this would create an advantage for smaller hubs, and I really can't believe that hubowners would want a client that makes it better to be in a small hub.

(for clarity: having one queue for all hubs would be out of the question, since this would worsen hardist's problem. considering that the "problem" you're really having, is with someone with 20 full slots joining an nth hub where noone can get a slot because they're all full. see: mepmuff's "I am of the persuasion that the slot-hub distribution will level out over time")


(and hardist.. gargoyle is in the developers list you mentioned, except he uses his real name there =) )
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

Well I tried to reply

Post by hardist » 2003-04-02 19:42

But this damned thing lost my sign in , and made me relogin and in so doing lost my reply ( that is very annoying) , so I will remember that if I want to make a long winded reply next time I will have to do it in notepad then login and paste it , so I dont run out of time ( groan)

I dont have the energy right now to retype it.........

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

Post by GargoyleMT » 2003-04-02 19:52

:) understood, that's why I keep myself auto-logged in, at least at home.

Why not give us the short-short version, we can likely extrapolate your arguments anyhow?

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

lol

Post by hardist » 2003-04-02 20:44

Is that like decompiling and having leftovers ?

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

Re: lol

Post by GargoyleMT » 2003-04-03 08:23

hardist wrote:Is that like decompiling and having leftovers ?
I'm sorry, your comparison escapes me.

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

Positions

Post by hardist » 2003-04-05 09:32

First lets talk about DC as a whole , there are quite a few hubs and more poping up everyday, as a whole there is no way that 1 user can contribute to the "whole" of DC . This being said , we are taken to the core of what DC is .

The Hub.

The individual hub IS the core of what DC is , so when we think of the Hub to slot problem with ++, we need to keep that kind of prospective.

Queueing is just a mess, no matter how you do it .
Ratings can only be done by the hub itself to be valid and reliable.
Which would mean if you want a rating you need to spend slot time in that hub . No difference to locking the slot to hub if you ask me.
The need to rewrite the hub software or implement seperate ratings servers just seems like more to go wrong to me.

I still think the best all around solution is to allow the slot setup to stay as it is, with the one slot exception , if you choose to DL in a hub your in , you lock a slot to that hub .

The arguement has been made that this should be handled by the hub and not the client , because you cannot trust a client .
I think that needs to be cleared up , you cannot trust a ++ or ++ based client. The ++client itself caused this mistrust.

I dont hear of anyone saying you cant trust a NMDC client.

If you were to ask me straight up , why I even mention NMDC , I would say this .

NMDC is the Original, it is how it this supposed to work.

1 hub to 1 client ( as another pointed out in this thread)
That setup guarenteed that you had slots shared in ANY hub you were in .
What that person failed to mention is that while this 1 to 1 ratio is true, you could open multiple instances of the NMDC client, and be in more than 1 hub .

NMDC is a resource hog, and you do get to the point where you cannot push the number of NMDC clients any higher. This *limits the number of hubs you can be in . This may have been planed or it may have been a happy accident, but it is what made the original DC ( pre ++ ) such a great thing - it was honest.

When I talk about putting the *Limits back into DC , that is what I am refering to .

I beleive that ++, as it is, drains the Whole of DC because it removes the Hub as the focus of the interaction, now the focus is the client and the ability to be in multiple hubs , not by actualy sharing , but by giving the Hub the option to have a slot Queued , instead of the honest sharing.
Hubs are no longer the center , they are options , and are treated as such by ++.

What I am getting at is , you dont share in DC as a whole, you share in DC in individual hubs, and while ++ gives you the option to be in several hubs, it does not share in all of them. It is not an *honest client.

So how do you make a client that lets you be in several hubs *honest ?

You make it so that if the client wants to DL in a hub it also locks a slot to that hub .
By doing this you keep the multihub browsing , and you also become a valid sharing member in that hub if you choose to download. ( not a bad trade off if you ask me)
( I know there will be details about how long to lock the slot to the hub if the user stops DLing in it . But the durration of the DL is fair I would say.)

ALL of this discussion is in an effort to KEEP ++ in the DC community by having it conform to the original model somewhat.

All a ++ buster hub would do is splinter off the DC community even more than ++ has done already.

I could go into Queueing and ratings more if you like , but I realy dont see the need for that kind of change to the system.

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

Re: Positions

Post by GargoyleMT » 2003-04-05 10:06

hardist wrote:Queueing is just a mess, no matter how you do it .
Ratings can only be done by the hub itself to be valid and reliable.
Sorry, neither of these two statements are backed up by facts or the discussion behind the ratings server.
I think that needs to be cleared up , you cannot trust a ++ or ++ based client. The ++client itself caused this mistrust.

I dont hear of anyone saying you cant trust a NMDC client.
There are share fakers for the official NMDC client. You'll have to do your own research to back this up, I'm not linking it. You can't trust any client, and that includes NMDC. Haven't you learned anything from the cracking of software, or the success of Kazaa Lite! (where there's been tons of functionality added onto a program without access to the source)?

Please do not trot out NMDC and say that it's the way DC is supposed to work. There are plenty of examples in the design of the DC protocol and the behavior of the NMDC client that show lack of programming skill on behalf of John Hess. He may have intended NMDC to be multi-hub or whatever, but lacked the skills to code it.

And before you jump on me and say that I've quoted you out of context, I haven't. Your arguments are based, at least partly, on the above statements, which I believe are false. Taking exception to them and ignoring the rest of what you say is perfectly justified.

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

Agreed

Post by hardist » 2003-04-05 10:25

Just as facts and discussion about a ratings server are also mute , because they are not in place to see how they actualy work.

Fake shares are controlled by OPs in the hub and are not the same as or in any way connected to slots .

Troting out NMDDC as a model is valid , it IS the model, no matter the coding skill or lack there of , by Hess.

Justification , is a purely personal experience.

Now, did you talk about the slots at all ?

If not , I will assume that you are not interested in the discussion , and are only interested in trying to bait me into somthing rude and base .

I was explaining MY positions , not telling you that they must be yours .

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

Post by cologic » 2003-04-05 11:00

hardist, you seem to have ... no, that would be an ad hom, and those are bad.
Fake shares are controlled by OPs in the hub and are not the same as or in any way connected to slots .
Incorrect. They're both controlled by clients, and hacking the number of slots isn't any more difficult (indeed, is likely less so) than [competent] sharefaking. That NMDC was hacked into sharefaking, and that there are not one, but two independent Kazaa modfications, indicates again that the client isn't to be trusted. Since you seem to feel strongly about enforcing at least a one hub/one slot ratio, this shows that you should not try to implement it in the client, where it can be trivially bypassed, but in the hub, where it cannot quite so trivially be bypassed.
Troting out NMDDC as a model is valid , it IS the model, no matter the coding skill or lack there of , by Hess.
NMDC sucks. Its being the first DC client doesn't make it a good model, as you apparently assume:
The individual hub IS the core of what DC is , so when we think of the Hub to slot problem with ++, we need to keep that kind of prospective.
I beleive that ++, as it is, drains the Whole of DC because it removes the Hub as the focus of the interaction, now the focus is the client and the ability to be in multiple hubs , not by actualy sharing , but by giving the Hub the option to have a slot Queued , instead of the honest sharing.
Hubs are no longer the center , they are options , and are treated as such by ++.
So you like the hub-centric model of DC, and NMDC promotes that. That doesn't make it the one right way to do it, and it doesn't make NMDC a good model of a DC client.
but it is what made the original DC ( pre ++ ) such a great thing - it was honest.
As Gargoyle points out, it was not honest. People hacked it to fake shares quite quickly.
I dont hear of anyone saying you cant trust a NMDC client.
Many posters in this very thread have stated that (e.g. Sedulus, Gargoyle, and I): by stating that no client can be trusted, we all included NMDC.
Justification , is a purely personal experience.
Huh? I have no idea what this means. If I take it literally, it's simply wrong: one can justify something with reason, and math relies on people choosing a few axioms and justifying everything rigorously based on them. So that statement is utter bullshit.
If not , I will assume that you are not interested in the discussion , and are only interested in trying to bait me into somthing rude and base .
Not speaking for Gargoyle here, you can feel free to assume that, but he was commenting quite legitimately on your lack of a solid foundation for your claim.
I was explaining MY positions , not telling you that they must be yours .
If this is your response to criticism of your idea, you should have kept it private to begin with. This is discussion board; would you preferred to be ignored entirely?

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

Re: Agreed

Post by Sedulus » 2003-04-05 11:05

hardist wrote:Just as facts and discussion about a ratings server are also mute , because they are not in place to see how they actualy work.
it's true that there is not a well formed plan yet. but that they are not in place is irrelevant. dedicated slots (it has been discussed _way_ long ago) are not in place either.
hardist wrote:Fake shares are controlled by OPs in the hub and are not the same as or in any way connected to slots .
two words: slot locking
hardist wrote:Troting out NMDDC as a model is valid , it IS the model, no matter the coding skill or lack there of , by Hess.
I beg to differ. it _was_ the model. nmdc(h) is of no influence on the current development of the DC network anymore (except from the fact that coders still try to make their software fully nmdc(h) compatible (which would be a different discussion)). perhaps Hess intended it to work the way it did, at least you feel that _that_ is the way. others however think the network should "go with the flow" and evolve. you say that dc++ ruins the community feel? I do not think so. I can be in 4 communities at the same time now, and _I_ think that is an advantage.
I'll be uploading at 700kB no matter how many hubs I'm in. so there is no disadvantage for the community as a whole. if I were allowed to be in one hub only, perhaps the people would be tired of my files after a while and stop downloading. that would certainly not be good for the community.
hardist wrote:Justification , is a purely personal experience.
que?
hardist wrote:Now, did you talk about the slots at all ?
you have not said anything new. so any new reply would/could have been posted earlier already.
hardist wrote:If not , I will assume that you are not interested in the discussion , and are only interested in trying to bait me into somthing rude and base
I was explaining MY positions , not telling you that they must be yours ..
being rude is a choice on your part. no one is asking you to start yelling. and the discussion is getting tiresome, yes. you still haven't convinced anyone to code this "feature" for you. nor did you put forward any new arguments. so.. unless you or someone else starts coding - or you become very convincing suddenly (unlikely) - I'll consider this thread dead.
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

So be it

Post by hardist » 2003-04-05 11:13

It's dead.

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

Now for the rest of you

Post by hardist » 2003-04-05 11:57

We were talking about slots here , not fake shares , so when I say honest , I mean in regards to slots.
Sorry I dont accept your fake share arguements, since I was refering to SLOTS.

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

re read

Post by hardist » 2003-04-05 12:14

It may help some of you to re-read that post that just got blasted , and mentaly put the phrase -with regard to slots.
After each line.

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

Post by Marvin » 2003-04-05 14:45

Haven't you ever heard of slot blocking NMDC clients (you are in one hub with 0 slots).

ps : sorry, I can't let this thread die, as it's my (second) favorite. :wink:

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

Post by cologic » 2003-04-05 15:31

I've enjoyed this thread too... And what makes you think if NMDC is vulnerable to fakeshare hacks, it's somehow immune from slot hacks? Given that your ideal model of DC is ludicrously based on people acting against their own self-interest, those who have the technical means to break out of the restrictions would certainly have much to gain; as a result, both sorts of hacks are available for NMDC. It is not an honest client, even "with regard to slots".

If you're going to concede, I don't want any half-ass concession. :P

yilard
Posts: 66
Joined: 2003-01-11 06:04
Location: Slovakia

Post by yilard » 2003-04-05 18:57

I can make slot locker for NMDC and any closed source client in 30 minutes. Don't think that obscurity ensures security.
In the age of super-boredom/hype and mediocrity/celebrate relentlessness/menace to society --KMFDM

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

I was not quitting

Post by hardist » 2003-04-06 02:08

Sedulus said HE considers this thread dead , the so be it was for him.

Granted , you could make a fake slot hack , but we are talking majority here , not programers, most could not.

I do not claim NMDC is immune to anything , its not , your right .
But the slot setup is what I DO like about it .
I said you dont hear about NMDC getting hacked , because ++ is the hackers prefered choice.

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

Re: I was not quitting

Post by [KUN.NL]mepmuff » 2003-04-06 02:49

hardist wrote: ++ is the hackers prefered choice.
I don't think thats a point for NMDC. It's just a drawback of opensource.

Everything you code can and will be used against you

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

Re: I was not quitting

Post by GargoyleMT » 2003-04-06 08:56

hardist wrote:Granted , you could make a fake slot hack , but we are talking majority here , not programers, most could not.
The original point was that you cannot trust the client. That includes NMDC, DC++, and the other DC clients out there. All it takes is one programmer to give a client with [insert leech feature here] to his leech buddies, and suddenly it doesn't matter if most people aren't programmers.

I think it makes much more sense to implement some features in the hub, especially those that are supposed to make sure the client is "a good client."

Locking upload slots to download slots (just one upload slot regardless of how many downloads?) to a hub is a novel idea, it will not work all the time, because of the points that fusbar and others pointed out. And of course it's (potentially) worthless without your original suggestion of one upload slot per hub, which was the original point of contention. (How do you lock 4 upload slots to 4 hubs if you only have 3 slots?) :-D The choice of how many slots a hub wants to require from users connecting to it should be left up to that hub. That conclusion is not the same one you reach, and I'm at a loss about what could possibly convince you.

Go to the DC++ homepage and read the text in the graphic: "Announcing: the freedom to share. {your files. your way. no limits}"

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

Perhaps your right , pershaps its somthing else

Post by hardist » 2003-04-07 04:09

But either way its a problem .
I hope no one will argue that at least.

I have always thought that the solution in in the hub software , but I didnt want to push that idea because it is anti ++.

The true purpose of this was to see if ++ programers would accept any responsibility for what their program does , or put it off on other people to handle .

I am sure people can see what has happened .

I would love programers here to actualy take the slot problem seriously,and do something /anything to fix it even if it isn't my idea , but from everything said , it seems that you are saying that even though the problem was created by ++ , the problem should be handled by someone else willing to write new hub software .
Which is the easiest thing for you to do , that way you dont have to DO anything.
If we look at this thread , about the only thing that's agreed on is that there IS a problem.

So if my ideas are not good enough , and yours are not good enough , and theirs are not good enough, what then ?

Does that mean ++ will do nothing ?

Does that mean we add to the system, to support ratings servers or implement a queueing system?

I dont know , I found no answers here . ( remember this was posed as a question ).

But it seems from what I got from this thread, that these programers do not plan, or see the need, to do anything about it .

I hope I am wrong !

wickedsun
Posts: 11
Joined: 2003-02-27 13:52

Post by wickedsun » 2003-04-07 04:39

To me, it seems that you are not looking at the DC comunity as a whole. Whats the difference if you are connected to 10 hubs with 100 each, or one with 1000? None. The whole (1000) pack of user has the exact same shot at your upload slots.

If someone has 6 slots open for 2 hubs, it doesnt matter how many users are from what hub. The guy is sharing to the comunity as a whole. People dont leech from the hub, they leech from each others. Hubs are merely a point of rendez-vous.

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

Post by mo » 2003-04-07 08:03

I agree with wickedsun, dc++ was designed for the whole community. The best solution does not focus totally on the hub or the user. I think the design of dc++ keeps the best interest of both the end user and the hub owners in mind, or at least the best mix of the two. There may be a couple things that will improve it's implementation, but it's on course in my head.

To say the the developers should take some sort of action to bend the favor totally to the hub owners would do a disservice to the community as a whole, and I hope that it does not take this action.

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

Post by cologic » 2003-04-07 12:08

But either way its a problem .
I hope no one will argue that at least.
I'll argue against that. As long as people upload reasonably, I would claim the individual hubs are fairly unimportant (and dispute what you said in a previous post about looking at this through the point of view of a hub).
I have always thought that the solution in in the hub software , but I didnt want to push that idea because it is anti ++.
No, it's not.
The true purpose of this was to see if ++ programers would accept any responsibility for what their program does , or put it off on other people to handle .
Sure, this program (I make one variation of it) participates in the DC filesharing network. It uploads and downloads files to and from other DC network users.
I would love programers here to actualy take the slot problem seriously,and do something /anything to fix it even if it isn't my idea , but from everything said , it seems that you are saying that even though the problem was created by ++ , the problem should be handled by someone else willing to write new hub software .
Which is the easiest thing for you to do , that way you dont have to DO anything.
If we look at this thread , about the only thing that's agreed on is that there IS a problem.
Oh no! Disagreement? Nah, people wouldn't actually dispute the great words of hardist, would they? Uncivilized, unwashed heathens.

Yes, any perceived problem should be handled by the trusted hub, for reasons entirely unrelated to your claims of laziness, or a desire not "to DO anything" on the part of DC++ and DC++ mod programmers. The client can't be trusted, and open source or closed, as Gargoyle and yilard pointed out, it will be hacked quickly. Thus, you must enforce rules in the hub.
So if my ideas are not good enough , and yours are not good enough , and theirs are not good enough, what then ?

Does that mean ++ will do nothing ?
You've given no compelling reason to make DC++ behave the way you want. If you have another idea, feel free to suggest it. Do not, however, come in and whine "okay, so my ideas suck. You think of something. Or else I'll just keep whining." That's accomplishes nothing positive.
But it seems from what I got from this thread, that these programers do not plan, or see the need, to do anything about it .
Just because you think something doesn't mean (1) I think it, (2) Arnetheduck thinks it, or (3) it's right.

no_dammagE
Posts: 5
Joined: 2003-02-18 03:55
Contact:

Post by no_dammagE » 2003-04-08 09:58

(i didnt read the second page, sorry, if i will write something what has been already written) the first ++ cure would be if ++ would close connections to hubs if they are inactive for 1 hour.
Definition of inactive:
* no searches
* no downloads
* no uploads
* no replys to the chat.

Effect: a user doesnt sit for hours on 20 hubs - he find something and stays on the hubs. He either makes something different or leaves his PC.
After lets say an hour all inactive connections will be closed. The user stays only on hubs where he is chatting, searching, downloading and uploading. After an hour his upload slots should be also be used up and so he is SHARING only on several hubs and doesnt report 0/x slots to every hub.
That also reduces the global traffic for the hubs (chat, glosearches in passive mode) and the user stays really only in needed hubs.
For the end user this is really not a problem (as long as he is not an OP, but then you might enter hubs which shouldnt be closed automatically) because he really doesnt need the hubs.
The most users have up to 7 active downloads (plus 3-5 uploads), so it makes 12 hubs.
It doesnt make any limits, the user just has to be active in ALL hubs.

sarf
Posts: 382
Joined: 2003-01-24 05:43
Location: Sweden
Contact:

Re: I was not quitting

Post by sarf » 2003-04-08 10:58

hardist wrote:[snippity]Granted , you could make a fake slot hack , but we are talking majority here , not programers, most could not.
This is simply not true. Many non-programmers know how to edit stats in games using trainers. Now, making a trainer is not as easy - but there is no need to do so as the trainers are already "out there" - both for NM DC and DC++. I would consider most slot-lockers "out there" to be on the level of trainers with regards to complexity.

You are correct in that DC++ is not hub-centric - it is, indeed, user-centric (or client-centric). This is, in your opinion, a Bad Thing (tm). So be it. In my opinion it is a Good Thing (tm).

What we have here is a simple difference of opinion.

You consider enforcing a certain set of rules to be the responsibility of the client. I consider it to be the responsibility of the hub. I must also add that there is at least one feature arnetheduck added to DC++ which is hub-centric, the "disconnect people who leave the hub"-feature, so arnetheduck might be receptive to your ideas - though I suspect they would have to packaged more attractively, either using numbers to show the benefits of your ideas, or by providing code that performs the tasks you wish.

As regards to your post, no_dammagE, it is fatally flawed in that it trusts the client to do things that the user of the client does not gain any benefits from. Thus, people would use a modified version that did not require them to be chatting, searching, uploading or downloading from a hub when they would rather be doing other things, such as sleeping, playing games, fiddling with their thumbs or creating the cure of AIDS.

I, for one, would be very quick to release a patched version of DC++ which does not have this limitation, as I myself often find myself in hubs where the client that you propose would kick me from (due to the fact that there are very few users on that hub).

Oh well. Hope you understand that this is not a personal criticism or anything.

Sarf
---
Every absurdity has a champion to defend it.

no_dammagE
Posts: 5
Joined: 2003-02-18 03:55
Contact:

Post by no_dammagE » 2003-04-08 16:04

patches ...
there will be always patches etc., but they aren't used by most of the users.
Only several users get ++!b**e
and an emule mod without part sharing is really unpopular.
also, many users might get the ed2k client-server client (patched ed2k)

if we make now 1 hub-limit, the users will change to other clients (dcgui for linux, compilable for windows). Or: the use of the glosearch tools will be much higher, the users will hop through the hubs, that means that they will get a result per glosearch, hop to the hub, begin the transfer and leave the hub.

----

If you have favorite hubs where you just want to stay, there might be a function to ignore closing favorite hubs. Then, the problem should be solved.

If you want to win the fight, you have to add the 1-hub-limit globally. It can be made by hub-admins (globally), or by the clients(globally).
But you all know that this will never work.

So, we have to make compromisses.

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

Post by cologic » 2003-04-08 16:23

and an emule mod without part sharing is really unpopular.
also, many users might get the ed2k client-server client (patched ed2k)

if we make now 1 hub-limit, the users will change to other clients (dcgui for linux, compilable for windows). Or: the use of the glosearch tools will be much higher, the users will hop through the hubs, that means that they will get a result per glosearch, hop to the hub, begin the transfer and leave the hub.
I have literally no idea what you're on about there, or more precisely why, for example, a hypothetical, relatively featureless eMule client is of interest in this thread. Further, the one hub limit is the most blatant red herring I've seen in the last few months: no one in this thread, not even the hard-line hardist, has suggested it. It is, indeed, a stupid direction for DC++ to evolve into, but it's also utterly irrelevant.
If you want to win the fight, you have to add the 1-hub-limit globally. It can be made by hub-admins (globally), or by the clients(globally).
But you all know that this will never work.

So, we have to make compromisses.
What fight, and why do I want to win? Not this one-hub per client stuff, I hope, as that's silly and hasn't been brought up in this thread before.
If you have favorite hubs where you just want to stay, there might be a function to ignore closing favorite hubs. Then, the problem should be solved.
Hey, look, out of 12 sentences, one of them is actually to the point and on-topic. Dumb luck has to come through eventually.

No, even after the no-idling idea is restricted somewhat, it's still braindead. Your definition of inactive:
the first ++ cure would be if ++ would close connections to hubs if they are inactive for 1 hour.
Definition of inactive:
* no searches
* no downloads
* no uploads
* no replys to the chat.
(1) Searches in DC++ are currently across all connected hubs. If you want to change this, elaborate on how. Keep in mind though that currently, your first criterion doesn't distinguish between hubs.
(2) I thought the goal was to avoid leeches, in which case you'd prefer people not to download. I'm not sure of the intention of this rule.
(3) If no one on a hub wants your files, well, that's not your fault; you're making a good faith effort to contribute. Someone else's inaction shouldn't lead to your being kicked from hubs.
(4) I'm a regular on 3 chat-heavy hubs. Even in them, 90% of the people don't say more than a word in every few weeks. That has absolutely no bearing on their value to the hub, or the degree to which they're a leech.

Soap
Posts: 13
Joined: 2003-02-11 19:11

Post by Soap » 2003-04-08 16:36

In answer to the complaint that you can't trust the client, what if you could...

A consortium of dedicated DC++ fans create a robust verification system for hub owners to check the true nature of connecting DC++ clients.

This verification program will use a new, but to be published, extension to the DC protocol that uses a kerbos-style, public key encryption, challenge and response. The challenge and response will allow a hub to detect, and verify the version of client being used, and any different features this client has, such as how much of a bandwidth cap is being implemented, if any.

Hub owners would be able to create a specific list of clients they were willing to allow to connect to their hubs.

Q: What about my ability to take this beautiful open-source code and "roll my own" client?
A: It's still there, the community would just need to "elect" some trusted members to look over your mods to the code, and publish the "fingerprint" of the resulting binary. The great thing about this is that the hub owner STILL has the power to decide if (s)he likes the client or not!

This fingerprinting of clients could be used to add all sorts of mods to DC++, extensions to the protocol, and changes to the very nature of DC++ it's self, while still allowing hub owners to choose what they want their community to look like.


?Soap?

Move this suggestion if off topic.
Reality is what you can get away with.

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

Post by cologic » 2003-04-08 17:01

First read this thread for some background on this subject.

Now in response to your specific suggestion:
This verification program will use a new, but to be published, extension to the DC protocol that uses a kerbos-style, public key encryption, challenge and response.
I assume then, you'll take as acceptable fallout of this that neither current (official) versions of DC++ that don't support this extension, as well as any Neo-modus clients (especially the one for OS X, which is without viable competition at the moment), will cease to be allowed?
The challenge and response will allow a hub to detect, and verify the version of client being used, and any different features this client has, such as how much of a bandwidth cap is being implemented, if any.
What prevents a client from providing a misleading response?

No, making DC++ closed-source won't help. NMDC's lock/key mechanism was independently broken by several people, and it's closed-source. One can start, for example, by monitoring its connections with a packet sniffer such as ethereal or tcpdump; one can also use a debugger such as SoftICE to examine and set breakpoints in a running program.

Of course, any DC++ mods have to be GPL'd (or be put under a compatible license), so it's even easier than that: just open the DC++ source, copy the official challenge-response code, and make sure one's own mod's code produces the same results.

This adds, in short, absolutely no verifiable way to determine a client's identity.

yilard
Posts: 66
Joined: 2003-01-11 06:04
Location: Slovakia

Post by yilard » 2003-04-08 17:16

Soap wrote: A consortium of dedicated DC++ fans create a robust verification system for hub owners to check the true nature of connecting DC++ clients.
Just few words: This is not possible. :(
Please accept, that client can be never considered trusted and DC network should never be restricted to certain clients. The goal in the long run is to enforce such rules that make cheating and unwanted behavior pointless, that will hurt offender himself. This could never depend on client.
In the age of super-boredom/hype and mediocrity/celebrate relentlessness/menace to society --KMFDM

Soap
Posts: 13
Joined: 2003-02-11 19:11

To those who say it is "not possible"

Post by Soap » 2003-04-08 18:43

I read the forum you so kindly provided the link to, and while it is probably a more appropiate one for this discussion, it does nothing to counter my argument.

A: It is possible.
B: It doesn't need to make DC++ closed source.
C: DC++ being open source does not weaken this system in the least!

Here's how:
1.The hub machine established an encrypted connection with the "fingerprinting" program (on the client machine) first. (let's call it the FP program from now on)
2.Hub sends randomly generated data to the FP program.
3.FP program uses the hub's public key to make a hash of the DC client requesting connection AND the data sent to it by the hub.
4.FP sends this ID to the hub.
5.Hub now uses it's private key to decrypt the ID. It checks the data that it sent to make sure that the FP program is sending a legit package, and checks to see if the client hash matches the known ID of client that the HUB wishes to allow


Now on to your "questions" (statements).
I assume then, you'll take as acceptable fallout of this that neither current (official) versions of DC++ that don't support this extension, as well as any Neo-modus clients (especially the one for OS X, which is without viable competition at the moment), will cease to be allowed?
ANY client can be fingerprinted, and a hub can choose to allow ANY client under this system. No modification is needed to be made to the client, past, current, or future. This is a system that the hub owner can implement at his/her liking.
You could run this system on top of any past, present, or future hub software. It could run in the layer between the hub or client and the TCP/IP stack.
So, to answer your question directly: No I do not find the discarding of any client accecptable. But this system would not render any client worthless.


What prevents a client from providing a misleading response?
The randomly generated data packet that the hub side sends to the client side ensures that the client side computer just doesn't send a hash of a known good client.

Just few words: This is not possible.
My ass!
Encrypted binary checking is not a new idea.
Public key encryption is not a new idea.
Public key query/response methods of authentication is not a new idea.
You probably have all three systems running on your machine as we speak.


And again, this DOES NOT limit the DC network to certain clients. A hub owner is free to allow any client in he/she wants. All this does is provide a way to fingerprint a client.
If you choose to "roll your own" client from the open source, then you could provide a copy of the source to the community as a whole, or communialy trusted individuals. They could provide details to the lay hub owners about the mods, (if it is a cheat client or not) and publish the hash of your compiled source. Then a hub owner can make the decision on their own if they want the modified client or not. All a hub owner needs besides this FP software is hashes of the clients that they want to accecpt.

The FP program could even be open source. It wouldn't weaken the system at all.

Is PGP insecure by nature of it's source being open?


?Soap?
Reality is what you can get away with.

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

Post by GargoyleMT » 2003-04-08 19:43

How are you to ensure the integrity of the fingerprinting program? You could clone it (including the hub's public key) and make one that, instead of reading the currently running DC client, reads a known good one off of disk.

I'm not sure that Kerberos really is appropriate in this situation, from the FAQ from the newsgroup, it says
Kerberos makes no provisions for host security; it assumes that it is running on trusted hosts with an untrusted network. If your host security is compromised, then Kerberos is compromised as well.
Isn't this exactly what we have, an untrusted host?

Soap
Posts: 13
Joined: 2003-02-11 19:11

Post by Soap » 2003-04-08 19:58

GargoyleMT - You make a good point about Kerbos's assumption of a secure host.

OK, I'm now increasingly sure I'd have to concede the fingerprinting program to closed source. Not there yet, but leaning. (against my will :D ) (security through obscurity is not security)


The way I envisioned the FP program verifying that you don't point it to another, "good", binary, is that it would check the running process that requested the connection, on the client's machine. The FP program playing "man in the middle"

Kerberos was not ment to be a model for the FP program it's self, just the idea of public key query/response.

Let me sleep on it tonight, you raise a valid concern, but I am not throwing in the towel yet. :D
Reality is what you can get away with.

Soap
Posts: 13
Joined: 2003-02-11 19:11

One more thought...

Post by Soap » 2003-04-08 20:12

Isn't this exactly what we have, an untrusted host?
Exactly right.

What we need is a man in the middle, a trusted man in the middle. I still believe the idea of verifying a client is necessary for the long-term survival of DC, or any other P2P network. I also still believe that the fingerprinting method is secure and praticle...

If there is a "trusted" host.

Now, we don't have to trust the host machine, we only have to trust the host process. (The FP program.) Correct? Not trying to make it out to be easier than it is, just want to see if we make the assumption of a trustworthy FP program, are we doable?
I don't see why not...
please feel free to poke more holes,
no thanks to blanket dismissals.

?Soap?

PS, in response to cloning FP program and hub public key...the hub public key does not have to be static.
Reality is what you can get away with.

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

Post by cologic » 2003-04-08 20:15

3.FP program uses the hub's public key to make a hash of the DC client requesting connection AND the data sent to it by the hub.
Find a hash of a known good client and send it to the FP. The FP then handles everything else on its own, including generating the correct responses to the hub's random challenges. Alternatively, reverse engineer the FP, and rewrite it to not bother checking the identity of the local client at all, but simply to allow the user to pick a client to spoof (and use a hash accordingly).

Locked