Author Topic: Download blocker problem  (Read 6805 times)

0 Members and 1 Guest are viewing this topic.

Offline Naithif

  • Triple Ace
  • **
  • Posts: 199
  • Karma: +32/-13
Download blocker problem
« on: 19 December, 2006, 13:38:13 »
Hi all

I've a problem with the simple download blocker part of my script

Code: [Select]
tCantDownload = { [0] = 0, [1] = 0, [2] = 0, [3] = 0, [-1] = 1 }
bCantDownloadInPm = true

function ConnectToMeArrival(User, Data)
if tCantDownload[User.iProfile] == 1 then
if bCantDownloadInPm == true then
User:SendPM(HubBot, sCantDownload)
else
User:SendData(HubBot, sCantDownload)
end
return 1
end
end


RevConnectToMeArrival = ConnectToMeArrival
SearchArrival = ConnectToMeArrival


The problem is that no passive registered users (profiles 0, 1, 2, 3) can download from an active user (profile -1)
I can't seem to understand this, searched for other scripts, but as I saw all in common with the way RevConnectToMeArrivals are handled.
Can somebody help me with this? Thanks in advance

PtokaX forum

Download blocker problem
« on: 19 December, 2006, 13:38:13 »

Offline Thor

  • Scripter
  • Lord
  • ******
  • Posts: 290
  • Karma: +45/-5
    • Hungarian Direct Connect Site
Re: Download blocker problem
« Reply #1 on: 19 December, 2006, 18:25:14 »
sCantDownload isn't declared, got nil, and script don't disard the data.
+
http://forum.ptokax.org/index.php?topic=6473#msg63640
« Last Edit: 19 December, 2006, 18:39:08 by Hungarista »

Offline Naithif

  • Triple Ace
  • **
  • Posts: 199
  • Karma: +32/-13
Re: Download blocker problem
« Reply #2 on: 19 December, 2006, 19:26:09 »
That string's declared in my script, I'm not soooo (Maybe.) stupid, just forgot to paste it here. (I've pasted the first two lines after the rest, and didn't noticed the message string)

Well, thanks for the link. - It's funny 'cause it wasn't long ago.
The only thing left to do then is to wish that maybe PPK implants it into PtokaX. ([beady little eyes] please? ::))

(Where's my head these days)

Offline bastya_elvtars

  • Forum God
  • ****
  • Posts: 3 744
  • Karma: +173/-7
  • The rock n' roll doctor
    • The FreshStuff3 Site
Re: Download blocker problem
« Reply #3 on: 19 December, 2006, 19:38:29 »
Naithif, your problem originates from the protocol specification. On a $RevConnectToMe the target client sends a $ConnectToMe to the source client because the peer-to-peer connection can only be established this way (one of the clients is passive). Therefore, you have to enter allowed passive users to a table on $RCTM and remove if the same user does the $CTM afterwards.
Everything could have been anything else and it would have just as much meaning.

Offline Naithif

  • Triple Ace
  • **
  • Posts: 199
  • Karma: +32/-13
Re: Download blocker problem
« Reply #4 on: 19 December, 2006, 20:50:08 »
Yip I've been thinking some about this in the past few days

It's because the passive user (non -1 profile) sends RevConnectToMe and the other replies with a ConnectToMe, with blocked profile (-1, user) that's easy to understand an it's clear

The sender of RevConnectToMe is always that client that's the downloader - good as blocked if profile matches
The sender of ConnectToMe can be either the downloader or the victim - It should be split into two cases?

--> Check ConnectToMe connections, if there was a RevConnectToMe before it?

If there was, don't block it (this case RevConnectToMe would have already been blocked if the profile would match, so if RevConnectToMe sent it, and got through, it's good (passive non user))
If there wasn't, block it after a profile check (active sender, if fails on profile check, should be blocked)

This would require a monitoring of connections
Like RevConnectToMe users (if they are through the profile check) would send any confirmation info (like a value set) with the other users name (it can be read through a string.find, right?) and upon ConnectToMeArrival only connections confirmed with this info should be allowed?

Dammit, it isn't as easy as it looks :D
My question: Can this be made, or is there some other errors in it? (I just need the answer)

