[BitTorrent] Kenosis: BT tracker failover / distribution

Gary Fung gary at isohunt.com
Wed Feb 2 00:33:11 EST 2005

On Tue, 01 Feb 2005 18:59:10 -0800 (PST), Elliott Mitchell <ehem at m5p.com> wrote:

>> From: Gary Fung <gary at isohunt.com>
>> "Kenosis is a fully-distributed peer-to-peer RPC system built on top of XMLRPC. Nodes are automatically connected to each other via a Kademlia-style network and can route RPC requests efficiently to any online node. Kenosis does not rely on a central server; any Kenosis node can effectively join the network ("bootstrap") from any connected node."
> RPC and XML.
> Implementations of both have been fraught with security holes. RPC is
> pretty well guarenteed to be dropped at any decent border firewall, as
> it it used for LAN-only protocols. Very poor choice for something that
> will span the Internet. XML is big and complex. Why is something so big
> and complex needed where robustness is needed?
> Not to mention they still have some flavor of centralized tracker
> otherwise things just don't work (okay, so I'm unsure what Kademlia-style
> means). Notice earlier discussions on getting rid of the tracker, it just
> doesn't work.

I agree XML is bloated relative to bencoding, but RPC security depends on the systems it hooks to. Changing encoding scheme also shouldn't be too difficult, consider this as a proof of concept.

I haven't read much about Kademlia either, but Kenosis describes a root node for discovery of peer nodes (trackers), and the location of root node is configurable. So there are central servers, but not a single one.

>> There are two cases to consider: legacy BitTorrent clients and Kenosis-enabled BitTorrent clients. In either case, imagine we have two Kenosis-enabled BitTorrent trackers being run on machines TA and TB (both on port 1234). Machines TA and TB automatically organize themselves into a Kademlia-style network via Kenosis. Let's further imagine a file being shared by the operator of TA, called FA. FA's .torrent file is constructed to talk to this tracker URL: http://foo.bt.kenosisp2p.org:1234/announce.
> Sounds very much like the Multi-Tracker extension:
> http://bittornado.com/docs/multitracker-spec.txt
> It exists, it has been implemented. Haven't heard of complete failures
> with it. Perhaps the Kenosis folks should consider begining on that?

No this is different. multitracker pre-specifies trackers to connect to (I use it to add more bthub urls), Kenosis forms a P2P network of tracker nodes that all torrents can use. Node address is computed based on info_hash and a distance algorithm. Clients select the closest tracker node, if it goes down the next closest node is used so the swarm is not splitted.

>> Their DNS bridge is what I'm doing with http://{hash}.bthub.com:{port}/announce tracker redirections. Kenosis is written in python, so it maybe worthwhile to investigate this as an extension, towards distributed BT trackers.
> And here (and above too) is that dirty little secret. You're using DNS as
> your central server. Maybe not as much of one as the standard BT
> protocol, but still very much a central server. If I'm an evil dude, I
> can kill it by DoSing your nameservers, worse this kills ALL Kenosis
> files. Sounds like a conventional P2P app, not BT.
> So, what is new and different about this?

See above. The DNS in kenosis serves as a bridge for clients that are not kenosis aware. It resolves the node address inside the DNS instead of in client. If you want to get rid of the DNS point of failure than compute node address in client.


Yahoo! Groups Links

<*> To visit your group on the web, go to:

<*> To unsubscribe from this group, send an email to:
    BitTorrent-unsubscribe at yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:

More information about the BitTorrent mailing list