|
About:
MUTE File Sharing is an anonymous, decentralized search-and-download file sharing system. Several people have described MUTE as the "third generation file sharing network" (From Napster to Gnutella to MUTE, with each generation getting less centralized and more anonymous). MUTE uses algorithms inspired by ant behavior to route all messages, include file transfers, through a mesh network of neighbor connections.
Author:
Jason Rohrer [contact developer]
Homepage:
http://mute-net.sourceforge.net/
Changelog:
http://mute-net.cvs.sourceforge.net/[..]e-net/MUTE/doc/changeLog.txt?view=markup
CVS tree (cvsweb):
http://mute-net.cvs.sourceforge.net/mute-net/MUTE
Trove categories:
[change]
Dependencies:
[change]
No dependencies filed
|
|
» Rating:
7.87/10.00
(Rank N/A)
» Vitality: 0.01% (Rank 5464)
» Popularity: 2.55% (Rank 1878)
 
(click to enlarge graphs)
Record hits: 31,514
URL hits: 13,278
Subscribers: 54
|
|
Branches
Comments
[»]
An idea
by DannyB3 - May 15th 2004 09:45:31
I like Mute's virtual network.
Still, a possible problem is that an entire file is sent from point A to
point B.
Now suppose that instead of files, two things could be requested over the
network.
1. A list of block numbers that make up a particular file.
2. A block's contents, by its id number.
An end user does a search for "The Worst Song Ever". A number of nodes
may respond to the search. Each responding node responds with a list of
blocks and instructions, like this...
The resulting file is length 2837889 bytes.
Block 1 consists of Blk_295837 XOR Blk_285211
Block 2 consists of Blk_9111ZQ XOR Blk_121193
Block 3 consists of Blk_11AAB1 XOR Blk_87222AZ XOR Blk_8922279
....etc....
Block 2852 consists of Blk_118sjK XOR Blk_ZZiww9
Resulting file checksum is ZQ29878228
Once your software re-assembles a file, it is truncated it to the length
2837889 specified in the list of instructions. All blocks are fixed
length, like, say, 4096 bytes. But not all files are multiples of 4096.
Therefore, the length specification.
So when doing a search, you enter a term, like "The Worst Song Ever", and
get back one or more sets of instructions from responding nodes. (Note
that responding nodes may not even contain any of the actual blocks in the
instructions!)
Now, in BitTorrent like fashion, you can start requesting all of the
blocks. Any node with a particular block can send it to you. Once you
have that block, you can offer that block to anyone else by it's id
number.
The block ID's could be something like the MD5 hash of the block's 4096
byte contents.
Each block will pass a statistical test for randomness. That is, each and
every block appears to just be random bits. No block is part of the file
"The Worst Song Ever". But by XOR'ing blocks together you reconstruct the
file "The Worst Song Ever". No single part of the file will have come from
any other node in the network.
Furthermore, any single block may be part of multiple files. Some
unscrupulous organization could complain that "The Worst Song Ever" was
made, in part, from Blk_295837, and therefore Blk_295837 must infringe the
copyright on "The Worst Song Ever".
But Blk_295837 may also be part of another file such as The Bible, or The
Declaration of Independance. So how could Blk_295837 be infringing if it
is also part of the recipie for two things like The Bible, or The
Declaration of Independance?
You may be able do download "The Worst Song Ever" much more quickly,
because the blocks it is made from may be scattered all over the network.
Partly, because those blocks may be part of the recipie to other files.
Each block can be sent as a UDP type message. Lack of receipt of a
particular block simply results in eventually that block being
re-requested.
The obvious drawback to this scheme is that downloading "The Worst Song
Ever" requires two or more times the bandwidth, because every single part
of it is constructed from XOR'ing a minimum of two blocks.
But this leaves unscrupulous organizations with problems. Which blocks
are infringing? Is it infringing to merely provide a recipie in response
to a search request? Because of the very nature of Mute, which node in the
real world did a particular block or recipie originate from?
Another drawback is that this scheme seems to assume that nodes stay up
for a long time. Otherwise, the blocks are pointless. If all nodes are
short lived, then each node must always provide all of the blocks for any
files it offers. This idea seems closer to FreeNet than Mute. This idea
of blocks and recipies could be implemented on top of FreeNet.
[reply]
[top]
|
