Split: Passives and SR's

[bINKbINK]

hi guys^^

sorry if i've taken this thread afloat...
and of course sorry for my silly question..
but:
in terms of protocol, why a passive user does not receive $SR from another passive user?

i know that if the $Search was a passive one, the $SR is returned via the hub connection, via TCP. but why the user does not receive $SR if the source was another passive?

actually i'm missing it...

i'm asking for this because i've notice that and actually i'm a kinda of perplexed...

thx in advances and sorry if i miss the right section

[ivulfusbar]

If two persons are truely passive, then their is no use to reply with $SR since they can't connect to eachother. It is a waste of bandwidth. We will have millions of "i can see this file when i search but i can't download it threads" in this forum otherwise.

[bINKbINK]

then their is no use to reply with $SR since they can't connect to eachother.

do you mean that it is the client itself that does not send $SR if it has received a passive $Search?

We will have millions of "i can see this file when i search but i can't download it threads" in this forum otherwise.

indeed, i see...
yes, you right... even if certain times it can propably be useful...

[GargoyleMT]

do you mean that it is the client itself that does not send $SR if it has received a passive $Search?

Yes, it does not send a $SR to a passive $Search if it is in passive mode itself.

See:

Code: Select all

	// We don't wan't to answer passive searches if we're in passive mode...
	if(isPassive && !ClientManager::getInstance()->isActive()) {
		return;
	}

[bINKbINK]

Yes, it does not send a $SR to a passive $Search if it is in passive mode itself.

See:

Code: Select all

	// We don't wan't to answer passive searches if we're in passive mode...
	if(isPassive && !ClientManager::getInstance()->isActive()) {
		return;
	}

yes.. i've just realized it...
but i was also thinking that it can be very useful in certain times... isn't it?

anyways, thx for your replies^^

[GargoyleMT]

but i was also thinking that it can be very useful in certain times... isn't it?

If so, there have been surprisingly few complaints about it publically since I've been working on DC++.

[Quattro]

indeed.
what is the use of getting search results from a passive user when you're passive yourself?
you can't download the files anyway so why would you want to see what you can't get anyway :S

[bINKbINK]

what is the use of getting search results from a passive user when you're passive yourself?
you can't download the files anyway so why would you want to see what you can't get anyway

but you're thinking about downloading and nothing else...
that's not the way i was considering...
what about an OP in passive mode who's checking forbidden files in his hub?
if he's able to see $SR from *all* users (passive ones too), his check is indeed better... isn't it?
in the way i've described, he eventually can kick or ban even users whom usually he can't kick or ban... what's different? more hubs well checked...

[Todi]

I've got a better idea: The OP should use active mode.

Problem solved, bandwidth saved.

[bINKbINK]

I've got a better idea: The OP should use active mode.
Problem solved, bandwidth saved.

what about passive mode?
it sounds like discrimination... everytime thinking about active...
then, why passive mode exists?!
since it exists, let's think about it too...
i don't understand why an OP who's in a LAN, for example, can't be OP because he's passive and nothing else... actually i'm missing it..

instead of this... let's work for passive too... let's enable passive OPs to do their job as the other OPs do... isn't it better?

[ivulfusbar]

Most OPs doesn't know enough to understand the difference between a passive and an active search-reply. Most OPs have for many years kicked/banned users depending on active search-replies which are extremly easy to spoof nickname/content in. Ofcourse IP is unique upto NAT. Passive search replies are more secure an can be trusted more.

For ops you can simply set up a proxy to search through. Its fairly simple.

[GargoyleMT]

I don't think it is a good solution, but searches by operators could be treated differently.

A user who can only set up passive mode (or run one client, if he is also on LAN hubs) doesn't make a good operator, from a technical point of view. Passive mode is limited, and it's meant only to let people use DC somewhat. It's not meant to be equivalent to active mode.

[ullner]

Just add "|| isOP()" in above code and distribute?

[bINKbINK]

I don't think it is a good solution, but searches by operators could be treated differently.

me too, i think so

A user who can only set up passive mode (or run one client, if he is also on LAN hubs) doesn't make a good operator, from a technical point of view.
Passive mode is limited, and it's meant only to let people use DC somewhat. It's not meant to be equivalent to active mode.

so, let's do something to make passive OPs and active ones equal...
yep, i know that.. i know that it's meant only to let people use DC somewhat. but we're considering OP, not people. we're considering checks and hub security, not downloading.
isn't the time to consider it too?

Just add "|| isOP()" in above code and distribute?

right, i was just thinking something like that...

[PseudonympH]

Of course, then ops will try to download some files, and kick you for them not being able to download from you. I don't think we can win here.

[GargoyleMT]

so, let's do something to make passive OPs and active ones equal...
yep, i know that.. i know that it's meant only to let people use DC somewhat. but we're considering OP, not people. we're considering checks and hub security, not downloading.
isn't the time to consider it too?