Edit: [Offtopic] Nice petition Bastya, I like it, is there a topic about it, or something at this board? Maybe voting or stuff  :D
« Last Edit: 19 December, 2006, 20:57:09 by Naithif »

Offline bastya_elvtars

  • Forum God
  • ****
  • Posts: 3 744
  • Karma: +173/-7
  • The rock n' roll doctor
    • The FreshStuff3 Site
Re: Download blocker problem
« Reply #5 on: 19 December, 2006, 21:21:14 »
Well, you can do with a table with $RCTM username as key and target username as value. It needs a trick because of CTM, but I am sure you'll find the solution. ;-)

Edit: I don't know if you can do it with a coroutine, but maybe it's worth trying (yield until no match perhaps ).
Everything could have been anything else and it would have just as much meaning.

Offline Naithif

  • Triple Ace
  • **
  • Posts: 199
  • Karma: +32/-13
Re: Download blocker problem
« Reply #6 on: 19 December, 2006, 21:28:20 »
Not really these days I'm afraid, I've got loads of stuff to do (and more in january...).
Big thanks for the advice Bastya, I'll look into it sometime, maybe a crude version will come up soon or something

Edit:
Well, you can do with a table with $RCTM username as key and target username as value.

Do we need that target username into the table?
I mean RCTM sets the 'Confirmed' value to the User.sName ('User' is the triggerer) in the table (if passed of course)
And CTM checks for the 'Confirmed' value with the Connecter.sName ('Connecter' is the one who connects to the triggerer in this case) in the table
(it seems that the connecter to the triggerer ('Connecter') can be grabbed with string.find, just seen it with Mutor's script :) )
« Last Edit: 19 December, 2006, 21:56:32 by Naithif »

Offline Naithif

  • Triple Ace
  • **
  • Posts: 199
  • Karma: +32/-13
Re: Download blocker problem
« Reply #7 on: 21 December, 2006, 13:38:22 »
I dunno if it's right, but tested it with Passive and Active normal users, and regged Passives

Results for me: normal user blocked, passive regged NOT blocked  :D

Please test it who can, I'm not sure in it (I've tested it some, but I don't know)

Code: [Select]
HubBot = frmHub:GetHubBotName()
bSwitchOnCantDownload = true
tCantDownload = { [0] = 0, [1] = 0, [2] = 0, [3] = 0, [-1] = 1 }
bCantDownloadInPm = true
sCantDownload = "\r\n\r\nRegisztr?ci? n?lk?l nem t?lthetsz ?s kereshetsz ezen a hubon. Ha regisztr?lni szeretn?l, keress meg egy oper?tort ?s V?RJ T?RELMESEN.\r\nOhne Registrieren kannst du nicht in diesem Hub downloaden und suchen. Wenn du registriert sein willst, frag einen Operator und WARTE GEDULDIG.\r\nWithout registration, you are not allowed to download and search in this hub. If you want to register, ask an operator and WAIT PATIENTLY.\r\n"
tConfirmed = { }



function RevConnectToMeArrival(User, Data)
if bSwitchOnCantDownload == true then
if tCantDownload[User.iProfile] == 1 then
if bCantDownloadInPm == true then
User:SendPM(HubBot, sCantDownload)
else
User:SendData(HubBot, sCantDownload)
end
return 1
else
tConfirmed[User.sName] = "A"
end
end
end


function ConnectToMeArrival(User, Data)
if bSwitchOnCantDownload == true then
if tCantDownload[User.iProfile] == 1 then

    local s,e,CTM = string.find(Data,"$ConnectToMe%s+(%S+)")
    local s,e,RCTM = string.find(Data,"^$RevConnectToMe%s+%S+%s+(%S+)|$")

    if CTM ~= nil then Connecter = GetItemByName(CTM); end
    if RCTM ~= nil then Connecter = GetItemByName(RCTM); end



if tConfirmed[Connecter.sName] ~= "A" then
if bCantDownloadInPm == true then
User:SendPM(HubBot, sCantDownload)
else
User:SendData(HubBot, sCantDownload)
end
return 1
else
tConfirmed[Connecter.sName] = ""
end
end
end
end



function SearchArrival(User, Data)
if bSwitchOnCantDownload == true then
if tCantDownload[User.iProfile] == 1 then
if bCantDownloadInPm == true then
User:SendPM(HubBot, sCantDownload)
else
User:SendData(HubBot, sCantDownload)
end
return 1
end
end
end

(sorry for the big deal of crap in this (like bSwitchOnCantDownload = true , and using a table for profiles who can't download), it can be made more simple of course with just the profile (-1) inserted, it was neater for me in the main script (and toggling should be in it). I've just ripped it off quickly)

Credits goes to Mutor, bastya_elvtars, and everyone else who identifies his/her code in this
« Last Edit: 21 December, 2006, 13:53:13 by Naithif »

Offline Naithif

  • Triple Ace
  • **
  • Posts: 199
  • Karma: +32/-13
Re: Download blocker problem
« Reply #8 on: 23 December, 2006, 15:13:27 »
Nobody's testing or commenting ? :( If this one works / not works for anyone, or simply found something which isn't right, please give feedback... Sorry for double posting

Offline Naithif

  • Triple Ace
  • **
  • Posts: 199
  • Karma: +32/-13
Re: Download blocker problem
« Reply #9 on: 23 December, 2006, 19:55:26 »
I haven't tested the code, but I'm doubtful this would work.

Code: [Select]
local s,e,RCTM = string.find(Data,"^$RevConnectToMe%s+%S+%s+(%S+)|$")
should always be nil in:

Code: [Select]
function ConnectToMeArrival
It should only be available in:

Code: [Select]
function RevConnectToMeArrival

Yip, that's right

As was stated earlier, it would be best to build a atble from RCTM

Isn't the table is built by RCTM users in this script ???

Code: [Select]
function RevConnectToMeArrival(User, Data)
...
tConfirmed[User.sName] = "A"
...

and then if the RCTM user matches the CTM remote nick, allow xfer.

Code: [Select]
function ConnectToMeArrival(User, Data)
...
if tConfirmed[Connecter.sName] ~= "A" then
...

CTM remote is "Connecter"

Edit:
I've tested this script now, and it seems to work  ??? All reged could download, and unreged cannot BUT expect that:

It can't avoid the "established connection" problem, so if you're regged and start downloading from someone, they can start downloading from you too, which makes the whole script rather useless... (This problem is present in all of these scripts isn't it?) Seems like it's a lost case sorry for disturbing you with it
« Last Edit: 23 December, 2006, 20:06:57 by Naithif »

Offline Naithif

  • Triple Ace
  • **
  • Posts: 199
  • Karma: +32/-13
Re: Download blocker problem
« Reply #10 on: 23 December, 2006, 20:24:56 »
you not accounting for multiple RCTM's
from the same passive user. I was suggesting your RCTM table entries  should
have a value of the remote nick, not just "A".

I thought clearing it upon each successful connection should be able to handle it :(

Code: [Select]
else
tConfirmed[Connecter.sName] = ""

The main problem is the "established connection" problem I think :(
(After hiding share with clients, scripts and such, I can say that I don't agree with the "don't share / hide share" thing, just I hate leechers who enter the hub with minimal (and crappy) share and pulls down everything from all users - if you and other ops don't hide share it's easier to filter leechers)
(most leechers leave immediately if they can't download, and it's easier to get them back on 'wait' list by removing their reg if they act as a leecher eventually)

Offline Naithif

  • Triple Ace
  • **
  • Posts: 199
  • Karma: +32/-13
Re: Download blocker problem
« Reply #11 on: 23 December, 2006, 21:29:14 »
It should, unless perhaps the connection speeds of the respective users plays a role.
So I'm thinking it's best to use numerical indices [arrays] and looping the table [with ipairs]
rather than hashing [tables] for what might be a common alpha-num. indice This would also
allow for the use of table.insert and table.remove

Sounds reasonable but this script will eventually leak, I think the way of sorting the table and adding the connecter with indexes would fix 1:100th of the leaking errors.
I mean no disrespect, it should be better your way, but if there's a great hole in the ship I can't see the reason to fix the small one.
With unregs can download when a reg downloads from them (or even can start) this script has a great hole in it.

Offline Naithif

  • Triple Ace
  • **
  • Posts: 199
  • Karma: +32/-13
Re: Download blocker problem
« Reply #12 on: 24 December, 2006, 12:03:07 »
In any rate the protocol limitations on 'blocking' transfers will exist
until such protocol is changed, thus the advent of ADC. I dont wish
to start a debate on ADC but if nothing else it was an attempt at change.

I don't seem to understand because I've leafed through ADC documentation (0.12) but not even connect methods have changed in the ADC protocol (CTM arrival) :( (at least yet, and how it's documented)
I haven't found anything descriptive regarding how the actual connections going on - I mean what happens on different side transfers if the connection is established.

Offline bastya_elvtars

  • Forum God
  • ****
  • Posts: 3 744
  • Karma: +173/-7
  • The rock n' roll doctor
    • The FreshStuff3 Site
Re: Download blocker problem
« Reply #13 on: 26 December, 2006, 23:10:41 »
Erm well, I download from you but you aren't allowed to download from me.
How would this look in the rules? :)
Everything could have been anything else and it would have just as much meaning.

Offline Naithif

  • Triple Ace
  • **
  • Posts: 199
  • Karma: +32/-13
Re: Download blocker problem
« Reply #14 on: 27 December, 2006, 12:02:36 »
Yes, you're somewhat right, maybe this script's beauty is in it's imperfection
Anyway, I only added it into my script in case it would be needed (not like I think it so :D) and came across that problem, and tried to solve it, it succeded in some crude way as I guessed it earlier.
I'm not planning to use it

(And B?stya, I've seen enough "you must be regged to be able to download here" messages to know that it looks shit in the rules  ;D It's the same as not letting people enter the hub without reg)

Offline TTB

  • Lord
  • ***
  • Posts: 436
  • Karma: +17/-1
Re: Download blocker problem
« Reply #15 on: 13 November, 2007, 15:23:48 »
Hi,

I've just created such script, and indeed... this is also a problem I faced with. Putting a nick in a temp table by RevCon, to establish a connection in CTM works, but the other user can still download when the connection has been made. Just confirming the problem. Afaik, there is no way to solve this problem. Blocked users can always download from "allowed" users who set up the connection.
TTB

(? ?.??.-> Admin @ Surfnet hubs <-.??.???)

Offline TTB

  • Lord
  • ***
  • Posts: 436
  • Karma: +17/-1
Re: Download blocker problem
« Reply #16 on: 14 November, 2007, 11:57:00 »
I really don't think so because this must happen after the
transfers has been initiated and is then client to client [after
the hub has handed the request off].
I mean... when a non-allowed user try's to download from an allowed user, the connection is blocked. The filelist remains in the downloadqueue. When the connection is established (by the allowed user), the non-allowed will get the filelist. As long as the connection remains, the non-allowed will be able to download from the allowed user.

Am I wrong Mutor?
TTB

(? ?.??.-> Admin @ Surfnet hubs <-.??.???)

Offline Naithif

  • Triple Ace
  • **
  • Posts: 199
  • Karma: +32/-13
Re: Download blocker problem
« Reply #17 on: 14 November, 2007, 12:35:59 »
I mean... when a non-allowed user try's to download from an allowed user, the connection is blocked. The filelist remains in the downloadqueue. When the connection is established (by the allowed user), the non-allowed will get the filelist. As long as the connection remains, the non-allowed will be able to download from the allowed user.

Am I wrong Mutor?

True (As it was written above, and was discussed throughout)

Other implementations has only more flaws thou - for example, another hubsoft has block download at hub level, but reconnecting to the hub makes the connection up'n'go.

Every (including my old script above) version of download blocker is VERY flawed, and isn't possible to fix, because it was never meant to be this way.

Besides, that script & discussion was at that time when there wasn't any blocker scripts (at least not public), just those ones that blocked all passives. Since then there are way betters, with discussion in most topics where they are.
« Last Edit: 14 November, 2007, 12:38:36 by Naithif »

Offline TTB

  • Lord
  • ***
  • Posts: 436
  • Karma: +17/-1
Re: Download blocker problem
« Reply #18 on: 14 November, 2007, 13:21:23 »
There is a way, but allowed users won't also be able to download from non-allowed users. Only this way the block works.

TTB

(? ?.??.-> Admin @ Surfnet hubs <-.??.???)

PtokaX forum

Re: Download blocker problem
« Reply #18 on: 14 November, 2007, 13:21:23 »