In a P2P network, a cancer node is a network node that misbehaves and spreads faulty data. The nodes are typically known as "cancer" nodes because the bad data tends to get copied to many other nodes before the node maintainers delete broken files - and even then, unless absolutely all copies of the broken files were deleted from everywhere, the broken files may end up spreading again.

Typically, a node may become a cancer node for two reasons: Due to a software bug or due to malicious node operator.

Software bugs are probably the most common P2P file corruption source. Most P2P networks these days involve some kind of "swarming" mechanism, which means that if a large file is available on multiple nodes, each node sends a small of a file and the requesting node pieces the file together.

Sometimes, hosts send the chunks incorrectly or the file is pieced together incorrectly. (Too many cooks spoil the broth.) This creates broken files. Sometimes, all nodes work normally but one (usually with older, buggier version of software) sends things wrong - one example of cancer node.

One such case might be from giFT. Back in the day, there were clearly some big bugs in the multi-source file download. It was fixed in a later revision. Since all users run code from the CVS and not all people keep their daemon up to date, for a long time there still were hosts that sent chunks incorrectly, thus corrupting files.

The malicious node operators are also a risk on P2P nodes. Obviously, not all people are happy with P2P file transfers for whatever reason (censorship, terrorism, concerns about copyright infringement) and thus try to discourage it by disrupting the network in many ways - one of these ways is putting fake files up for download and hoping they get spread far enough and people forget to delete them.

There are even companies that try to disrupt file sharing on popular P2P networks (Gnutella, KaZaA etc). An example of such company is Overpeer, Inc.

Protection from cancer nodes: Obviously, the most functional way to ensure transfer validity is to rely on checksums on all phases of transfer. Against malicious file sources, there are number of safeguards that are not always well implemented, but are accepted anyway. One of the most obvious example is a network-wide rating system. Many Gnutella clients include support for Bitzi rating database, for example - file may be, for instance, flagged as having small problems or being completely unusable, all based on its SHA-1 checksum. Chunked transfers may also employ checksums. (Then again, validity of the ratings can also be questioned...)

Log in or registerto write something here or to contact authors.