single client search

Technical discussion about the NMDC and <a href="http://dcpp.net/ADC.html">ADC</A> protocol. The NMDC protocol is documented in the <a href="http://dcpp.net/wiki/">Wiki</a>, so feel free to refer to it.

Moderator: Moderators

Locked
dieselmachine
Posts: 36
Joined: 2003-01-19 22:22
Location: Rochester, NY, USA
Contact:

single client search

Post by dieselmachine » 2003-06-09 08:48

Is there any way to send a search request to only a single user? like, i assume he has a connection with the hub, which is thus leaving a port on his computer open to listen to tranmissions from the hub. Can i send my own info into that port ($Search), or will it check and make sure the info is coming from the hub?

I want to do individual user checking on entry via the client, to test for both actual slot count, as well as whether or not it will respond to a 'blind' search request. Any ideas?

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

Post by sarf » 2003-06-09 09:31

Yes, you can do this - you merely need a special command on the hub that will send a string of characters to a certain user.

There is no way of doing this using the standard DC protocol AFAIK.

Also, if I were doing a slotlocker (actually, when I DID do a slotlocker) I simply reprogrammed DC++ to believe it had zero or one slot and report that it had X slots (I modified the UploadManager if I remember correctly). This way, both the number of slots reported to the hub, the number of slots reported in a search result and the number of slots actually used by the client were in harmony. Therefore your method will only work on the crude slotlockers floating around the net - not that I am saying that it's a bad thing, mind you, but you need to understand that it is not foolproof.

Sarf
---
A government which robs Peter to pay Paul can always count on the support of Paul.

dieselmachine
Posts: 36
Joined: 2003-01-19 22:22
Location: Rochester, NY, USA
Contact:

Post by dieselmachine » 2003-06-09 09:38

Actually, slotlocking wasnt the issue i was looking at. I've essentially given up on slotlocking as i've realized it's going to be a very tricky thing (impossible?) to actually recognize.

I was thinking of wiping out the stupid people who have mismatched slot amounts (real slots vs. the number in their dc tag). Right now my client will automatically kick people when it finds discrepencies, but that requires searching for a . globally, which wastes everyone's resources, and requires a manual scan (searching everytime someone enters the hub isnt viable, IMO).

If i could hit up just one person with a search, that would allow me to search everyone on entry and catch that group, however small, of morons who havent quite figured out teh intricacies of basic math. ;-]

If someone cheats, and they cheat well, stopping them is going to be impossible. I've already realized that. The fact is, though, that 99% of the cheaters are fucking morons, so if i can keep that 99% out of my hub, the 1% should have negligible impact. The hub I op in has already gotten infinitely better since i've been adding in basic checks on locks and pks, and your sharechecker is also doing wonders. So if 1% of the cheaters get away with it, I can live with that. They've earned it for being smart, i guess. they're still fuckers, but i'd rather clean out the other 99% than worry about the 1%.

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

Post by sarf » 2003-06-09 13:51

Ah. Good that you've realized this - it'll make your life a little bit less frustrating. :)

Anyhow, the only thing I can think of is having a "backdoor" in a script which would issue a search request to a certain client - this should work since it looks the same as any other search to the client in question.

The only thing I would like you to do would be to build in a possibility to change the search string. It's OK that the default is ".", but it should be possible to use another string - this way you both get an easy way to adapt your client for "special interest group"-hubs (read: mp3 hubs) as well as being forwards-compatible with DC++, which might get a "do not respond to searches with less than three characters" option, since searches such as these are only used by complete and utter morons and for detection purposes (note that if you have a user-configurable search string it would be hard to simply return fake search results when someone searches for "." and do search-locking otherwise, which is a very effective method for reducing upstream bandwidth usage when you combine it with slotlocking).

Sarf
---
You wouldn't be so smug if you really knew what was going on.

Locked