How can we make them equal? I don't see a way to tell them that they can see files, but can't download them. And we can't fix old versions of DC++ like 0.401, on which operator specific clients still seem to be based.

I suspect that just as few passive operators need to truly be passive as normal users. More than a few users who are M:P have said that they are just because they can't figure out port forwarding.

I don't see a compelling reason to change anything. (And ADC certainly isn't going to behave the way you want.)

[Pothead]

Of course, then ops will try to download some files, and kick you for them not being able to download from you.

Yup, i foresee that happening as well.
I personally think it works fine as it is. And if they want to search for bad files of all users, well, get the hub to run a script or a bot.

[bINKbINK]

Of course, then ops will try to download some files, and kick you for them not being able to download from you. I don't think we can win here.

if OPs have a little piece of brain in their head they'll probably figure it out...

How can we make them equal? I don't see a way to tell them that they can see files, but can't download them.

the point is that we are not consedering downloading...
ok, right, they can see some files thay can't download...
let's stress those files in the client, in the SR's window, for example... so that eventually OPs will understand what are available for downloading and what not...
and as i've just said, we're talking about OPs, not newbies. i think (well, i hope) that OPs aren't those users who don't understand even the differences between passive and active...

And we can't fix old versions of DC++ like 0.401, on which operator specific clients still seem to be based

as ullner suggested, we have to add that little piece of code and nothing else... where's the problem?
actually i'm thinking it isn't so difficult fixing that code...

I suspect that just as few passive operators need to truly be passive as normal users. More than a few users who are M:P have said that they are just because they can't figure out port forwarding.

i don't think so...
just an example: in my country there's a provider that is a LAN.
yes, an ISP that is a LAN. and all users have to be in passive mode if they want to connect to pubblic hubs...
so, what about those OPs who have that ISP?
yep, probably some OPs don't know the differences between passive and active... but if silly owner choose silly OPs, i don't think the other OPs have to pay for it... of course, the other OPs who truely need be passive.

And if they want to search for bad files of all users, well, get the hub to run a script or a bot.

why we have to waste more bandwidth using bots if we can let the OPs do the same job?
then, let's also consider those hubs that can't be checked by bots...
and believe me, they exist...

[ivulfusbar]

Why would it be in DC++ best interest to fullfill some issue for passive OPs?

I don't get why it would be in the clients interest.

[Pothead]

And if they want to search for bad files of all users, well, get the hub to run a script or a bot.

why we have to waste more bandwidth using bots if we can let the OPs do the same job?
then, let's also consider those hubs that can't be checked by bots...
and believe me, they exist...

From a Search point of view, you only need one bot. Or a script. Which if ran from, the hosts pc, should always get full results. And use the same amount of bandwidth as 1 extra user in that hub.
You only need one active mode op, not pamper to loads of passive op's.

[poy]

imagine the little "|| isOP()" was included in DC++ 0.695. now, a passive user using DC++ 0.694 or an OP mod based on it does a search: he will see the results sent by passive users using DC++ 0.695. how are you going to tell the user using DC++ 0.694 that the $SR he has just received is not a "fake" file, but can't be downloaded?

edit: and i think you should download file lists and check these lists if you want to forbid some bad files; see this: http://dcpp.net/blog/?p=113

[GargoyleMT]

as ullner suggested, we have to add that little piece of code and nothing else... where's the problem?
actually i'm thinking it isn't so difficult fixing that code...

You're correct that the difficult part isn't in changing the code, it is the implications of the change. And since there are some problems that will occur, that's why we need to be convinced. Ignoring the fact that operators will want to download any file they get in their search results (they don't always just check files -- they also are users of the application) isn't a good solution, in my opinion. Or rather, it creates a problem that I perceive to be much bigger than your original "problem."

[bINKbINK]

ehm.. sorry if i'm answering now... but i've been a kind of busy in these days...
well,

From a Search point of view, you only need one bot. Or a script. Which if ran from, the hosts pc, should always get full results. And use the same amount of bandwidth as 1 extra user in that hub.
You only need one active mode op, not pamper to loads of passive op's.

well, right.. i can use a bot or a script... even if the bot is hosted by an active OP... but what is the quality of that control?
i mean: how exact can be this kind of check? the bot miss that important feature called "human factor".
a bot (or a script as well) can search for some bad words in the filename, and nothing else. it is not able to *decide* if a certain file *can* or not be a forbidden file. We all know that some bad files are shared with another name sometimes. and of course some of those with names so different from their own content either.
On the contrary, an OP can value this, he can decide if some filenames can hide forbidden files. and of course he can looking for sospicious files, something that a bot will never be able to do.
so, a question: can a bot (or a script) *really* replace a human being?

