About downloads limit…

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

Moderator: Moderators

Locked

Should be added a new parameter in the DC description for downloads???

yes
17
55%
no
14
45%
 
Total votes: 31

[PT]Devilishly
Posts: 96
Joined: 2003-04-18 05:57
Location: Oporto, Portugal
Contact:

About downloads limit…

Post by [PT]Devilishly » 2003-04-18 06:18

Hello :)
Could it be possible adding in the DC “Description� information about the “Maximum simultaneous downloads (0 = infinite)�???
Why:
Because if it exists, Hubs could create a rule like a user could only have x slots open to downloads and y to up-loads.
If this were possible to be done, things like one user downloading from 30 users and other not downloading from no one, would be rarer. This would make DC better, I suppose…
How to do it:
I believe that this wouldn’t change a lot the actual dc, because this function already exists in it. All what I’m saying is to be sent with the string(<++ V:0.24;M:A,H:2/0/0,S:3> ).
For example being added a new parameter ‘D’ that would say 0(no limit), or the number of max dls. Hubs could choose if they want or not to use it… But I believe that it would make a lot of difference…

Best regards [PT]Devilishly

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

Post by [KUN.NL]mepmuff » 2003-04-18 07:35

I fail to see what the use of this info would be, as the number of download slots has no effect for other users. The only upside i see is that you can tell people who are complaining about the speed they are getting from you to f*** off.

[PT]Devilishly
Posts: 96
Joined: 2003-04-18 05:57
Location: Oporto, Portugal
Contact:

Post by [PT]Devilishly » 2003-04-18 08:03

I’m sorry if i didn’t make my self clear. When I say “Maximum simultaneous downloads (0 = infinite)�, this is an option with u can choose in the settings menu. With this option u can choose the maximum downloads, but it won’t say how many downloads your doing in a certain time…
Having this information would only say the maximum downloads possible, that doesn’t mean that you are using all of them…

Thank for your opinion [[]]

[PT]Devilishly

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

Post by [KUN.NL]mepmuff » 2003-04-18 08:07

i know that. so i still don't see any use. If someone is using loads of download slots, that only tells you that and nothing more. if he's using all of them he's not bothering anyone, he's only cramping the speed of his downloads overall.

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

Post by mo » 2003-04-18 08:37

also... the default is 0, and there is nothing wrong with it

[PT]Devilishly
Posts: 96
Joined: 2003-04-18 05:57
Location: Oporto, Portugal
Contact:

Post by [PT]Devilishly » 2003-04-18 12:20

The point of this implementation is to make things more linear. What I’m trying to say is that slots could be better distributed from the users that are in a HUB. Cramping your speed of downloads is just a consequence of doing to many downloads. But the problem is, if your are making too many downloads that means someone isn’t making any… So with this implementation, this could be controlled.
Of course hubs that wouldn’t want to use it or that think this would make any difference, could just ignore that parameter ‘D’…

Best regards

[PT]Devilishly

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

Post by [KUN.NL]mepmuff » 2003-04-18 12:42

I think this might be nice idea for NMDC-client-only hubs. When you're connected to multiple hubs, there is no way to do anything sensible with that info IMO.

[PT]Devilishly
Posts: 96
Joined: 2003-04-18 05:57
Location: Oporto, Portugal
Contact:

Post by [PT]Devilishly » 2003-04-19 06:16

Why not?! 8) But i also believe that it would be very useful for DC++ hubs.

Best regards,
[PT]Devilishly

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

Post by [KUN.NL]mepmuff » 2003-04-19 06:27

Well, if you want to balance the upload and download slots in your hub, and the users are in multiple hubs, you can't say anything sensible about the amount of slots used in your hub. The only thing you can do is make an assumption (like a user will have an equal amount of upload and download slots in use in every hub he is in), which will almost always be a wrong assumption.

The only way to make a fair count of the slots used within your hub, is to actually have some way of clients reporting the actual transfers to the hub. Using the description info would leave you with to many variables.

[PT]Devilishly
Posts: 96
Joined: 2003-04-18 05:57
Location: Oporto, Portugal
Contact:

Post by [PT]Devilishly » 2003-04-19 06:46

You are absolutely right about that!!! But implementing this would be a start. At least would prevent a user to have enormous quantities of slots, raising the probability of at least all users having one slot available to download…
Of course this wouldn’t be a precise measure, but has I said, it would be a start…
Tanks for your opinion [[]]

Best regards,
[PT]Devilishly

Wjierd
Posts: 29
Joined: 2003-04-15 10:47

Post by Wjierd » 2003-04-20 04:22

I think adding this extra description is a good idea and here is why:

Someone on a very fast connection can easily take many many slots, and then newcomers to the hub find it difficult to get slots due to the people who are downloading 50 files at once. There isn't anything inherently wrong with this fastest-connection-wins way of doing things, but giving OPs an option to run their hubs a different way is always good in my opinion. This could be a relatively reliable way to ensure that every user finds at least a few available slots at any given time. This is not only better for people who are on slower connections, but it is also relatively friendly to hub newcomers and ensures that they probably won't have to wait in the hub an extremely long time in order to get a slot. Again, giving OPs the option of making rules around Max DL slots will only add to the diversity and end-user options in DC++. I see this as good thing.

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

Post by GargoyleMT » 2003-04-20 07:46

You can already take a single slot from every user, even on a modem connection.

Listen, I'll share everything people might conceivably want, and sit in hubs and just upload to people, without having any downloads queued or transferring (thus my 3.5+ ratio), but if you make me report my number of download slots or currently running downloads, you'll quickly find me hacking that feature out of the client, or reporting a bogus number.

DC++ reports way more about its configuration than NMDC, probably in an attempt to prove to hub operators that it's a good (read: trustworthy) client. I think giving the hub additional information about my configuration than it already has is... bad. I don't trust hubs that much, even though I'm just on private hubs, and I don't feel like I need to be completely honest and open if I've done nothing wrong or suspicious.

If you've managed to annoy honest users/programmers like me, just think of what the forum(s?) of slot-locking hacked clients will do with this feature! (Aren't these the people who you want to protect yourself from?)

Wjierd
Posts: 29
Joined: 2003-04-15 10:47

Post by Wjierd » 2003-04-20 08:52

No reason to get annoyed, this is just a discussion after all. I don't think most hubs would make rules regarding # of download slots if a download slot reporting device were somehow implemented, but I'm sure a good number would. I don't know if I personally would hang out in hubs that implemented DL limitations, but having that option would improve certain users' experience IMO. Now, if there is a concern about privacy then that is certainly understandable, but reporting the number of DL slots you're using seems to me to mainly be keeping things on the level with where they are now... Upload slots are reported, why not download slots? As I explained before, I think there are several benefits to certain types of users if this feature were added.
As for taking a single slot from every user on a modem connection, yes, it is possible in theory, but I doubt many modem users ever split their 56k into 50 different DLs. If they tried, they would probably have to will their DLs to their descendants for when they were finally completed.
Now for the primary concern, it is true that any tags specifying number of DL slots would be a target for those who like to make slot-lockers and hacked clients. All I can say is that those who would abuse the system are either really good at what they're doing and relatively subtle, or they get caught and banned eventually so long as the OPs are responsible. There have been quite a few measures implemented against such people and activities and, for the most part, they've been effective enough to stop abuse from overly effecting the average user. I'm sure abuse of DL Slot rules in a hub that decided to create some would be reported eventually.
I think OPs should be free to make decisions regarding whether they'll set a DL slot limit or not. Users who like having no slot limit could just hang out in hubs without any. This, of course, is all just my opinion on the matter, but I genuinely believe that this feature could improve the experience of many users.

Wjierd
Posts: 29
Joined: 2003-04-15 10:47

Post by Wjierd » 2003-04-20 09:01

I was just thinking that a possible solution to this issue could be an option to turn DL slot reporting on/off. Then OPs could decide whether they would require DL slot-reporting and/or limiting for their particular hub, and no one would have to be reporting anything extra so long as they choose to only enter hubs without DL slot requirements.

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

