We have got to do something about people taking up multiple slots. I routinely have to close connections of people downloading two files at the same time. I even had somebody downloading three times. I got so sick of it I banned his IP on the firewall. One guy I'm fighting now is in two hubs but has two CIDs. Same nick, same ip, same client, how can the CID be different? I thought that was supposed to be a globally unique identifier. The way it is now people can monopolize ur client.

LA

Last edited by lordadmira on 2006-06-21 10:31, edited 1 time in total.

When I check my own CID in the userlist it's the same in all the hubs I'm in. Why is my CID the same and the other guy's is different. What reason is there to include a hub component in calculating the CID? Seems everything would be better if DC didn't do that.

So ur saying that the CID is something my client generates and not something the remote clients push out? That seems very flaky. It's just a glorified version of nick+hubname. If a hub changes its name, wham I lost all my sources from that hub. I don't see how this way is better than the old way. What did this "fix" that was so "wrong" with the old way? Atleast then it knew that two people on different hubs were the same. How precisely is the CID generated?

All users are identified by CID because that is how ADC does it. This is the reason for the change. I would assume the CID is created by Base32.encrypt(Tiger.hash(nickname + hubname)) == CID. Ugly indeed, but that's what we get for using NMDC.

ullner wrote:All users are identified by CID because that is how ADC does it.

This isn't ADC. There is only NMDC.

ullner wrote:Ugly indeed, but that's what we get for using NMDC.

That's a specious argument. There's nothing besides NMDC so u can't offload responsibility onto those who are using it. That's like deriding African villagers for eating bugs, but that's all there is! It's that or nothing. ADC is a draft and an alpha tree, not an alternative to NMDC. Products should strive to be as functional as possible and as user friendly as possible within the current environment. If the current environment is really so bad then development on it should be stopped. The current CID pragma hasn't improved the usability of the environment, it's decreased it. NMDC cannot be evolved into ADC.

So I'ld like to hear it from Arne, why was CID implemented now? What did it fix that was broken before? It seems to me that the current CID implementation is a major design flaw.

lordadmira wrote:Atleast then it knew that two people on different hubs were the same.

Nope. It chose the first occurance of that nick it found. Could be a totally different user. So you got 1 bug with it this way, beats the many it used to have, from being unable to identify users.
e.g. having to go through every hub a certain nick was in, granting slots to each one, until they actually got the slot, was very annoying.

lordadmira: You don't understand. The change was because DC++ (in ADC) must identify users by CID, which doesn't exist natively in the NMDC protocol. For a work around, DC++ will now create a CID for every user based on nick and hubname (this could potientially even make multi-share possible, though there might be still some problems I can imagine), all because the internal user identification scheme should use a common denominator.