imagine the little "|| isOP()" was included in DC++ 0.695. now, a passive user using DC++ 0.694 or an OP mod based on it does a search: he will see the results sent by passive users using DC++ 0.695. how are you going to tell the user using DC++ 0.694 that the $SR he has just received is not a "fake" file, but can't be downloaded?

i've already answerd to this question...
as i said, we can stress those files, or we can underline them. i don't know.
but of corse we can put them in evidence graphically...
i don't think it can be a problem... there are so many way to avoid that...

You're correct that the difficult part isn't in changing the code, it is the implications of the change. And since there are some problems that will occur, that's why we need to be convinced. Ignoring the fact that operators will want to download any file they get in their search results (they don't always just check files -- they also are users of the application) isn't a good solution, in my opinion. Or rather, it creates a problem that I perceive to be much bigger than your original "problem."

i'm pretty sure there won't be so bad implications as you said...
of course an OP is a user too, and of course he wants to download either.
but we can solve the question putting them in evidence or putting them in another window. or better, we can add an option in the search window that we can select. We can call that option "get even passive SR" so that the OP will be able to decide if he wants to search for bad files or if he wants only search for downloading.
of course, if we don't select that option i suggested, the OP won't receive passive SR, so that he won't see some files he can download.
We let the OP decide what kind of search he wants to do. that is just an example...

DC is great network indeed.
but i think it can be improved...
DC has a weak point, a point that the other p2p softwares do not have: the passive mode.
everytime we're thinking about active mode and we work harshly for that, ignoring its weak point.
but we have not to allow ourselves that something like that can happen... DC is made of those two things: active and passive. and we can't go on developing only one side and let the other one leave alone.
If we want DC to be greater, we have to work for its weak ponts too, and actually passive mode is one of them. so, i think we have to devote the same resources both to active mode and passive one.
i think it isn't a good behavior going on ignoring passive mode...
let's improve DC, let's work to make it greater...

[poy]

imagine the little "|| isOP()" was included in DC++ 0.695. now, a passive user using DC++ 0.694 or an OP mod based on it does a search: he will see the results sent by passive users using DC++ 0.695. how are you going to tell the user using DC++ 0.694 that the $SR he has just received is not a "fake" file, but can't be downloaded?

i've already answerd to this question...
as i said, we can stress those files, or we can underline them. i don't know.
but of corse we can put them in evidence graphically...
i don't think it can be a problem... there are so many way to avoid that...

no, you can't, by sending a "weird" $SR from a DC++ 0.695 (in my example), have DC++ 0.694 stress / underline / color the files or whatever. you can't change the DC++ versions that already exist, and that won't understand why passive $SRs are being send to them (ie they may display them but there is nothing you can do in these older versions to have them change something in the way they display the passive results).

[Pothead]

i'm pretty sure there won't be so bad implications as you said...

Do not under estimate the stupidity of stupid op's. This is a bad idea because it'll result in 1000's of innocent users being kicked by stupid op's. Ain't broke don't fix, and all that.
There is no problem at the moment. Stop trying to make a massive one. Please.

DC has a weak point, a point that the other p2p softwares do not have: the passive mode.

They also have passive mode, they just hide it. e.g. with torrents, and no open port you get a popup box "couldn't connect to port, this will result in very slow transfers".

[cologic]

Equality between DC's treatment of passive and active "ops" (those who either get OP in INF or are in $OpList, depending on protocol) should be subordinate to the equality of "ops" and non-"ops". Given that those two either conflict or require passive non-"ops" to be treated identically, in no case should an isOp() check or equivalent, clientside, be performed. Alternatively, the client's view of an op has little necessary with a hub's view of an operator todo, so the arguments that because ops have some power, they should be treated specially by a client is specious.

[GargoyleMT]

or better, we can add an option in the search window that we can select.

As long as you understand that DC++ would have to be changed on the side that is being *searched*. DC++ could certainly filter passive search results by default and allow the user to select to filter them.

However, hubs may drop this anyway, there have been a few inquiries into such by hub developers like Yoshi.

This change would take a while to be effective.

DC has a weak point, a point that the other p2p softwares do not have: the passive mode.

What p2p networks are you basing this on? eDonkey has lowID, Gnutella, Kazaa, and even WinMX all have (or had) equivalents.

I'm not sure how you got the idea that being unable to accept incoming TCP connections (or UDP packets) was an imaginary problem, but it has to stop now.

[shufty]

there's a few ways to do it:
Removing the context menu's applicable options "download this file" "match queue" and so on...
adding yet another tick box in search for "receive passive results" which could be greyed out or not shown when in active mode.
an auto set option when clicking "only where im an op" with the possible option to turn that off in advanced settings.

It all gets back to what fusbar said about passive ops; it is a small corner of the dc++ world.