|
|
Posted by Billy Joe on 09/08/05 23:05
anthonyberet wrote:
> Billy Joe wrote:
<snip>
>> This is a behavioral problem, not an IP address problem.
>>
>> The behavior in question is: answering queries in an overly
>> aggressive manner.
>>
>> If FC were to do anything, and it might be understandable to do so
>> as a network integrity measure, it would be to have primary nodes
>> limit responses from secondary connections to a piddling few per
>> time period. My own variation on this methodology would be to apply
>> the clamps proportionate to the responses generated - the more
>> responses to a sinlge query, the longer before that secondary may
>> respond again AT ALL. Now there is NO way that all the primary users will
>> EVER implement
>> anything on their own. So FC's concern for net integrity might be
>> the only answer to THIS problem. Not to say that there would not be
>> some future problem instigated in its stead, but this behavior would
>> be put to an end. Considering that authors of software considered
>> unfriendly to "the
>> industry" are now targets, I'm far from optimistic that FC will even
>> issue the next update to WinMX.
>>
>> Scriptor caveo ;-0)
>>
> If I understand correctly what is happening with the type 5 fakes, it
> is that a hacked or bespoke client gets the addresses of lots of
> primaries from the peer cache server and uploads a fake library.dat
> file to all of them.
I'm not sure that the perps expected this windfall; that FC does not prevent
the same secondary from attaching to more than one primary - FC obviously
thinking that ONLY their code would ever be used to connect!! Hopefully
they are now less naive.
The penalty for keeping track of connections is severe tho; server space,
look-up time, and confirmation on the web would slow down connection times
and require more costly servers. When security doesn't come cheaply, it's
an unlikely remedy.
> Blocking ranges at the cache server would be a
> good quick fix,
and useless. Where is the list of confirmed "bad IPs" to come from? For
were a list utilized with any positive effect whatever, would not its
composition change?
> but might have workarounds, such as proxying.
> I think cutting down on search responses would help reduce fakes as
> you say, but it would also reduce genuine hits.
Genuine hits? If a single inquiry causes untoward numbers of "hits" from
the same secondary library, or that library creates total hits of more than
n per time period, then that secondary is merely suspended from replying at
all for period x. Do you really believe this would impact "genuine hits" in
any way whatever?
The idea is to impact fake *behavior* and, coincidentally, reduce the size
of the flood to a rivulet of manageable proportions. This suggestion
doesn't even eliminate fakes, simply dampens their impact on the WPN. Other
tools seem to work well in ignoring fakes.
It's not my intent that a contented lion should become agitated and hungry
once again ;-0)
> What about if the peer cache worked the other way around? Supposing a
> secondary would announce itself to the peer cache, and then await a
> connection with a primary. The primaries would poll the cache server
> when they were short of secondaries, and then ask the secondary to
> attach. After the secondary connects to the primary the primary could
> inform the cache server which could drop that secondary from its list.
>
I think I know what you mean;-0) And addressed it above.
> Or, another possibility would be for the primary to always request a
> random file from the secondary upon connection, and kick the secondary
> off if the transfer times out.
>
Too specific. By that I mean: you're designing a MUST SHARE system.
Commendable from many points of view, save the authors'!
> Sadly, I don't think FC are going to fix this.
Oddly, I agree ;-0)
BJ
Navigation:
[Reply to this message]
|