stimbot kicking

[drCor]

I'm using stimbot 1.11

But it's not kicking users below the minimum share limit if they use DC++.
When using normal DC, it's working fine.

Any ideas in scripting?
I like DC++..........

TIA!!

[BSOD2600]

I posted the same question a few weeks ago: http://dcplusplus.sourceforge.net/forum ... .php?t=493

ender
It must be a bug in the NMDC hub - the same thing sometimes happens with my bot, with no good reason - or so I thought... NMDC hub seems to sometimes send wrong user reference to the DataArival hub, which causes the script to work on somebody else (I noticed this when the bot greeted me two times with a share size that wasn't remotely like mine)...

[drCor]

yes I saw this one
was hoping someone knows the answer, getting attention by reposting it.


tnx

[Masto]

Many script dont kick below share. Use Gadget MultiBot that is one of the only working script

[ButterflySoul]

If it's a problem of reference to the right user, and it's specific to the DataArival Sub, I'm not sure why it would work with NMDC users, yet not DC++ users. *ponders*

Eventhough it's very nicely commented, Stimbot isn't exactly an easy script. It uses a lot of custom subs and objects (like the JustConnected Sub and colRecentArrivals) which makes it quite hard to track down 100% of the code actually involved in a specific behavior like the one you described.
However, there is a part of the code that might be involved in this, since dc++ offers the opportunity to handle redirections differently from NMDC :


iMinSharedBytes is the minimum share, and it's loaded this way :

Code: Select all

iMinSharedBytes = CDbl(txtMinShare.Text)

The only place where iMinSharedBytes is matched against a user's share is in the following part of the code :

Code: Select all

      ' If there are not too many users, but the user who's trying to connect shares too little, PM him an explanation, and redirect him.
      If iTheirSharedBytes < iMinSharedBytes Then
        CommunicateMessage curUser, frmHub.txtName, sMsgShareRedirect
        frmHub.DoEventsForMe
        curUser.ForceMove frmHub.txtRedirect
        Exit Function
      End If

I would suggest replacing curUser.ForceMove frmHub.txtRedirect with a good ole curUser.Kick()
If I remember well (but I could be wrong there), ForceMove doesn't disconnect a user, but merely "suggests" to the client to follow the redirect (which NMDC does without hesitating).
According to the protocol description from Suxxx :

$ForceMove SERVER This message will sends by the server to a client, that he must connect to another hub.
Server dont kick the user, the client must disconnect!

Format: $ForceMove <ipaddress>

Your original post suggests that DC++ doesn't disconnect itself from a hub when it receives a $ForceMove. Depending on how you interpret the protocol description, this is either a bug from DC++ (which prevents StimBot from working), either an accurate implementation of the protocol by DC++ (which Stimorol overlooked when he wrote his script).

The protocol specification from David Marwood would suggest that it is DC++ not handling things properly, but again, this specific part of the protocol can be interpreted either way, and the fact that NMDC always follows a redirection really doesn't help figuring out what should happen in case a client doesn't automatically follow redirections :

An op may send a $OpForceMove to cause a client to move to a different server.

$OpForceMove $Who:<victimNick>$Where:<newIp>$Msg:<reasonMsg>
<victimNick> is the nick that will be asked to move.
<newHub> is the IP address (and optional colon-separated port) of another hub that the user should move to.
<reasonMsg> is the reason provided to <victimNick>.
On receiving this, the server must send to <victimNick>,

$ForceMove <newIp>
$To: <victimNick> From: <senderNick> $<<senderNick>> You are being re-directed to <newHub> because: <reasonMsg>
<senderNick> is the nick that sent the $OpForceMove.
In addition to displaying the message, <victimNick> must disconnect from the server and connect to <newIp>. The server should not disconnect the client. I'm not sure if the client should send $Quit or if it should simply close the socket.

This is the most likely reason for NMDC clients systematically getting caught, and DC++ clients systematically getting skipped. Furthermore, I'm not sure what would happen with a DC++ client that explicitely has its options set to not follow redirects automatically, but chances are you'll keep it in your hub. Also, as Dave mentions, JavaDC ignores the $OPForceMove/$ForceMove sequence alltogether, so wether this is or isn't what causes DC++ to stay in your hub when their share is under the minimum, I suggest you still add a kick anyway to handle the JavaDC clients.

If you don't want to kick users (i.e. temp-ban them), at least disconnect them, but be aware your script will probably have to process them again a minute later, if the client automatically attempts to reconnect. That would be : curUser.Disconnect

Also, nothing prevents you from combining both approaches : redirect them if their client supports it, then kick them if they are still around because the client didn't follow the redirect. In this case, you would end up with the following code :

Code: Select all

      ' If there are not too many users, but the user who's trying to connect shares too little, PM him an explanation, and redirect him.
      If iTheirSharedBytes < iMinSharedBytes Then
        CommunicateMessage curUser, frmHub.txtName, sMsgShareRedirect
        frmHub.DoEventsForMe
        curUser.ForceMove frmHub.txtRedirect
        curUser.Kick()
        Exit Function
      End If

Finally, note that all the above is my own guess at what is happening, according to your problem description and to the source of the Stimbot 1.11 script.
If adding this curUser.Kick() doesn't solve anything, it means I am wrong, and that DC++ and StimBot both do what they are supposed to, etc etc.

-----

Aside from the $ForceMove issue, the iTheirSharedBytes variable -which iMinSharedBytes is matched against- gets determined the following way in Stimbot :

Code: Select all

    ' Skip to the sixth occurrence of $ in the string - that's where the user's share size is held.
    sTemp = sCurData
    For x = 1 To 6
      sTemp = AfterFirst(sTemp, "$")
    Next
    iTheirSharedBytes = CDbl(BeforeFirst(sTemp, "$"))

You can replace that whole part of the code by :

Code: Select all

iTheirSharedBytes = curUser.iBytesShared

Maybe some names or descriptions in DC++ can force it to send an extra $, but NMDC and DC++ essentially send their MyInfo strings in the same format, and DC++ is very clean about it. Even if this doesn't fix anything, at least it will speed up the script.

-----

If you feel adventurous, you can apply the same optimisation to the way iTheirSharedBytes is calculated in the SendWelcomeMessage(ByVal curUser, ByVal sUserData) Sub. Since it's a sub called pretty often, you might get a bit more performance out of your hub

-----

Finally, if this doesn't solve it, your best bet is to contact Stimorol himself, in case it is indeed a behavior occuring each time (or almost each time), and not something rare and random that would be happening because of the DataArival problem Ender mentioned.

[ButterflySoul]

$ForceMove <newIp>
$To: <victimNick> From: <senderNick> $<<senderNick>> You are being re-directed to <newHub> because: <reasonMsg>
<senderNick> is the nick that sent the $OpForceMove.
In addition to displaying the message, <victimNick> must disconnect from the server

According to the order in which David quoted the 2 commands, it could also be that after receiving a $ForceMove command, clients expect a last PM before disconnecting from the server, since they are required to display it... in which case, by the book, DC++ might handle things properly by staying connected, since no PM is sent by StimBot.
That would mean that an alternative to kicking would be to send the PM and see what happens then =)

