lock/pk retrieval

[dieselmachine]

Ive been struggling with this for a while now, and im having minimal success, so i'm here to ask for help. I'm trying to find a fast way to retrive a client's lock and pk as soon as possible, using only sent commands (not generating and requesting fake files like dc++k). The solution i came up with was pretty straight forward. My client would receive a $myinfo, thus alerting me that there was someone there to scan. in client.cpp:

} else if(cmd == "$MyINFO") {

[...]
u->setBytesShared(param.substr(i, j-i));

after this line, i added the following:

connectToMe(u);

now, according to my understanding of the code (which could be totally off base), this will result in my client sending a $ConnectToMe command to the server, which then gets relayed to the user in question, and my client then listens for incoming traffic.

on the other side of the situation, the server is then relaying the command, which is intercepted by the target in Client.cpp, with the line

} else if(cmd == "$ConnectToMe") {

which blah blah blahs until the target sends info and i get the lock.

Now, it works. partially. About halfway through the list after joining the hub, my client simply stops getting lock/pk information from the clients. It will get about half of it, then just stop. Checking the debug window shows a couple socketexception errors. Am i overloading the socket with too much traffic or something?

Second, although it currently works for half of the users, it takes a bit of time to do it. Is this a problem with having one socket taking all the incoming requests, or am i just doing this in an innefficient manner? I have a modified build of 181 dubbed 'client detection mod' (im certain a few people in here are familiar with it), which seems to grab nearly every pk in the hub on connection. At least the extended ones. Now, im wondering how it does this so fast. I know the program isnt open source, but im wondering if anyone has any theories as to how that was possible, and if they could share any ideas with me, because i'm having a difficult time with this.

Thanks in advance.

[sarf]

To avoid being "swamped" by connecting clients, I'd recommend you to create either a new thread or a function which is run once every minute which would scan (at most) one client every second. I'd also recommend you to download the filelist of the user, since that can be used later on for checking the share as well as giving you an easy way to patch in the checking of the user... this way, there's also the benefit of detecting slotstoppers and connection refusers + modified versions of DC++ (including older versions of DC++ which refused to upload filelists). Please note, however, that there are a limited number of "extra" upload slots - but if the client is logged on as an OP a reasonably recent DC++ client should send the filelist anyhow.

The main problem I think you get is that you get "swamped" with connection requests - but this is mere speculation.

By the way, the reason I used a "fake file request" was that DC++k was supposed to be used normally, too, so I couldn't fiddle too much with the already existing code.

Sarf
---
By God, for a moment there it all made sense...

[dieselmachine]

Ok, first off, thanks for the help. I appreciate it a lot. However... One client a second isnt something i want to do, as that would require not calling the check function from the $MyInfo command handler, which is how i want to do this. I'm pretty sure i could do it in a faster way (which was my initial question. I'm looking for speed here). So, in the pursuit of a faster way, I have more info regarding my observations.

Watching the debug window in vc98, when i log into a hub i see the following:

A shitload of connecttome requests, all in a row. after the connect to mes, i see a steady stream of 'onmynick's and then 'lock obtained' (i added this in when i successfully go a lock). this works well, and works fast, until a point. After getting a bunch of locks, i see "The thread 0x*** has exited with code 0 (0x0)" a bunch of times. like 50-60, all in a row. And after this happens, none of the $connecttomes that i've sent out BEFORE that point will receive responses. I'm sure the clients are sending them, but i'm not getting them for some reason. Like the socket stopped listening or something. However, clients that connect to the hub after this massive thread shutdown will still receive my connecttome request, and will still respond with the desired info.

Can anyone help me out here with the possible cause for (or better yet, the solution to) this problem? Until i started editing the dc++ source code, I had NO experience with threads, so drop me some hints if you can. Thanks!

I do appreciate the help Sarf, but I'm looking for another way. No disrespect intended with my request for further assistance.

[sarf]

Ok, first off, thanks for the help.

Not a problem - and don't feel bad about not following my advice - heck, even I don't follow my own advice all the time.

[snip]
Watching the debug window in vc98, when i log into a hub i see the following:
[snip]

Hmm... this might be due to the fact that some hubs have a small delay on when they start accepting data (or at least searches/connecttome requests). Perhaps this may be the cause of your problem... but as I re-read your post, I see that you did indeed get locks. Are you sure that those locks come from connections you have initiated?

It may also be due to the TCP/IP stack you are using (might have a low maximum number of connections value), or it might be due to your router/ISP/birth sign.

If you want some help with a threaded solution (preferably involving lots of CriticalSections, mutual exclusions and a list of clients as well as other mumbo-jumbo) put your code up somewhere and link to it from here.

Sarf
---
Never test for an error condition you don't know how to handle.