Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×
The Internet

Decentralize BitTorrent with Kenosis 327

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."
This discussion has been archived. No new comments can be posted.

Decentralize BitTorrent with Kenosis

Comments Filter:
  • ke.no.sis (Score:5, Informative)

    by KillerDeathRobot ( 818062 ) on Tuesday January 11, 2005 @02:05PM (#11323045) Homepage
    n. Christianity

    The relinquishment of the form of God by Jesus in becoming man and suffering death.
  • by Anonymous Coward on Tuesday January 11, 2005 @02:05PM (#11323046)
    How is the RIAA and MPAA supposed to stamp out bittorrent if you guys keep improving it? Where's your compassion?
  • by Nosf3ratu ( 702029 ) <Nosf3ratu AT sbcglobal DOT net> on Tuesday January 11, 2005 @02:07PM (#11323071)
    This doesn't anonymize the users, does it? Your IP address is still readily available, no?

    Then this falls a bit short of the "killer p2p app" moniker that it *almost* deserves.

    • I'd like to see someone take this and add anonymity to it.
    • And how do you expecto t "anonymize" yourself in a P2P? You can anonymize the searchs (the README says something about proxys) but for downloading the data, how could you be "anonymous"

      P2P basis is that everyone sends data to anyone in the net. I don't think it can be "anonymous" - you'll be always connecting to someone's computer to download part of a file. It you want to "anonymize" it you'd have to go trought a central server and that doesn't works because it's centralized. You could play some tricks l
      • And how do you expecto t "anonymize" yourself in a P2P? You can anonymize the searchs (the README says something about proxys) but for downloading the data, how could you be "anonymous"

        Someone came up with one way to get around this. Basically, you setup a P2P network where everyone is only allowed to download from peers.

        Let's take a simple, single-path example. Computer A connects to computer B and requests TinyLinux.iso.
        A doesn't know if B *owns* the file or not, or is getting it from computer C.

        B
    • As soon as you enlighten us on how to send a directed IP packet without a destination address, I'm sure someone will write a few dozen p2p apps around it.
  • by hourieh ( 845242 ) on Tuesday January 11, 2005 @02:09PM (#11323098)
    From the feature list... [sourceforge.net]

    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.

    • Nope (Score:3, Informative)

      by EnglishTim ( 9662 )
      If I understand this correctly, this doesn't affect communication between the bittorrent peers, just the client and the tracker. It still won't work through an HTTP proxy.
  • Hi there... (Score:2, Funny)

    by gowen ( 141411 )
    And welcome to KBTR (formerly K/.), all Bit-Torrent stories, all the time.

    Enough, already!
    • Re:Hi there... (Score:3, Insightful)

      by ultrabot ( 200914 )
      And welcome to KBTR (formerly K/.), all Bit-Torrent stories, all the time.

      There are enough non-bittorrent articles to fill your workday, so move along, nothing to see here.

      Bittorrent and p2p arp the hot topics of today (given all the police raids). New projects are certainly worth discussing.

  • Forced Evolution (Score:5, Insightful)

    by Superfreaker ( 581067 ) on Tuesday January 11, 2005 @02:11PM (#11323118) Homepage Journal
    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.

    • by Larsiny ( 753559 )
      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.

      Remember that the next time one of your relatives' or friends' car gets stolen and stripped. Sure the technology to bypass all of the alarms and security measure not to mention the chop-shop techniques keep improving to the point where they keep outpacing the police. To paraphrase you
      • by pcmanjon ( 735165 )
        "For anyone to say this would be most beneficial for anything other than illegal activities would be lying."

        Well, I used BT to get the Rubyx Linux distribution. It was available through BitTorrent and then a proprietary P2P method devised by the developer of Rubyx Linux.

        That was the only two ways to get it... the maintainer ran the rubyx website off his home DSL modem.

        As you can see, people *DO* use BT for legitimate reasons and people like me utilize that.

        Granted, the majority of people pirate using BT
      • Police are reactive. Even on stings, they're reacting to a threat (or at least a perceived threat). Installation of alarms and other security technologies is a proactive process, and those who want to get around them are largely reactive (though there is some reactivity on the part of the security industry to the occasional proactivity of the opponent).

        A few days ago, there was a paper mentioned on Slashdot about safecracking. I found it fascinating, and it was really very eye-opening, because it cut th
    • Ironically, BT was actually a step back from the p2p generation. It was Napster-esque, and thus, first generation p2p (centralized p2p). Kazaa(Gnutella, etc) were 2nd gen (decentralized, p2p). Then the newest apps like Mute, Waste, and even Freenet are 'third gen' p2p. Comprising decentralized structure, p2p connections, and anonymity/security functions for protection.

      3rd gen was an obvious move from 2nd gen. 2nd gen(Gnutella) was a smart, but obvious move from 1st gen(napster).

      4th Gen? I have no idea. A
      • Right, in terms of vulnerability, Bittorrent was a step back. It was created for efficiency's sake. It was a huge step forward in p2p efficiency. Now that it has been proven as an efficient p2p system, it is being extended to have other advantages that p2p has. Thus, there are several categories of improvement that need to be considered:

        P2P transfer, P2P search, P2P speed, and P2P anonymity. Actually, Kazaa had all of these except anonymity (it was speedy in many ways, but not nearly as optimized as B
    • I know this is a bit OT, but it seems that by convention of the English language we have confused the meaning of the word "Revolution".

      People use "revolutionary" in the sense of an idea or concept which is mind-blowing, and brings us in a direction we have never encountered prior. "Evolutionary" is used to describe a system which is usefully extended, modded, but altogether not an unforseeable feat from the perspective of the original object or concept's invention.

      But I think we have them con-fused. Rev

  • by Henry V .009 ( 518000 ) on Tuesday January 11, 2005 @02:17PM (#11323196) Journal
    The problem with this approach is dealing with untrustworthy peer. Without substantial protections, one peer can ruin everybody's downloads.
    • by Anonymous Coward
      That is true, but you only need to ensure that the torrent you have is legit. Since the .torrent holds the checksums of the chunks, if a peer sends you garbaged data a couple of times then you can safely ignore it and move on, lookin' for other ones with the real data. MPAA would have to dump alot of bandwith to make it annoying enough, wich wouldn't be feasible, and even in such circumstance, it'd have to deal with the problem of being ignored after the clients realized it was sending false data.

      You still
    • BitTorrent has said substantial protections built in to the protocols.

      Remarkably, you are not the first to think of this problem. (Sarcasm.)
  • No central server? (Score:3, Insightful)

    by Psychic Burrito ( 611532 ) on Tuesday January 11, 2005 @02:18PM (#11323208)
    From the Readme [sourceforge.net]:

    Details

    Kenosis-BitTorrent uses torrent files which specify a tracker of the
    form http://hash.bt.kenosisp2p.org, where "hash" is the hash of the
    original file.

    Kenosis-BitTorrent downloaders will notice that this is a kenosis url
    and use kenosis to find the tracker that is handling this torrent
    file. Standard BitTorrent downloaders try to resolve
    hash.bt.kenosisp2p.org as normal. Our dns server will look up the hash
    in kenosis and return to the client the ip address of the kenosis
    node that is tracking that file. If that tracker becomes unreachable,
    subsequent lookups for that hash will switch automatically to the next
    available Kenosis-enabled tracker.

    Well, since there is a central DNS server at bt.kenosisp2p.org, how can they sincerely declare this to have no central point of failure? Yeah, of course dns propagates, but turn off this central DNS server and in a few days everything is gone, right?
    • by sinclair44 ( 728189 ) on Tuesday January 11, 2005 @02:25PM (#11323311) Homepage
      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.
    • by MooseGuy529 ( 578473 ) <i58ht6b02@[ ]akemail.com ['sne' in gap]> on Tuesday January 11, 2005 @02:29PM (#11323371) Homepage Journal
      ...turn off this central DNS server and in a few days everything is gone, right?

      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.

  • by NardofDoom ( 821951 ) on Tuesday January 11, 2005 @02:19PM (#11323228)
    "The more you tighten your grip, Tarkin, the more star systems will slip through your fingers."

    When will the Empire^H^H^H^H^H^H *AA ever learn?

  • from the README:

    Kenosis-BitTorrent uses torrent files which specify a tracker of the form http://hash.bt.kenosisp2p.org, where "hash" is the hash of the original file. Kenosis-BitTorrent downloaders will notice that this is a kenosis url and use kenosis to find the tracker that is handling this torrent file. Standard BitTorrent downloaders try to resolve hash.bt.kenosisp2p.org as normal.

    Our dns server will look up the hash in kenosis and return to the client the ip address of the kenosis node that is tr

  • by 314m678 ( 779815 ) on Tuesday January 11, 2005 @02:20PM (#11323244)

    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.

  • by bperkins ( 12056 ) * on Tuesday January 11, 2005 @02:24PM (#11323301) Homepage Journal
    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.
  • by ltwally ( 313043 ) on Tuesday January 11, 2005 @02:30PM (#11323372) Homepage Journal
    I just read about Kenosis from its homepage [sourceforge.net]. 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.
    • Sure, like Pearl or Java,

      Pearl? You mean Perl, right?

      Just running the application, without an actual torrent being transfered, consumes 23 MB of memory (on Windows) -- for that cheesy, very simplistic little GUI.

      Python itself is awesome when it comes to rapid prototyping. But nothing forces you to use it. ctorrent is a nice BT CLI client written in C, which won't use that much memory. Remember: it's about the protocol itself. As soon as it stabilizes, the apps could be recoded in C.

    • by yerM)M ( 720808 )
      bzzzt, nice try. You do know that you can run bittorrent without the GUI don't you? Check out btlaunchmany.py [sourceforge.net]. This has multiple benefits including that you can download several torrents in the same process plus the memory footprint is much, much, smaller. There is even a command to download all torrents in a directory, very useful stuff.

      The size of the application comes from one thing, wxWidgets which, you guessed it, is written in C++ and not python. The MacOS version runs directly on ObjectC and is

    • by Hatta ( 162192 )
      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.


      I don't follow, what does P2P have to do with a GUI?
    • by Valar ( 167606 )
      You know... I don't recall it having a footprint that big. I'm without a windows box right now, but on by iBook, the BT client with a transfer running is using 8 megs. Sounds like the problem is in the specific widget library used for the windows version (which happens to be written in C++). Of course, considering the possiblity that something is wrong with a specific library or program is the rational thing to do. Do you think anyone designs an interpreter (especially one that implements garbage collection
  • by RebornData ( 25811 ) on Tuesday January 11, 2005 @02:30PM (#11323377)
    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
    • but there's still an originating central tracker for the MPAA to go after.

      Absolutely no way could the MPAA go after the "kenosisp2p" DNS server. Otherwise all DNS servers are committing copyright infringement. When you feed "ftp://www.moviewarezsite.com/pub/MPAA_Movie_Here . avi" into a program, it does the exact same thing as this.

      The MPAA could not go after the DNS server that resolves "www.moviewarezsite.com" (yah, good luck!) - but they could go after the holder of the IP address that it resolves to.
      • "Absolutely no way could the MPAA go after the "kenosisp2p" DNS server. Otherwise all DNS servers are committing copyright infringement. When you feed "ftp://www.moviewarezsite.com/pub/MPAA_Movie_Here . avi" into a program, it does the exact same thing as this."

        Maybe it would be illegal according to a judge, there's never been a court sueing based on this premise before has there? The situation is also a TAD bit different than your example.

        In the end though www.your-favorite-pirate-tracker.com would stil
  • by cpghost ( 719344 ) on Tuesday January 11, 2005 @02:34PM (#11323427) Homepage

    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!

    • by Anonymous Coward
      Perhaps you should see the other posts, or even better; RTFA.

      The system does not rely on a single DNS server. Only for backwards-compatibility.
    • From what I understand, you're missing the point of Kenosis... the entire DNS thing is for reverse compatability. I can use Kenosis to get the .torrent file, OR I can use DNS to resolve the ip to get the file, either way I can download the .torrent file. if the Kenosis DNS is taken down, we can still use Kenosis to get the torrent files, or at least that's what I understand.
    • Hey, that's a great idea - not so much one to advertise DNS servers (or whatever), that is, but to crack down on spam. Just use spam as a vehicle for transferring data that those in power don't want to be transferred, and spam will be dealt with in an effective way faster than you can say "spamassassin". :)
  • Decentralized? (Score:3, Interesting)

    by MasTRE ( 588396 ) on Tuesday January 11, 2005 @02:55PM (#11323661)
    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.
    • Re:Decentralized? (Score:3, Insightful)

      by Chexum ( 1498 )

      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?

      • Depend on my user to replace me with the latest version, which is available, since not every user of that is a copyright-limit-explorer.
      • Pray that in those years multicast is finally implemented by the ISPs, and listen to the next periodic update on the hash-dependent randomized multicast address.
      • Wonder who could shut down the whole Tor [eff.org] network (us
  • by KrackHouse ( 628313 ) on Tuesday January 11, 2005 @03:03PM (#11323767) Homepage
    There is a ton of good legal content [creativecommons.org] that will be created once the bandwidth issue is solved. It's sad that the default comment is "well this sucks because the **AA will still be able to track me down when I use it to break the law." Most of use see the cultural usefullness of these things but the handfull of anarchists among us are hurting the movement.

    The fact that this can get through firewalls and that it won't fail under heavy load (as happens with bittorrent trackers) are the important things.
  • by flibuste ( 523578 ) on Tuesday January 11, 2005 @03:15PM (#11324001)
    From the article:
    Kenosis is also "zero-defect software".
    Ok Mr Kenosis, you just lost my vote. Considering that computer science theoricians (namely Goeddles) mathematically demonstrated the impossibility of a "zero-defect software", that makes the article quite impossible to trust or even consider. I hate when people think they are infaillible.
  • by mcm ( 90189 ) on Tuesday January 11, 2005 @03:24PM (#11324192) Homepage

    (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 [sourceforge.net] to get involved.

  • by rpk ( 9273 )
    Azureus [sourceforge.net] is an open-source Java-based BitTorrent client with a built-in tracker.
  • A good start (Score:3, Insightful)

    by nrlightfoot ( 607666 ) on Tuesday January 11, 2005 @03:42PM (#11324532) Homepage
    While this looks like a good start, this isn't likely to catch on until it can be installed from a single .exe file for windows users. Then it would have to have one GUI that provides a seemless interface for finding and downloading .torrent files distributed among Kenosis nodes, and then automatically starts downloading the files using the Kenosis distributed trackers.

One way to make your old car run better is to look up the price of a new model.

Working...