Search Bot Port

[mo]

aDe has talked about a udp port created specifically for search bots.

I think we all understand the benefits of this.

Here is a thought that would produce the same effect, but would not require a second port for the hub, and no additional protocol commands.

Normal Login Protocol
C>H: Connection
H>C: $Lock ...
C>H: $Key ...
C>H: $ValidateNick ...
C>H: $MyINFO ...
H>C: $HubName ...
H>C: $Hello ... (at this point $Hello is sent to all clients)

Search Bot Login
C>H: Connection
H>C: $Lock ...
C>H: $Key ...
C>H: $ValidateNick ...
H>C: $HubName ...
H>C: $Hello ... (at this point $Hello is not sent to other clients)

Knowing that the $MyINFO command is required to correctly join a hub.
If this command is not sent by the client, the hub assumes the client is a search bot.

When in this state...

• only $Search, $SR, $GetNickList, $NickList and $Quit are valid messages send back and forth.

• The hub would not send this client the following messages
  $To, $Hello (regarding other's entering the hub), $MyINFO, $Search, etc...

• The hub would not accept the following command from the client
  $To, $GetINFO, $ConnectToMe, etc...

• If $MyINFO is sent by the client then the hub assumes it is not a search bot and send a $Hello to the rest of the connected clients

I think this would definatly help reduce network traffic on hubs, and may help encorage hub owners to allow search bots.

Is this a good idea?
Is this possible?

Should I crawl back in my hole

[sandos]

Basically, until you send MyINFO, your considered a searchbot? Sounds sane.

[Sedulus]

actually.. I already have the above in dch++ combined with a snippet of Lua:

Code: Select all

function dchpp.clientLine( client, data )
    if string.lower( nick ) == "zsearch[moglo]" then
        local ret,c,ip = string.find( data, "^%$Search ([0-9.]+):" )
        if ret and ip == client:getIp() then
            dchpp.sendToAll( data )
        end
        client:disconnect()
        return dchpp.ACTION_DISCONNECTED
    end
end

dch++ never sends the Hello's since no myinfo has been sent,
but in the mean time, the search has been forwarded.

so, it all sounds quite sane :)

[mo]

I don't know how golsearch works, but MoS++ doesn't send the search commands until the $hello <nick> is recieved from the hub.

The $hello command does not need to be sent to the rest of the hub, but it does need to be sent to the search client.

[Sedulus]

well yeah, it does get sent to the client that logs on (I think even dc++ would choke on not getting a Hello)

[Moch]

*furrows brow* Couldn't this be an exploit waiting to happen? If a client supports this then someone would be able to come in, and sit, hidden... also, bypassing any share/slot requirements. Heck... with a decent HACK of DC++ you could que up hubs like a search bot do your search.. get your results, request downloads from people.. and not have to be in any hub.

I guess that exploitation could become less and less as more users use DC++ and have the option checked to disconnect uploads from users not in hub.....

The hidden problem seems like it could be an issue though, while I was programming my client I introduced a bug where it didn't send the | after myInfo (and nothing was sent afterwards) and I was in the hubs I joined for a long time not being detected. (of course I wouldn't of been able to do searches, but I am just saying this as in I effectivly was counted as not sending in $MyINFO)

So.. to fix that hubs have to become more strict on how soon the MyINFO needs to be sent.

Ahh well, just my thoughts on this
~Moch

[aDe]

Heck... with a decent HACK of DC++ you could que up hubs like a search bot do your search.. get your results, request downloads from people.. and not have to be in any hub.

You wouldn't be able to sit hidden downloading since $ConnectToMe etc won't be allowed.
With a decent 'hack' of dc++ you can do alot =)
I don't think this is going to raise any further issues, though. There's nothing limiting you from doing the same thing today...