Post by GargoyleMT » 2003-04-20 09:16

Ok, the mainstay of my post was this: I don't feel that it's any business of the hub how many download slots I have.

Since you don't get that or agree, how about a technical attack on implementation of your argument? Download slots, I would imagine, would be left as 0 by most people, so a reported value of 0 would be useless. Also, there's the "Maximum speed to start new downloads at", which doesn't translate to a number of download slots - and indeed can cause the number to be wildly inaccurate. And note that those are both slots, not the current number of downloads. (Which is comensurate with the reporting of upload slots, not actual number of uploads.)

Wjierd
Posts: 29
Joined: 2003-04-15 10:47

Post by Wjierd » 2003-04-20 09:31

The problem you suggest regarding most people reporting 0 DL slots would be a non-issue if an on/off function for DL-slots is implemented. If you're in a hub where DL-slot-reporting is required to be on, then chances are the hub would also have a DL-slot limitation requirement (say for the sake of argument that it was 6), which would mean that you would not have 0/infinite DL slots, but would have 6 in order to fulfill the hub requirement. If you're in a hub where no DL slot reporting is required, then you could just leave DL slot reporting turned off and wouldn't have to worry about it. I don't really see where your technical attack is going. The way I see it, this would just be one more option for the end-user to decide whether a hub with DL-slot-limitations or without them would best suit their needs/connection-speed & etc...

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

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

So you want the hub to turn on/off behavior in the client? You must be talking about scripting the kick, because DC++ has no facility for determining the capabilities of a given hub.

My point was merely that if you want DC++ to stick to a fixed number of download slots, you're going to have to remove an option from the client - specifically the "Max speed to start new downloads at." By "technical attack" I mean that sooner or later you're going to have to code this, if you want it in DC++. Some "features" require things that are technically impossible, or that require a significant change in the way DC++ works. I'm a programmer, this is often the weakest link in any feature.

Wjierd
Posts: 29
Joined: 2003-04-15 10:47

Post by Wjierd » 2003-04-20 10:33

I never suggested I wanted the hub to turn on/off the hypothetical DL-slot reporting feature. I was thinking this would work fine as something the user could do from the options menu on their end.
I didn't realize that you were specifically referencing programming in your previous technical attack, but if that's what you're getting at, then you're absolutely right. Someone will have to code this at some point if it's ever to be a feature in DC++. I'm not really worried about that at this point. I'm just trying to develop a good conversation to see whether it's worth coding in the first place or not. I think all potentially useful features deserve this attention.

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

Post by GargoyleMT » 2003-04-20 18:50