The best thing to do is to give an eye to the source of DC++ and see what happens exactly when it receives a $ForceMove. The only problem with this is that it requires some c++ knowledge, which is unfortunately not my case =/

[chrish4321]

Somehow, my copy of StimBot was disconnecting users below the allowed share, but not below the permitted slots; I'm not sure exactly what was going wrong, but I also stumbled across the "frmhub.ForceMove" issue with DC++. The above solution(s) to that problem seem very elegant.

However, my users were not even getting redirect requests with insufficent slots, so I rewrote a portion of the StimBot code to be more adaptable in reading the DC++ <++ tag. I used RegExps to pull out the relevant data. The replaced code follows.

You might want to add this to StimBot, or at least check to see if you have the same problem. Note that as this code follows a check for op-ness, ops will not be disconnected.

Code: Select all

' in the HandleDCPlusPlus Sub, right after the "if" check for <++ and >
' tags in the sDescription variable

' this original StimBot code has been disabled...:

    ' iHubs = CInt(BeforeFirst(AfterFirst(sDescription, "H:"), ",S")) '+ 1
    ' iSlots = CInt(AfterFirst(sDescription, "S:"))
 
' ...and replaced by all the following:

' Define patterns and variables to handle DC++ tag parts
  Dim slotsre, hubsre, numre
  Set slotsre = new RegExp
  Set hubsre = new RegExp
  Set numre = new RegExp
  slotsre.Pattern = "S:[0-9]+[^0-9]"
  hubsre.Pattern = "H:[0-9]+[^0-9]"
  numre.Pattern = "[0-9]+"

' read the info

    ' note I add one to the value in the "H:" field, as otherwise registered 
    ' users have 0 as their Hubs value, due to the DC++ method of 
    ' calculating the H: field, and thus StimBot's later iSlots < slots-per-hub * iHubs 
    ' check allows as few as 0 slots open!
    iHubs = CInt(numre.execute(hubsre.execute(sDescription)(0).Value)(0).Value) + 1
    iSlots = CInt(numre.execute(slotsre.execute(sDescription)(0).Value)(0).Value)

' Back to original StimBot code, possibly with Disconnects replacing ForceMoves
' ...

sorry if my style's off, I'm not a VB-ite

[Sedulus]

According to the order in which David quoted the 2 commands, it could also be that after receiving a $ForceMove command, clients expect a last PM before disconnecting from the server, since they are required to display it... in which case, by the book, DC++ might handle things properly by staying connected, since no PM is sent by StimBot.

this is not the case.
my redirectorhub works fine with dc++, and does not send a $To. (it never waits 8 seconds)