|
|
Posted by fred-bloggs on 09/09/05 15:52
anthonyberet <nospam@me.invalid> wrote in
news:3obdgsF54pu3U1@individual.net:
> 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. Blocking ranges at the cache server would be a
> good quick fix, but might have workarounds, such as proxying.
I see no reason to use hacked or bespoke clients, it is a simple matter
to use winMX itself as a source of fake files.
> I think cutting down on search responses would help reduce fakes as
> you say, but it would also reduce genuine hits.
Agreed, but it might be the lesser of two evils.
> 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.
>
> 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.
My thought, same effect, would be to have the primary connect to
supposedly active secondaries and demand the file list.
>
> Sadly, I don't think FC are going to fix this.
>
--
fred
Navigation:
[Reply to this message]
|