Wjierd wrote:I think all potentially useful features deserve this attention.
Agreed. (Though I'd strike "ly useful" from that statement.)

It can be taken too far, though I doubt that DC++ could ever become "design by committee."

Wjierd
Posts: 29
Joined: 2003-04-15 10:47

Post by Wjierd » 2003-04-20 19:22

The day some committee takes over DC++ design is the day it becomes a less useful project. But committees are usually only formed for things so ingrained in the system that they're basically universally accepted. So maybe this would be good in some way? j/k ^_^

[PT]Devilishly
Posts: 96
Joined: 2003-04-18 05:57
Location: Oporto, Portugal
Contact:

Post by [PT]Devilishly » 2003-04-21 06:10

First of all, I would like to thank you for your opinions.
I believe that it would be interesting giving an example so we could really see what would this implementation do to DC:

Let suppose we have two users, 'A' and 'B'.
I’m going to use a DC++ 0.24 as the used DC.
The descriptions that we have from them are:
A: <++ V:0.24,M:A,H:2/0/0,S:3>
B: <++ V:0.24,M:A,H:2/0/0,S:3>
To version DC++ 0.24 those are two users in the same level.

Assuming, that we have a new version DC++ x.xx let’s do the test again:
A: <++ V:x.xx,M:A,H:2/0/0,S:3,D:6>
B: <++ V:x.xx,M:A,H:2/0/0,S:3,D:0>
Now with this information, we can see that user ‘A’ have dl limit at 6. Being user ‘A’ in 2 hubs, 3 up-load slots and 6 dl slots it pretty fair I believe, and this information could be very useful for hubs that would want to use it.
About user ‘B’, we don’t have any information that regards to dl slots, so he has no limit, which is what normally happens.

Has you can see, this information would only be useful for hubs that would like to use it. Hubs that wouldn’t want/like to use it had the opportunity to ignore it. So, I really don’t see any harm on it, because you would just be giving useful information…

About being too many information added to dc description, maybe you’re right. But it could be reduced if the parameter H had only two sub parameters as H:’how many hubs you’re in without being OP’/’how many hubs you’re in being OP’; Well, but this is another matter, which has nothing to do with the topic…

Best regards,
[PT]Devilishly

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

Post by GargoyleMT » 2003-04-21 07:34

Has you can see, this information would only be useful for hubs that would like to use it. Hubs that wouldn’t want/like to use it had the opportunity to ignore it. So, I really don’t see any harm on it, because you would just be giving useful information…
The way I see it, it is causing harm, because it allows hubs to make rules and control the client in ways that it would have previously been unable to do.

Sorry, this is a more general expression of my belief that the rules of conduct on DC hubs, although generally just good/(comon sense) behavior, are just bandaids over other problems. (I think a ratings system, or something similar might be able to de-regulate hubs.)

I suppose another way of looking at it is that if certain hub operators need to be obsessive/compulsive about making rules and enforcing them (rules that go beyond the "norm" to just control the client), then that's not the kind of hub I want to be in anyhow.

[PT]Devilishly
Posts: 96
Joined: 2003-04-18 05:57
Location: Oporto, Portugal
Contact:

Post by [PT]Devilishly » 2003-04-21 08:24

I’m sorry, but this is a matter that should interest not only hubs but also users.
This wasn’t just an opportunity to make new rules for hubs, but this was an opportunity to make dc better!!! I’m not against doing 20 or 30 dls, I had done it myself, but I just don’t feel that it’s fair to others… We must understand that the most important information in DC is dls. That’s why exists up-load slots, so we could do dls, but if there are 8 or 9 users making 20 or 30 dls each, slots would be drastically reduced.
With this new parameter things could be controlled and this isn’t a matter of being obsessive or not, is just a matter of trying balance things…

Best regards
[PT]Devilishly

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

Post by Marvin » 2003-04-21 08:37

As GargoyleMT wrote, rating systems should handle this properly (and much more).

Your solution is too partial IMO, as it deals with maximum, not actual statistics.

volkris
Posts: 121
Joined: 2003-02-02 18:07
Contact:

Post by volkris » 2003-04-21 08:56

[PT]Devilishly wrote: Now with this information, we can see that user ‘A’ have dl limit at 6.
No, with that information you can see very clearly and confidently that user A is reporting a dl limit of 6. Other than that you're just running on conjecture.

This is the fundamental problem with tags. They don't mean anything except that there is a tag. If you're lucky the tag will happen to represent what the user is actually doing, but there's no reason to bet your hub on it. To say it with a little more verbosity, there's no reason to bet that this guy who has almost certainly come to your hub with the intention of taking would report the truth when it would interfere with is taking.

Tags were, IMO, implemented to shut hub ops up, not to solve any real problem. It worked well enough at shutting them up, which is indicative of the normal intelligence level of these ops and owners, but to look to tags for solutions in any other contexts is foolish.

Clients can only be trusted not to lie when they would gain nothing from doing so but would gain from not. Even with the compromises mentioned towards the end of this thread clients will still gain from lieing.

[PT]Devilishly
Posts: 96
Joined: 2003-04-18 05:57
Location: Oporto, Portugal
Contact:

Post by [PT]Devilishly » 2003-04-21 10:52

Well, if what you’re saying is truth (which I don’t question), is their other way to send this information???(Reliable way)

Best regards
[PT]Devilishly

volkris
Posts: 121
Joined: 2003-02-02 18:07
Contact:

Post by volkris » 2003-04-21 16:44

[PT]Devilishly wrote:Well, if what you’re saying is truth (which I don’t question), is their other way to send this information???(Reliable way)

Best regards
[PT]Devilishly
No, there is no reliable way to get information on how many downloads a user is limiting himself to. Any trustworthy source of information would only lead to conjecture.

But that's ok. You don't really need to know this anyway, as it's pretty indirectly tied to actual performance and value to the hub.

A better idea would be to track how much each user uploads and reward them based on that. You can get this information from the receiver so it's fairly trustworthy, and it actually represents a quality that improves value to the hub.

I mean, here on my OC3 I could share a whole heck of a lot to other DC++ users... but why should I? All I need to do is throw enough data into a directory to meet the hub requirements and then occasionally throw out a file to a person or two. At the same time it's using my system resources to upload, so I'd want to avoid uploading as much as possible. On the other hand, if you rewarded me for uploading I actually would agree to trade in my resources for sending more people more files.

And if I was being honest with a download limit tag and wanted to share out of altruism, I'd cause a different problem as I wouldn't be able to reshare as many files as I would otherwise. You know, if I turned around and reshared everything I got and I didn't get as much I woldn't be sharing as much.

The point is that the download limit attribute isn't a terribly good indicator of DC++ performance. Sure it would work ok, but there are better attributes to follow. And in the end the difficulty of tracking such an attribute simply isn't worth it's less than stellar return on value.

Wjierd
Posts: 29
Joined: 2003-04-15 10:47

Post by Wjierd » 2003-04-22 00:50

I can see this argument isn't going anywhere fast on either end. I can also see there's a lot of concern about DL slot limitation indicators and how they would probably inhibit people with super-fast connections. I can't say that this wouldn't be the case, but I think my suggested option of being able to turn off the indicator would allow those hubs not wanting limitations to run just as they are now and wouldn't take anything away from people with fast connections. The suggestion that a tag indicator is unreliable I find somewhat suspect primarily for the following reason: not anywhere near a majority of DC++ users are using hacked clients. Those who are using the faker clients and/or modifying their tags are found and dealt with on a regular basis. The simple fact is, that so long as there are rules and a relatively reliable means of enforcing them in a given hub, then most hub-users tend to follow the rules.
The hypothetical issue of people on super-fast connections not being able to share as much because they can't download as much, and consequently somehow making things worse for everybody, I find relatively ridiculous. Sure, it might be a problem for you if you can't DL as much on your super-fast connection, but users who can't normally DL as much at one time because their connections aren't as fast or they can't stay in a hub as long will be able to DL more because they won't be punished as severely for being on a slower/less-reliable connection and thus everything will even itself out. And, since the problem of circumstances where one user takes up huge numbers of slots is pretty much nullified, then slot availability in general will tend to increase so long as the DL slot limitation rules are adjusted properly by the OPs (based on average hub population and upload slot rules), and this would allow more users to DL more. The UL/DL ratio as a whole could even become a rule in certain hubs and thus users wouldn't even have to be limited to a certain number of DL slots so long as they kept their ULs in the proper ratio.
Those who are still worried about not being able to get as much "stuff" with such features implemented should think about this: not every hub would want to implement DL slot limitation rules and those hubs that don't would cater even better to users on fast connections because users who want a slot in a short time-period and on slower connections would tend to be filtered out into the hubs with DL slot limitations. Remember, if you can turn the DL slot limitation indicator off, then everything would function just as it does currently in those hubs that choose to not implement DL limitation rules. I see this a good diversification of DC++ both for the reasons I've mentioned above and those in my previous commentary.

Wjierd
Posts: 29
Joined: 2003-04-15 10:47

Post by Wjierd » 2003-04-22 01:22

In many ways I believe this argument can be boiled down to the following analogy: Capitalism vs. Socialism
I like both ideas, and don't see why they can't co-exist peacefully.

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

Post by GargoyleMT » 2003-04-22 08:14

Lord Helmet (Spaceballs) wrote:Evil will always win because good is dumb.
Seriously. There is a privacy concern here. DC++ is way more open than NMDC, and already tells way more than NMDC does. I don't believe that adding even one more piece of information to that should happen without a really good reason.

Neither of you advocates address this issue. I vaguely sense a "If you have nothing to hide, you won't mind if we come in and browse around" avenue of thinking.

If you don't want to think of it that way, give me an example of a P2P application that reports the number of downloads of a user. Now, what sort of percentage report download slots?

Yeah. I thought so.

Wjierd
Posts: 29
Joined: 2003-04-15 10:47

Post by Wjierd » 2003-04-22 15:56

I very specifically addressed the privacy issue in one of my previous posts. To rehash what I said earlier, I believe that privacy concerns are real enough and should be paid attention to. However, in this instance I think the feature enabling users to turn the DL slot limitation indicator off sufficiently addresses concerns about privacy. To wit, in the hypothetical eventuality of a DL slot limitation indicator becoming a reality in DC++: if you are concerned about keeping DL slot info private, then just turn the indicator off and stick to hubs that don't have rules regarding DL slots.
To me a DL slot indicator is merely a means by which to offer more options for OPs to choose from in how they decide to run their hubs, and, from my point of view, it has nothing to do with any sort of snooping mentality as you seem to imply. I think all users have a right to keep their DL slot info private if they so desire, and if this were the case in this hypothetical scenario, then all they would have to do is leave the "show DL slot indicator" option turned off, and stick to hubs that decide not to require it.

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

Post by cologic » 2003-04-22 16:25

To me a DL slot indicator is merely a means by which to offer more options for OPs to choose from in how they decide to run their hubs
I don't want ops to have an expectation they can run their hubs in some manners.
I think all users have a right to keep their DL slot info private if they so desire, and if this were the case in this hypothetical scenario, then all they would have to do is leave the "show DL slot indicator" option turned off, and stick to hubs that decide not to require it.
All someone has to do to avoid revealing his social security number - its being too widely revealed does cause identity fraud, after all - is avoid business with those banks and employers that decide not to require it.

Wjierd
Posts: 29
Joined: 2003-04-15 10:47

Post by Wjierd » 2003-04-22 21:53

Are suggesting that all hubs would require DL slot limitation indicators to be turned on? I strongly disagree. I am certain that quite a few hubs would not require this.

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

Post by cologic » 2003-04-23 09:28

I'm claiming that ops on the DC network have shown a tendency to exert as much control as is practical. If DC++ were to allow them to expect users to display their download limit, many of them would apply similar reasoning as you that it's something else about which they can make a rule, so why not?

My analogy was a little strong, but it clearly communicated its point.

Wjierd
Posts: 29
Joined: 2003-04-15 10:47

Post by Wjierd » 2003-04-23 13:55

I am not sure you are following my reasoning in its entirety if you think that it solely consists of something along the lines of, 'it's something new about which we can make a rule so why not?' I would suggest you re-read my previous posts, specifically those referencing the advantages for hub newcomers and users not on super-fast connections in order to get a better handle on exactly what I believe the benefit for the DC++ community would be.

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

Post by cologic » 2003-04-24 21:29

the advantages for hub newcomers and users not on super-fast connections
Users on faster connections should be able to open more download connections - they can better handle the bandwidth it'd use.

Restricting the number of download slots a user has will result in suboptimal slot usage on the hub (optimal being every upload slot full) if downloading isn't spread across all users, so making new users feel more welcome here is traded off against usability in the long run, IMO a bad trade.

volkris
Posts: 121
Joined: 2003-02-02 18:07
Contact:

Post by volkris » 2003-04-24 22:17

Wjierd wrote:The suggestion that a tag indicator is unreliable I find somewhat suspect primarily for the following reason: not anywhere near a majority of DC++ users are using hacked clients.
100% of DC++ users are using hacked client. DC++ IS a hacked client.
The hypothetical issue of people on super-fast connections not being able to share as much because they can't download as much, and consequently somehow making things worse for everybody, I find relatively ridiculous. [...] and thus everything will even itself out.
Recheck your math. You're off by an order of magnitude.

But regardless of any of that, relying on tags, effectually relying on users to police themselves and punish themselves, is a poor solution. Even without the proposal of a better one, it's a fundamentally poor solution.

Wjierd
Posts: 29
Joined: 2003-04-15 10:47

Post by Wjierd » 2003-04-25 15:14

Cologic: You can think slot-usage on a DL-slot-limiting hub would be sub-optimal if you want to. I don't believe this would be the case at all, unless by sub-optimal you mean users on super-fast connections wouldn't get to take 30 slots and hinder slot-availability for users on connections that are not as fast or hub newcomers. Furthermore, I see no hindrances in long-term usability of such a system. Incidentally, since the entire feature would be optional, if you're on a fast connection and you don't want to stick by the rules of such a hub, be they a ratio of UL vs. DL slots or a specific DL slot number, then I'm sure you could find many hubs that decide not to implement such rules.

Volkris: You seriously think hubs revolve around users with the fastest connections? I don't find this to be the case at all. Far wider distribution of files will be attained if slot-availability is equally distributed. Let me restate once again that the system would be optional in any case. You would not be forced to go to a hub with such rules implemented if you didn't want to.

volkris
Posts: 121
Joined: 2003-02-02 18:07
Contact:

Post by volkris » 2003-04-25 21:49

Wjierd, I suggest you go learn a little about stochastic modeling before you speak any more on this subject.

Your last reply in particular shows a profound lack of understanding of systems theory. In other words, you don't know what you're talking about and you don't have enough of a foundation for it to even be explained to you.

Wjierd
Posts: 29
Joined: 2003-04-15 10:47

Post by Wjierd » 2003-04-26 14:32

So, all of the Stochastic Modeling research currently carried out supports you does it? Perhaps you need to do a little more research before you start throwing entire areas of science at people.
Furthermore, saying things such as, "you don't have enough of a foundation for it to even be explained to you," is pretty-much always a cop-out. If you cannot explain in any form what particular study or aspect of stochastic modeling as it relates to network traffic you are referencing, then you obviously have no business talking about it in the first place.

leadenboy
Posts: 15
Joined: 2003-04-22 05:51
Location: Paris, France

DON'T DO IT!!

Post by leadenboy » 2003-04-27 06:22

Wjierd wrote:The hypothetical issue of people on super-fast connections not being able to share as much because they can't download as much, and consequently somehow making things worse for everybody, I find relatively ridiculous. Sure, it might be a problem for you if you can't DL as much on your super-fast connection, but users who can't normally DL as much at one time because their connections aren't as fast or they can't stay in a hub as long will be able to DL more because they won't be punished as severely for being on a slower/less-reliable connection and thus everything will even itself out.
This is not obvious at all. It seems very plausible that if you limit the number of downloads people on very fast connections can have going at one time, this will ultimately lead to a slower spread of the things being shared. You argue that more downloads for slower users will compensate for less for faster ones. This is obviously false. Take away one fast download, add one slow download, you get a slower spread.

Of course this in itself doesn't resolve the issue of egalitarianism that's being raised here. What DOES resolve that issue is intelligent use of UL slot requirements. Everyone will benefit if those who are able to receive many files quickly at the same time are induced to share them quickly with many other people at the same time. Everyone will suffer if those fast downloaders are prevented from using their speed as a resource to make things more widely available.

Hub owners will probably not understand this, and they will limit numbers of downloads left and right. Sure, individuals will be able to choose to join hubs that don't limit download speed, but this won't change the fact that the spread through DC++ overall will be slowed down. WHY?!

(Of course, there are many factors determining the spread (eg people on fast connections may burn a higher proportion of mp3s they've downloaded to CD), but it seems to me unlikely that those factors will counterbalance this one.)

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

Post by Marvin » 2003-05-01 05:15

Once again, a rating system would <i>help</i> users to understand how sharing (uploading) is good to everyone. I see it as a wider solution than download limiting.

Locked