|
|
Posted by privateer on 10/10/07 02:30
On Mon, 10 Sep 2007 15:11:03 -0700, Greg Farr <gregfarr@comcast.net> wrote:
>been flooded with Faux Files by the hundred, and with some films, I
>don't see any good enough to d/l. A few weeks ago, before it quit on
>me the latest time, it was doing a good job and searches were small
>but useful. What happened? Was my patch corrupt? Do you peeps have
>simaler problems, do I get a new patch. I first put 3.4 in and then
>3.5.
>
>Greg
>http://gregsplace.50megs.com
>http://www.picturetrail.com/fugitive1
IF you are being flooded with fake files, you are causing it [most of the time].
It takes two parties to flood fake files. One party, the RIAA/MPAA mercenaries, loads
lists of fake files. The other party, the user [you], triggers the fake file floods by
searching for RIAA/MPAA protected media.
If you want to stop seeing fake files, STOP searching for RIAA/MPAA artists! Its that
easy. Boycott RIAA artists. That is the ONLY effective solution so far and the only one
that will stop the RIAA in its tracks and kill it.
I hear some voices saying 'Hey! we have the solutions. A DLL that does blocking and
filtering' of fakes. - Bullshit. The fakes are still there, using more WPN bandwidth and
resources than ever.
Blocking:
How is this blocking scheme SUPPOSED to work? [not that it does]
The first step is to identify the Fake File Flooders [FFF] and determine the IP they are
using. That might be possible, but the RIAA has virtually unlimited resources and can
change IPs on whim, so keeping such a blocklist up to date is a constant task. Lots of
work, fun but tedious.. but let's assume such identification and list maintenance is
effective and current.. then what?
The next step under the current scheme is to use that blocklist to prevent the FFF from
connecting as parasitic secondary clients to WPN primaries. Can't be done. Many people
will use the DLL which was designed to automatically upload such a blocklist and IF
running as a PRIMARY hub to prevent/block any clients with blacklisted IPs from connecting
as secondaries. There is also a non-DLL 'solution' that performs the same task for those
who prefer to use a modified hosts list to connect to WPN. This patch also installs
PGlite and uses the same blocklist to prevent connections from the FFF.
Does this scheme keep the FFF from connecting to WPN? NO!
The FFF may be rejected by the blocklist users, whether by the DLL or the PiePatch/PGlite
method, but all that does is make the FFF seek out and connect to primaries not running
such black list blocking. The FFF still are able to connect to WPN so nothing is really
gained by blocking except the rather empty personal satisfaction that the FFF is not using
YOUR primary connection to join WPN. The FFF merely move on to an open primary to connect
to.
If by some magic wand the blocklist could be constantly kept up to date with every IP the
FFF use AND EVERY primary hub, 100%, is using this current blocklist, the FFF would still
be there on WPN. All they would have to do is run their own primaries without blocking
themselves.
Blocking is a nice theory, but in reality is an exercise in futility. And all the
user-bashing blaming non-dll users for harming WPN is just divisive bullshit. In fact,
those who use the blocking/filtering DLL and continue searching for RIAA protected files
are actually aiding and abetting the RIAA cause by overloading WPN. as follows...
Filtering Fakes:
The current km/WmW DLL scheme for filtering fakes from search results may be doing far
more harm than good. Again, nice theory, but the far reaching ramifications were not well
thought out.
While specifics on exactly how the DLL filters out the fake files is not easy to come by,
suffice it to say that the process involves search result packet inspection, examining the
IP of the file source. If the file source IP matches an IP on the FFF black list, it is
filtered, somehow. This packet parsing and IP checking adds CPU load to whatever computer
is doing the filtering.
The sofar unanswered question is who's computer is doing the filtering? Who's CPU power
is being consumed for this process? Does it matter?
But what is really happening to effect fake file filtering and what effect is it having on
the infrastructure of WPN?
The current explanation of the process at
http://www.winmxworld.com/tutorials/fake_file_info.html .. is less than clear exactly how
the filtering is done, so it poses more questions than it answers for me. This line
perhaps offers a clue: "Any secondaries attached to a WinMXGroup primary are
automatically protected and will not receive any fake results".
To me that suggests that the filtering is done by the DLL primaries, by parsing EVERY
search result, fake or not, and dumping any that come from IPs on the current block list.
These DLL primaries may save a little bandwidth by not forwarding these chaff packets, but
wouldn't it be at the cost of more CPU resources on the primaries computer? Perhaps the
CPU load of filtering and dumping would be less than the CPU load for propagating the
results without filtering, I don't know. But it seems that IF the primaries are doing the
packet parsing and filtering, they would be doing this for all search results, even good
files and not just the fake chaff files. The user searching for such chaff-protected
files gets a free pass and the burden of these searches is dumped onto the primaries and
the net infrastructure. I suppose the RIAA could add lots of clients to do continual
searches for their own chaff-file trigger words thereby causing an avalanche of results
that the DLL primaries would have to work overtime to filter. Is that good practice?
And if the burden of filtering the chaff-files is handled by the searching users own
computer rather than by the primaries, then the CPU load is on them, but the bandwidth
load [and related CPU loads] are felt by primaries all over the net.
It seems that this filtering comes at a significant infrastructure resource cost
regardless. And by making it so users are oblivious to the ill effects of searching for
chaffed files, it would seem to be common sense that they would continue to search more
and more for the in-demand latest files that tend to be chaff-protected. Without seeing
the results on their screens, their behavior would continue unchanged or likely become
even more helpful to the RIAA as unwitting accomplices to their flooding scheme.
Compare that to a host list user, who sees the results of such searching with lots of fake
file results. Wouldn't it be common sense that they would change their search habits and
just maybe start to thumb their noses at RIAA/MPAA content? And make fewer searches for
such 'forbidden fruit'?
Again, I am not clear exactly how the filtering is done, but I think more might be
involved than simply "improving" the user experience by masking the detrimental effects
their behavior has on the WPN infrastructure.
Yes, ideally if everyone connecting as a primary hub used the blocking DLL or PG with an
up to date blocking list, there would be no fakes to filter... Even IF that could be
achieved, the RIAA has easy ways to defeat it by simply running their own non-blocking
primaries.
All I know is that flooders attack the secondary connection pool and searches for chaffed
files takes its toll on the WPN infrastructure filtered or not. Whether or not the CPU
cost of filtering all search results is less than the CPU cost of propagating those
results back to the searching user I don't know. IF the DLL primaries do have to
sacrifice their CPU resources to filter the packets, is it overbearing? It would seem to
save bandwidth if this is how it works. But what protects the user connected to a
hosts-list primary that doesn't filter the fakes for them? Does their DLL redundantly
parse and filter the packets also? Or is all of the filtering done at the search
requesters computer? If that, then the WPN bandwidth is stressed.
Like I said, more questions than answers...
Easiest solution is to stop searching for RIAA protected files. Boycott them and their
artists. Destroy that corrupt empire and help free the artists from their oppressive
yokes. Encourage artists to not sellout their rights to the mega-media corps that are now
even demanding that the artists sign over rights to their name and webpages to get a
recording contract. The RIAA monopoly on marketing music is now superfluous. With
computers for digital recording and mixing and the internet for promotion and
distribution, artists are no longer bound to the 'recording industry'.
Navigation:
[Reply to this message]
|