As far as ADC not being complete... What information do you have to backup that "ADC isn't an alternative"? DC++ has plenty ADC support. (There are only few things it doesn't have, which is negligible in the bigger picture.) (And, FYI, ADCH++ might be released soon so everyone can try it out.)

Ur right, I don't have information and that's why I'm beating my head against the wall here. No one's provided a reason why DC can't figure out commonality of users between hubs. This problem of people taking multiple slots has annoyed me to the point of speaking out. No one has said "it's impossible because..." and I think it's quite possible. No one's even acknowledged the problem as a problem! Nor has anybody stated "we should do something about that".

What difference does it make anyway? You would (or I assume) use the bandwidth regardless who it is. So, what is the problem? That other users don't get a slot? So? I don't get the "omg he is downloading from me from three places". A better solution for your "problem" would be to allow people to download multiple items from you as long as there aren't anyone else waiting for a slot. That sound a lot better to me than restricting multiple downloads.

That's an even more complicated solution than what I proposed. But yes, these people are keeping out other users. I'll have no free slots and some prick dl'ing off me 2 or 3 times. Even if there are other free slots it still messes up the overall network. It increases the time needed to get a file. I've had my own client dl twice from one person. That slows down *my* file transfer. I want to get one file as fast as possible. The fact that the overall download time for all the files is similar is no consolation.

could IP be a better way to uniquely identify users in NMDC? of course, if there are 2 people with 2 computers behind the same router, there might be some problem, but i think "nick+IP" seems better than "nick+hub". i may be wrong

I suggested that a while back but it was poo pooed. Actually IP alone is the easiest way to fix this. Just disallow multiple connections from the same IP. People can have different nicks in different hubs. It's true that different people could share an IP but that is a really small number and the odds that two such people would want to download off u at the same time are vanishingly small.

lordadmira wrote:It's true that different people could share an IP but that is a really small number and the odds that two such people would want to download off u at the same time are vanishingly small.

You have researched this matter closely? Could we see some statistics? How would you deal with hubs with many University users for instance, who often share the same IP?

i'm ona university connection most of the time but we all have different IP's
that's the case here in holland.
all the universitys connections have huge ip pools.
complete 145.x.x.x ranges for instance
and that's only one of the ranges

You can send a message around the world in 1/7 of a second; yet it may take several years to move a simple idea through a 1/4 inch of human skull.

lordadmira wrote:It's true that different people could share an IP but that is a really small number and the odds that two such people would want to download off u at the same time are vanishingly small.

You have researched this matter closely? Could we see some statistics? How would you deal with hubs with many University users for instance, who often share the same IP?

if you don't use only IP but "nick+IP" to identify users, i don't think such a problem can happen. if it does, it will be if 2 users of the same campus go on 2 different hubs with the same nick, which is really really rare i think

Nick+IP is just as broken as just Nick, since having different nicks in each hubs you're in (which many do) would circumvent it. Just set your Slots to 1 and you won't have any problem with users downloading too much from you..

This can be sorted for downloads which start with getting a filelist. Since for a while now the filelist has contained the users CID. So suppose could use that to match users up, and replace the "made" cid (from hub and nick) with the actual cid.

ADC's CID was meant to end the guessing. DC++ had to guess on NMDC hubs, since user identification wasn't something that Jon had to consider much when designing the protocol.

DC++ could implement more elaborate user guessing, but it would fail in some circumstances. Share size, for instance, may not be current, given the treatment of $MyINFO (the hub doesn't always have the current size of the hash, and the hub doesn't always let clients know if it does). IPs could be shared by multiple users (the probability of this varies widely by what type of hubs you are on) [IP isn't broadcast in MyINFO, only in UserIP, which I thought was still not widely deployed by NMDC hubs - something about security issues for broadcasting user IPs. a discussion may be archived here]. Nick is, well, nick. As for Email, Description, or Connection Type, nobody has seriously considered these, since they're not used much and can be changed very easily.

Back in the days that I was admin of a small LAN only internal hub on a university network, I played with script design to identify and log users attempts at circumventing bans. This would involved tracking their IP, Nick and Sharesize, and time between connection attempts. I was using SDCH and i never quite got to coding a working beta. But this was on the hub side, not the client side. It was my ability to code it mself, it isn't here. The adminship code in what they will make the client better, and If there is multiple connections getting through, then yes, something should be done. But sheez, pick a good day to share your problem on here.

Qn: Getting someones filelist updates the icon from Green to Blue how? Similarly can this also update the CID in the filelist, in the local client at all? Surely this is easy and more useful than not in the future?

Now realise, getting the other guys list isn't going to stop his client trying, we're then putting into our client blocking/banning code... which isn't right. The hacked clients will implement this throughout the place, making them even more popular with the riff-raff users around.

Case Study: You're the "other" guy.
- Has their client just "searched for alternates" and picked up another connection. In this case this is a Bug Report.
- Are they using a Hack client of which the guys here have almost no control over. in this case, we're stuffed.

The Qn above may solve an inadvertant picking up the extra same-user slots but not in a hack client, code can be deleted in source and recompiled.

Soln?: If the local client detects a same IP, same username, same sharesize from a connection, can the connection be dropped and/or added to "Waiting Users" ... i assume this is not a queue as such, but just a sniffer of access attempts, not to go as far as ban a connection attempt, but simply to delay it till after the first one has finished, they shouldn't know the different, it'll be as though you're out of slots.

a remote close of a connection, by default, the next time you go to pickup that file again, does the local client get the filelist again. Or is the get file list before a file download only active for certain settings/file-dl-initiations... (i only download from a search window, i find browsing tiresome)

as it is now, whenever your client finds a hit on an search , it will start to download the users filelist,,, from all hubs at the same time.
annoying as hell.

reading this topic didnt exactly explain much either, except that it works this way because nmdc sucks.
well,, since nmdc is what all the available hubs use , I'd say its a bit premature to implement this "feature" yet.
and even if that adch hub something is released, i doubt everyone is suddenly going to migrate to it.

I think he was talking about the dl-list-to-get-cid thing. Not queue automatch.

I still say one connection per IP is the way to go here. Simple and can't be spoofed. For the people on IP sharing, tough. "Oh God no, I can't get my file RIGHT NOW!!" They'll get the file eventually. In exchange for a small incovenience to a tiny number of people a big annoying problem is solved. How is that wrong??

If u want to go with the "elegant" solution why not just implement a protocol extension to $getCID. Heck everything else is an extension, what's wrong with one more. As people upgrade everything will fall into place.

lordadmira wrote:In exchange for a small incovenience to a tiny number of people a big annoying problem is solved. How is that wrong??

You obviously haven't (a) been to any hubs where operators kick for lack of downloading file lists ("omg, I can't download the list, CHEATER!") and/or (b) don't know that there are VERY many people on the same IP.

lordadmira wrote:If u want to go with the "elegant" solution why not just implement a protocol extension to $getCID. Heck everything else is an extension, what's wrong with one more. As people upgrade everything will fall into place.

The problem is that people don't upgrade... And I'd say your suggestion is quite hack-ish and not very "elegant".

LordSqueak wrote:this CID stuff,, *sigh*
seems to me its not working as intended.

The CID was never intended to work on NMDC - it's a feature of the ADC protocol. DC++ has been rewritten for ADC, so it makes its own CIDs up for users on NMDC hubs based on their nick and the hub name (I hope I was careful enough to say "pseudo-CID" earlier).

lordadmira wrote:I still say one connection per IP is the way to go here. Simple and can't be spoofed.

That solution may work fine for you, but if we implemented it, it would result in confusion and support requests when it got triggered.

make it a setting in advanced which defaults to three or something like that?
or the amount of slots set for uploading, people can then change it when they are really sick of one user downloading theyre files all the time.

You can send a message around the world in 1/7 of a second; yet it may take several years to move a simple idea through a 1/4 inch of human skull.

Todi wrote:Nick+IP is just as broken as just Nick, since having different nicks in each hubs you're in (which many do) would circumvent it. Just set your Slots to 1 and you won't have any problem with users downloading too much from you..

And what about somthing like IP+computer name (usually desk) in the network ? I think on one university network behing a proxy each computer has a different name doesn't it ? But I don't know if DC++ can have access to that information

You seem to be a man with a eager mind and alot of energy. Why not spend that energy on making the patches you want (and suggest them) instead of writing whole essays on why the application isn't up to your standards?

"Nothing really happens fast. Everything happens at such a rate that by the time it happens, it all seems normal."