Slashdot Mirror
Decentralize BitTorrent with Kenosis
UnderScan writes "Eric Ries, writer/programmer/CTO, authored an article 'Kenosis and the World Free Web' at Freshmeat [Owned by Slashdot's Parent OSTG]. Kenosis is described as a 'fully-distributed peer-to-peer RPC system built on top of XMLRPC.' He has combined his Kenosis with BitTorrent & removed the need for a centralized tracker. He states: 'To demonstrate Kenosis's suitability for these new applications, we have used it to improve upon another peer-to-peer filesharing application that Just Works: BitTorrent. BitTorrent does one thing incredibly well. Using a centralized "tracker," BitTorrent manages efficient distribution of data that is in high demand. We have extended BitTorrent, using Kenosis, to eliminate this dependence on a centralized tracker.'
See also the Kenosis README for details on using Kenosis-enabled BitTorrent."
n. Christianity
The relinquishment of the form of God by Jesus in becoming man and suffering death.
Thinkin' Lincoln - a web comic of presidential proportions
How is the RIAA and MPAA supposed to stamp out bittorrent if you guys keep improving it? Where's your compassion?
Then this falls a bit short of the "killer p2p app" moniker that it *almost* deserves.
The old Lie: Dulce et decorum est Pro patria mori
QUite useful, of course! We could distribute spatial-data, and Wi-Fi locations to PDAs and laptops in this way. There are metric tons of useful applications for BT and K.
Zhrodague.net - I do projects and stuff too.
Decentralization is generally useful for any application where failure of some critical node results in failure of the entire transaction. Distribution of any data via bittorrent will benefit - regardless of content - if there is a possibility that a tracker host could fail.
From the feature list...
Kenosis works in almost any networking environnment, including restrictive corporate firewalls, because it uses XMLRPC for its network communications. It can also work with an HTTP proxy.
This alone makes a worthwhile project, for those stuck behind firewalls/proxies.
This will probably considered a troll also, but I think the obvious answer is porn.
One of the problems with BitTorrent is that the trackers themselves can get overloaded with too many clients. If this system can eliminate something like that happening then that'd definately be a good thing.
;)
That being said, the busiest torrents I've seen are for copyright-infringing material, so I guess it's still a boon for piracy.
"People that quote themselves in their signatures bother me" - athakur999
We all knew this was coming, but would this app get this kind of exposure had the MPAA not cracked down on those BT tracker sites?
It is just like Scour net (web based/centralized), then napster (p2p/centralized), then kazaa (p2p/decentralized). Every time they go after a technology, they force it to evolve into the next phase. They will never win IMHO.
Allow oppressed people to anonymously distribute large incriminating videos of their corrupt government?
When will the Empire^H^H^H^H^H^H *AA ever learn?
You have two hands and one brain, so always code twice as much as you think!
This is an important step, but it still does not hide the user's IPs from the *AA.
From the Article:
It does not address problems of anonymity, privacy, or distributed data retention, although we hope to address these issues in future versions.
It's fun to see how book-writing hackers act.
;)
What, you mean, by using the right tool for the job instead of language snobbery?
I think I found a defect.
This thing doesn't make any fucking sense.
I was really excited by this slashdot story, because I think something like this could be very very useful. I have to say that I was disappointed a bit by the download.
No docs or pointers at the top of the tarball.
One of the READMEs on the site says try "test.py" for an example, which seems to just hang.
Elsewhere it says to fire up bittorrent
trackers and clients.
There clearly is a lot of work that has gone into this, and the idea sounds really promising, but it looks like it needs a better end-user documentation before it's ready for primetime.
Continuing reading, you can see that it's possible to directly have a torrent reference the network. The kenosisp2p.org bit is only for legacy clients that wouldn't know what to do with a "new" tracker location.
Omnes stulti sunt.
Remember, with enough lawyers _everything_ you do on your computer or download from the Internet may be considered illegal.
OTOH - if - for example - you crack a proprietary video codec so that it is suited for full-length movies distribution, add a cracked proprietary sound codec, name it all after a proprietary technology, then take some others' source, tweak it a bit, urge other peoples to contribute promising that it will be "free for ever", then demand money for it - it is still ok if you form a company! You can even put your certification on hardware players and stuff. Voila. (Yes, I do troll, "mod me down". But better yet - reply).
Because you have a fixation on money like some I've been acquainted with.
Seriously... I don't see how to make money off this...
Seriously...why is that important? Did you even read the article? The author of this BitTorrent enhancement does not even use the word "money"--it is WAY down the list of motivations for its creation, not does it seem to be about getting pr0n and warez. This guy sounds like an idealist in a very true sense--it's about decentralisation of control--making content available without being reliant on central servers.
I think this would be immensely useful. The reliance on central BT trackers has been shown to be BTs primary weak point--once a torrent is located and transfer is initiated it is incredibly robust.
Besides the fact that the admins of BT trackers are being harassed into submission by MPAA and RIAA, the more popular trackers seemed to be quite unreliable. If this innovation (open sourced to boot) addresses the reliablity issues in LOCATING the content that BT is so good at DISTRIBUTING then it could be start a dramatic shift in how we use the Internet, much like the WWW was.
It doesn't even have to be about piracy. Used within a VPN or on a corporate WAN it would make distribution of a large number of big applications much easier to distribute. I make VMWare and ghost images of machines that are many gigabytes and this solution would be a great way of distrubuting them to a large customer with global sites (keep in mind that these clients are legally permitted to use these images--my employer is a stickler for that).
A small operator could distribute software this way and save on the costs and time associated with maintaining a critical server with big pipe to the 'net. Security patches could be distributed this way very effectively without reliance on a single entity for distribution. The possibilities are endless. It might not be a money making machine, but it is the kind of thing that (if it works well) could change the face of computing.
Wrong! The DNS server is a hack. Normal bittorrent links lead directly to a tracker. Kenosis bittorrent links lead to HASH.their.server.name. BitTorrent-Kenosis clients will recognize this and use the network. The purpose of the DNS (and the reason it's not btkn://HASH or something) is that legacy clients going there will be given the IP of any Kenosis client that can act as a tracker for it. Killing that DNS would kill legacy clients but not the enhanced P2P ones.
Tired of free iPod sigs? Subscribe to my blacklist
I just read about Kenosis from its homepage. And, I'm forced to ask:
Do we really need yet another bloated python p2p app? I can feel the flamebait and troll mods comming.. but seriously: Python sucks at gui work. It has to use generic wrappeers, like wxPython, that are extremely inefficient. Sure, like Pearl or Java, you can write gui apps using Python... but they always come out slow and over-weight.
Consider the BitTorrent client. Just running the application, without an actual torrent being transfered, consumes 23 MB of memory (on Windows) -- for that cheesy, very simplistic little GUI. When you actually start running a torrent through it, it'll easily chew 40 MB's and gobble considerably more CPU time than a comparable program written in C/C++.
I'm not saying Python isn't a useful language... But it was not designed to run P2P apps.
Just because a programming language can be extended to creating GUI applications does not mean it's a good idea. Python's strengths are elsewhere, and I for one am tired of the BitTorrent community using it to write p2p clients in.
Now go ahead and mod me down for having a modicum of common sense.
/dev/random
If you read the article carefully (or not so carefully), you'll note that this product does NOT include a fully distributed / decentralized tracker... an web server tracker is still necessary for the initial torrent retrieval. If that tracker becomes overloaded / unavailable this system will have real value, but there's still an originating central tracker for the MPAA to go after.
However, it's only a very short matter of time. The author explains that such a thing could be easily created with this framework. Clearly he could have done it if he wanted, so I'm guessing this is a purposeful strategy on his part to avoid any potential direct or indirect personal liability or legal issues down the road...
-R
The problem with Kenosis is, of course, it's reliance upon a central DNS server to point to a list of distributed trackers. Many will undoubtely point out, that this DNS server could be taken off, and that's it.
Now how can we really circumvent this problem? One solution would be to advertize a list of DNS resolvers on USENET. A preconfigured list of newsgroups could be used to bootstrap this, and new usegroups (should the original newsgroups get closed) could be regularly advertized as well. A client would just go to those newsgroups, and fetch the updated list of DNS servers, newsgroups etc...
This system would be much more resilient to attacks by RIAA or MPAA because they won't have a single point to attack. Closing newsgroups is much more difficult than taking one DNS server from the upper zone.
Another way to advertize the DNS servers would be via spam! Yes, you didn't misread this. One can easily encode the location of DNS servers in spams and have clients read those spams, effectively extracting an updated list every now and then!
This is very important, because spam is already used as a covert channel to prevent traffic analysis. Specialy crafted spam checkers can extract useful information from spams. One such information would be the distributed location of trackers (or DNS servers that point to them).
Just because it's unethical (to piggy back useful data on top of spam), doesn't mean that it's not already used on a quite wide scale. There's no reason why it shouldn't work on a new generation of distributed BitTorrent trackers!
cpghost at Cordula's Web.
I see several weaknesses in this, however. If I wanted to attack this, the route is pretty obvious to me. Several lines of attack stand out:
1: Start serving falsely-labelled file data that is correctly represented internally. There appears to be no moderation system built in, so bogus file data will pollute the system.
2: Start serving any file data that is inaccurately represented internally. For example, make all of your hash entries but one accurate, but make that one hash entry inaccurate. Users end up downloading most of the bad file before it errors out. Depending on the setup of the server and client, they may continue trying to get the data from elsewhere, in which case you could serve larger amounts of corrupted data, possibly by using bad clients working in conjunction.
3: Hash cracking: Brute force hash cracking could allow fake data to pass as real, hash-matching data; only a single cracked piece per file is needed. This would probably be economically inefficient, however, compared to #1 and #2 in terms of the ability to disrupt network usage.
4: Mass peer suits. If BT is the download manager here, getting the people who have the file being shared is laughably simple.
There's probably also some risks for their proposed change to allow multiple seeders, but I'd need to think about it for a while.
1, 2, and 3 require an "intelligent" client. In real life, we inherently weed out those who give bad data simply by our experiences and the experiences of those we know. The more we trust a person, the more we trust what they tell us about others. This sort of system tends to inherently isolate out the bad apples, even if they work together. Even if, working together, they manage to convince a good client that they're right and others are wrong, that good client too will simply be viewed as a liar and its data shunned. Overall, the system will remain intact. It's no easy programming task, however; yet, it is doable, as evidenced by the fact that we, as humans, do it every day.
#4 has a simple solution: Involuntary mirroring. If this system would automatically force the mirroring of data into a cache on the destination machine, and serve it from there, there would be no way to know whether a person was actually uploading copyrighted material or simply acting as a "router". Since our law has finally started to catch on to the fact that it is unreasonable to sue those whose computers pass through illegal data that they had no realistic way of knowing about, it would effectively anonymize *all* data on the network.
Hey, guys, I'm just pleased as punch to report that it's a fleet of a hundred Vogon Battle Destroyers!
Lets simplify this. You are a program that doesn't know anything about the world, because you are a de-centralized program. You are started by your master ("user," in human speak). What do you then do? Who do you connect to? Surely if you had an address hardcoded somewhere you would no longer qualify as being decentralized. Do you start walking the IP space, trying to connect to 1.1.1.1, 1.1.1.2, and so on? Oh, so the IPs you have coded in your config are "only hints," huh? Okay, then you should be able to cope with all those "hints" having gone bad. When those hints are all bad, what do you do, Mr. D. Centralized Program?
Decentralized, my ass.
Must-not-watch TV!
(I am one of the authors of Kenosis.)
We are planning improvements to Kenosis in a number of areas such as better integration with BitTorrent, a more distributed BT tracker, simulation of larger Kenosis networks and making Kenosis work over NAT.
We'd love help with any of these or other areas.
Please join the mailing list to get involved.